WinAPI-Ersatz in Windows Longhorn

alles klar

Artchi

net schrieb:

asdfasdf schrieb:

also rede doch nicht so ein scheiss. das kommt doch erst mit visual studio .net 2005. das kannst du doch noch gar nicht ausprobiert haben.

hab' ich auch nicht. war wer anders. ausserdem geht bei meinem ollen vs2002 das auch schon. schimpft sich 'verwaltete c++ anwendung'

Verwaltete C++ Anwendung = ManagedC++ = C++/CLI 1.0

Passt schon!

Ok, nennen wie es Version 1 und 2. Aber zwischen diesen Versionen liegen gewaltige Unterschiede.

Artchi schrieb:

Verwaltete C++ Anwendung = ManagedC++ = C++/CLI 1.0

Nur zu deiner Information: _ICH_ habe Visual C++.Net 2005 bereits ausprobiert und kann sagen, dass Managed C++ gar nicht == C++/CLI ist. Ehrlich gesagt ist es eine völlig neue Sprache; inkompatibel allen alten managed C++ Source umschreiben, oder einen Compilerschalten benutzen, der die neue Syntax disablet! C++/CLI wurde als Bezeichnung erst nach manageD C++ erfunden, da sonst wohl von Anfang an von C**/CLI die Rede gewesen wäre.

Artchi

Das ändert nichts daran, das nur die Syntax geändert wurde. Das steht auch in dem von mir geposteten Artikel. Und nicht ich oder wir "nennen es mal" Version 1 und 2, sondern das ist orig. von MS und der ECMA so benannt, das die neue Syntax C++/CLI 2.0 heißt. Und du kannst auch in VC++ 2005 die alte Syntax per Compiler-Parameter reaktivieren. Lies mal deine Compiler-Hilfe durch, es kommt am Ende immer Code der selbe Code raus.

geeky

Ich freu mich schon auf Avalon

ich freu mich nicht auf ein betriebssystem was so langsam ist wie java.

dEUs

Brauchst dich nciht drauf zu freuen, kannst jetzt schon damit rumspielen

geeky

Ich werd auch damit rumspielen, sobald ich mal wieder Platz auffa platte hab

Irendwie versteh ich das mit der VM nicht richtig.

Wenn .net die WinAPI ersetzen soll dann muss es ja auch in allen Bereichen wo noch WinAPI eingesetzt wird einsetzbar sein. Was ist denn jetzt mit den ganz einfachen exes? zb Notepad und Minesweefer. Werden denn auch die alle in einer VM laufen oder werden da doch noch die ganz normalen PEs eingesetzt?

Ich meine wer sagt, dass .net eine VM braucht und, dass die WinAPI von .net abgelöst wird der sagt doch eigentlich auch, dass das PE exe Format begraben wird. Ds baut ja auf nativ Code auf und nicht auf irgendeinem interpretirten Code, also .net fällt aus, und die WinAPI ist ja nicht mehr einsetzbar.

Irgenwie erscheint mir das ganze nicht so richtig geheuer.

Bitte um Aufklärung.

operator void

Optimizer schrieb:

frage ich mich, wie du zu deiner gegenteiligen Behauptung kommst

Nur um meinen Ruf als CLI/C++-Fan zu retten: Du wolltest den anderen da quoten. Ich hab ein paar Minuten später deine Gedanken gehabt

operator void schrieb:

Optimizer schrieb:

frage ich mich, wie du zu deiner gegenteiligen Behauptung kommst

Nur um meinen Ruf als CLI/C++-Fan zu retten: Du wolltest den anderen da quoten. Ich hab ein paar Minuten später deine Gedanken gehabt

Oh verdammt. Das geht natürlich nicht, dass ich dir hier einfach was in die Schuhe schiebe. Aber keine Sorge, ich hab schon einen Schuldigen:

dEUs schrieb:

Optimizer schrieb:

Das stimmt nicht. Tatsächlich kann man nur mit C++/CLI alle Möglichkeiten des Frameworks bis ins letzte Detail nutzen. Ob das jetzt ausschlaggebend ist, muss jeder für sich wissen.

Welche Aspekte von .NET kann man mit C# nciht ausnutzen? (voids Frage kopiert und berichtigt)

Dies hat bei mir den Eindruck erweckt, dass du auch diese Frage gestellt hast und weil ich ja nicht 5 Stunden damit verbringen kann, dein Post durchzulesen, habe ich das nicht groß kontrolliert.

Ne, sorry natürlich.

Welche Aspekte von .NET kann man mit C# nciht ausnutzen?

z.B in Generics casten? Templates von Generics? Generische (function-)pointer? Wirklich typisiertes boxing/unboxing von System.ValueType Typen ohne Casting? Zusätzliche Operatoren wie op_PointerDereference und op_MemberSelection? Kontrolle über den Entrypoint der Applikation in die CLR, sowie den Austritt? System::Object via System::IntPtr zuweisen und umgekehrt, sowie von Hand auf Wert setzen (Ich weise System::Object den Wert 0x89ff3ea6 zu) Theoretischer Direktzugriff auf den nicht gepinnten Speicher, was ziemlich gefährlich sein kann? Unmanaged Zeiger auf managed Zeiger und vielleicht auch umgekehrt? Aber das brauchen wohl nur die wenigsten...