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)