Windows 8 unterdrückt C/C++ - Passt C/C++ nicht ins Konzept?

[DoS]

Guten Tag lieber Leser,
die einen wissen es schon: Es gibt schon seit etwas längerer Zeit vorläufige Informationen zu Windows 8. Ich persönlich bin darauf gestoßen, als ich die CHIP (Computermagazin, beste noch meiner Meinung nach) gelesen habe. Ich bin nach dem Artikel mit Windows 8 einer etwas, na ja aggressiven, Emotion verfallen und habe erst einmal schlechte Laune gehabt. Denn was ich da lesen musste, war für mich als C/C++ Liebhaber zu tiefst empörend. Es ist mir klar, dass Windows seine "eigenen" Programmiersprachen promovieren möchte, aber so? Ich informiere euch jetzt kurz und hoffentlich korrekt darüber, was mich da erbost hat.

1.) Windows 8 will in Zukunft die GPU viel mehr für Rechenoperationen nutzen. Viele nutzen schon die unheimlicher Power, die in den Grafikkartenprozessoren bei einfachen Operationen schlummert (z.B. CUDA von NVIDIA). Das ganze ist natürlich sinnvoll und gut. Dies wird die Leistung zum Beispiel von VB.NET usw. "Programmen" erhöhen. Für C/C++ gibt es allerdings dafür von Microsoft erst einmal keine automatische Funktion. Tja, war ja mal wieder klar: Hauptsache die "hauseigenen" Programmiersprachen unterstützen, der Rest interessiert nicht, denn wir wollen ja die Herrschaft/ Monopol.

2.) Microsoft lässt in Windows 8 C/C++ Programme nicht mehr direkt auf dem CPU ausführen. Als Grund dafür wird die Sicherheit angegeben, denn mit einem neuen System in Windows (Software-Isolierung) sollen zum Beispiel Bluescreens verhindert werden. Das funktioniert natürlich gut mit JIT-Kompiler (Java, .NET) aber da C/C++ richtig programmiert wurde, muss man das natürlich in einen erbärmlichen User-Mode mit weniger Rechten reinquetschen, und damit langsamer ausführen lassen ( wegen dieser angeblichen Sicherheit... ). Mit dieser Mogelei sollen dann .NET Programme so schnell laufen, wie C/C++ Programme.

Tja, wenn man schon einen scheiß JIT-Kompiler nutzt, muss man das ja durch Schummeln ausgleichen. Hauptsache Microsoft unterdrückt das, was ihm gerade mal nicht passt.

Wäre mal daran interessiert, was ihr gerade so denkt.

Mit freundlichen Grüßen
DoS

P.S. Der Thread sollte ein Appell zum Diskutieren sein und wurde deswegen dramatisch geschrieben.

[Funk_Doc]

Is ne Frechheit von MS. Wenn ich nicht so Spielsüchtig wäre würde ich nur noch linux einsetzen, aber egal zurück zum Thema. Is genauso wie mit DX und WinXP.

[QpL]

Naja - da Windows 8 noch in "Kinderschuhen" steht sind natürlich viele Sachen in Arbeit. Klar kommen auch viele Konzepte/Vorschläge ans Tageslicht. Ich denke, dass Microsoft diesen Schritt keinesfalls durchziehen wird. C bzw C++ ist eine ethablierte Programmiersprache, mit der sehr viele Programme geschrieben wurden - Viele können sich die Portierung auf .NET einfach nicht erlauben - sei es um kosten bzw. Performance willen. Auch wenn Windows eine bessere Performance solcher Tools verspricht ist diese nicht garantiert.

Grüße

[IRET]

Sollten sie das wirklich machen ,wird das sicherlich Folgen haben.
Viele werden zu Linux und Mac wechseln.
Und davor schätze ich werden die Spieleentwickler ihre Spiele halt auf OpenGL portieren usw.
Find das aber wirklich nicht OK von MS.
Hoffentlich bleibt es dabei ,dass es nur ein Vorhaben ist.

[l0dsb]

Wenn du schon so einen Thread anfängst, dann beachte bitte, dass Windows lediglich zwischen managed und unmanaged binaries unterscheiden wird. Die verwendete Sprache ist dabei im Endeffekt vollkommen egal.

Wer sagt, dass der Isolated Mode langsamer ist? Nur weil etwas nicht direkt auf der CPU ausgeführt wird (steht das so wortwörtlich im CHIP-Artikel?), muss es nicht zwangsläufig langsamer sein.

Dass die GPU-Funktion (zuerst) in das Framework integriert wird, liegt daran, dass es den zentralen JITer besitzt. Eine solche Zwischenstufe haben native Anwendungen nicht, weshalb die Umsetzung der GPU-Ausführung mehr als nur ein Designproblem darstellt.

Das .NET-Framework läuft nicht im Kernelmodus. Das ist schlichtweg falsch.

OT: Ich selbst programmiere primär in C/C++, aber auch in (zensiert, um Op's und BB's Augen zu schützen). Nur als Information, bevor mir sonst was vorgeworfen wird.

[ocz]

Hi wollte auch nur sagen das ich das voll blöd finde weil ich weiß nicht ob mein crypter noch geht unter windows 8
mfg

[mo0wm]

Microsoft lässt in Windows 8 C/C++ Programme nicht mehr direkt auf dem CPU ausführen.

Woran soll man denn kompilierte C/C++-Programme erkennen? Windows müsste das dann gleich bei allen nativen Exe- und DLL-Dateien umsetzen, sodass auch zB. in Assembler programmierte Dateien emuliert werden würden. Und weil man unter anderem Hardware-Treiber schlecht in .NET-Umgebungen laufen lassen kann, würde es fürs erste kein Problem sein, weiter in C oder C++ zu programmieren. Langfristig wird Microsoft aber eben immer mehr versuchen die eigenen Sprachen durchzusetzen.

[Barny]

Ich kann dazu nur sagen, dass ich froh bin auf Linux umgestiegen zu sein!^^ Würde ich jedem anderen eigentlich auch empfehlen!

Zum Thema: Ich finds auch ne Sauerei, falls das was oben steht denn wirklich auch stimmt. Wurde ja schließlich shcon kritisiert!

mfg

Barny

[DoS]

@l0dsb: Genau auf einen, wie dich habe ich gewartet . Jemand der ein paar Dinge genauer erklären kann. Wie ich bereits gesagt habe, basiert der Thread auf der Quelle des CHIP-Artikels. Er wurde zudem stark und dramatisch zusammengefasst und soll eine kleine Diskussion provozieren. Ich selbst habe von den einzelnen Dingen keine genaue Kenntnis (,wie du vielleicht) .

"Wer sagt, dass der Isolated Mode langsamer ist?"

Das behauptet hier keiner. Gerade weil der Isolated Mode bei Framework basierenden Programmen gut läuft, ist es ja schneller. Bei C/C++ ist das allerdings nicht so einfach umzusetzen.

"Das .NET-Framework läuft nicht im Kernelmodus."

Stimmt, das hatte ich nicht genau genug gelesen. Wurde sofort berichtigt. Da ist wohl die Dramatik mit mir durchgegangen.

Mit freundlichen Grüßen
DoS

P.S. @ OpCodez: Ja, du hattest Recht, damit was du mir letztens gesagt hast

[l0dsb]

Um welche CHIP-Ausgabe handelt es sich denn?

Ich erinnere mich an ein ganzes Betriebssystem, das jedes Programm in einer Sandbox laufen ließ. Der Ansatz macht an für sich Sinn, Details zur Implementierung, die MS vornehmen will, wären sicherlich interessant.