Delphi.NET Plattformunabhängig?

[malo]

Durch die vielen .NET-Threads in letzter Zeit hab ich sehr viel über .NET gehört. .NET soll ja z.B. plattformunabhängig sein. Wenn ich es richtig verstanden hab, war Delphi bisher nur plattformspezifisch, weil es auf die WinAPI aufgebaut hat. Jetzt würde mich aber interessieren, ob Delphi.NET nun auch plattformunabhängig ist (bzw. wird, sobald der winAPI-Teil vollkommen abgeschafft wurde).

[Luckie]

Die WinAPI muss nicht "abgeschafft" werden. Es reicht wenn das .NET Framework auf entsprechenden Plattformen verfügbar wird. Verhält sich im Prinzip wie mit Java.

[malo]

Zitat von Luckie:

Die WinAPI muss nicht "abgeschafft" werden. Es reicht wenn das .NET Framework auf entsprechenden Plattformen verfügbar wird. Verhält sich im Prinzip wie mit Java.

Ich dachte da eher daran, dass ja an manchen Stellen immer noch mit der Win32-API gearbeitet werden KANN. Die Programme, in denen noch mit WinAPI gearbeitet wird, sind natürlich nicht auf allen Plattformen verfügbar.


Aber das heißt dann wohl, dass man seine Delphi.NET-Programme auf allen Plattformen (mit .NET-Framework) starten kann?

[Luckie]

Zitat von malo:

Aber das heißt dann wohl, dass man seine Delphi.NET-Programme auf allen Plattformen (mit .NET-Framework) starten kann?

So sollte es günstigsten Falls sein. Problem ist nur dass das Framework von Microssoft entwickelt wird und deren Geschäftsgebaren sind ja bekannt und berüchtigt.

[alcaeus]

Zitat von Luckie:

So sollte es günstigsten Falls sein. Problem ist nur dass das Framework von Microssoft entwickelt wird und deren Geschäftsgebaren sind ja bekannt und berüchtigt.

Wobei laut Aussagen von Robert_G und Phoenix mit dotGNU eine Portiermöglichkeit auf Linux möglich ist, und angeblich eine gute.
@malo: ob das Ganze portierbar ist, hängt von dir ab. Wenn du unmanaged Code verwendest, dann nicht. Wenn du aber auf direkte API-Aufrufe, sowie DLLs verzichtest, dann ja

Greetz
alcaeus

[r_kerber]

Zitat von malo:

ob Delphi.NET nun auch plattformunabhängig ist

IMHO sind noch große Teile von Delphi (und auch von VS) Win32. Deshalb dürften die nicht auf anderen Plattformen lauffähig sein, eigene Anwendungen, die 100% .net sind, aber schon. Plattformunabhängig ist, glaube ich, der SharpDeveloper.

[jbg]

Meinst du SharpDevelop? Wenn ja, dann frage ich mich, warum man MonoDevelop ins lebengerufen hat. So lange die WinForms nicht unter anderen Platformen "fehlerfrei" implementiert ist, laufen nur Console und ASP.NET Anwendungen fast überall (wenn man nicht gerade an einen nicht vertandenen IL-Befehl vorbeikommt, wie es bei den Assemblies, die der Delphi.NET Compiler produziert, der Fall ist. Ich weiß jetzt nicht, ob Mono das jetzt schon behoben hat, müsste ich mal ausprobieren, aber vor einem viertel Jahr, gingen manche Konstrukte, die der Delphi.NET Compiler ausspuckt, nur unter MS.NET.

[Robert_G]

Zitat von alcaeus:

Wobei laut Aussagen von Robert_G und Phoenix mit dotGNU eine Portiermöglichkeit auf Linux möglich ist, und angeblich eine gute.

Habe ich nie behauptet! Lese dir die betreffenden "Heise"-Threads nochmal genau durch.
.Net ist für mich eine Windows Plattform. Linux interessiert mich eigentlich nicht die Bohne.
@Jbg
Das kann vielleicht an der 2. RTTI liegen, die einem Delphi.Net aufzwingt. (Man müsste mal die Borland.Delphi.System.dll disassemblieren...)
Welche übrigens ein Grund für mich ist keine mit Delphi.Net kompilierten Assemblies zu benutzen. (Indy.Net, TMS Kompos,...)

[r_kerber]

Zitat von jbg:

Meinst du SharpDevelop? Wenn ja, dann frage ich mich, warum man MonoDevelop ins lebengerufen hat. So lange die WinForms nicht unter anderen Platformen "fehlerfrei" implementiert ist, laufen nur Console und ASP.NET Anwendungen fast überall

Jep den meine ich. Aber was wollt Ihr immer nur mit Mono. Es gibt auch noch dotGnu. Und wie ich den Diskussionen hier entnehme, kann dotGnu WinForms und wird offensichtlich durch M$ unterstützt.

[jbg]

Zitat von Robert_G:

Das kann vielleicht an der 2. RTTI liegen

Welche 2. RTTI? Die Unit TypInfo ist nur für Win32. Delphi.NET fügt ein paar Metaklassen ein, aber dazu kann es auch nur die von der CLI bereigestellten Möglichkeiten nutzen.

Zitat:

Welche übrigens ein Grund für mich ist keine mit Delphi.Net kompilierten Assemblies zu benutzen.

Bei Bibliotheken und Freeware bzw. kleinen Projekten mag das ein Grund sein, aber wenn man was größeres hat, ist es eigentlich egal, ob man da ein Assembly mehr oder weniger dazupacken muss.