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). :gruebel:

[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:

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:

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:

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:

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:

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! :shock: Lese dir die betreffenden "Heise"-Threads nochmal genau durch. :roll:
.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:

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:

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.

[Robert_G]

Zitat:

Zitat von jbg

Zitat:

Zitat von Robert_G

Das kann vielleicht an der 2. RTTI liegen

Welche 2. RTTI?

:wall: RTL
Jede Delphi.Net Assembly braucht die Borland.Delphi.System.dll -> Warum kapiere ich beim besten Willen nicht. :gruebel:
Nunja... wenn ich etwas im VS programmiere ,zum Bleistift um eben keine Borland Assemblies benutzen zu müssen*, finde ich es einfach nicht akzeptabel, dass es mir TMS oder die Indys aufzwingen wollen.
Also verzichte ich einfach auf jeden, der es macht ;)


*nicht weil ich nichts dazupacken will, eher weil ich diese Assembly nicht dazupacken will ;)

[jbg]

Zitat:

Zitat von Robert_G

Jede Delphi.Net Assembly braucht die Borland.Delphi.System.dll -> Warum kapiere ich beim besten Willen nicht.

Das ist eigentlich ganz einfach. Jedes Delphi-Programm unterstützt die "initialization" (kein Problem mit Klassenkonstruktoren) und "finalization" Abschnitte. Letzterer ist wegen eines fehlenden Klassendestruktors (ist ja auch was unsinniges aus .NET Sicht) nur mit Hilfsmitteln möglich und der Code steckt schon mal in der Borland.Delphi.System unit. Dann kommen die ganzen dinge wie dynamische Arrays, class helpers, virtuelle Konstruktoren.
Im Großen und Ganzen steckt da eben wie bei nativen Code der Kern der RTL drinnen. Das das bei C# nicht notwendig ist, ist klar. Das ist wie bei C++ mit der msvcrtXX.dll, die auch auf jedem Rechner vorhanden ist und somit nicht mit ausgeliefert werden muss. So ist die C# Runtime in der System.dll integriert (besser ausgedrückt: die C# RTL ist die System.dll).

Die Alternative zur Borland.Delphi.System wäre, dass der Compiler in jedes Assembly deren Code injiziert und den Unit-Klassennamen mit einer unique ID vergibt, damit es nicht zu Namenskonflikten kommt. Aber dafür hat sich Borland nicht entschieden. Die nutzen lieber ein gemeinsames Assembly, wie es sich unter .NET gehört.

Der Grund warum jedes Delphi-Programm die System Unit benötigt und ein C/C++ Programm ohne alles auskommt, liegt darin, dass man in Pascal immer einen gewissen Funktionsumfang hat, wohingegen in C/C++ alles über extrene Bibliotheken statisch/dynamisch hinzugelinkt wird. Beides hat seine Vor- und Nachteile. Das eine ist leicht austauschbar, das andere verhält sich immer gleich. (Aber damit gehe ich jetzt glaube ich zu weit weg vom Thema)

[Robert_G]

Zitat:

So ist die C# Runtime in der System.dll integriert (besser ausgedrückt: die C# RTL ist die System.dll).

Genau das ist eben nicht der Fall! C# ist absolut CLS compliant. Die einzige RTL, die es benötigt ist die CLR (noch nichtmal zwingend die MsCoreLib.dll ;) )

Auch wenn es wieder wie eine Rumzickerei klingt: Objektiv betrachtet wirken allen Argumente, die du aufgeführt hast, wie Ausreden für eine .Net-Sprache, die eigentlich keine ist.
Statische Konstruktoren sind nunmal das Mittel in .Net. Wenn Borland auf initialisierung und finalization besteht (Warum auch immer...), dann sollten sie es mit .Net Bordmitteln lösen oder einfach sein lassen.
Virtuelle Konstruktoren rechtfertigen ebenfalls keine 2. RTL. Wenn man diese Funktionalität will kann man sich ganz einfach eine virtual protected Methode anlegen, die man im Konstruktor aufruft. Dadurch würde es in jeder .Net Sprache funktionieren.

Aber egal... Ich produziere mal wieder nur hypothetisches Gesülze. Es ist nunmal so wie es ist: Mancheiner greift aufgrund dieser "features" zu D.Net und ich werde seine Kompilate nicht anfassen. ;)