Was ist .NET?

[Phoenix]

Zitat:

Jain. Heute bist Du darauf angewiesen, dass die von Deinem Programm verwendeten DLLs ein einer entsprechenden Version vorliegen, so Du sie nicht mitlieferst. Letzteres kannst Du bei .NET aber auch.

Also ich habe das Konzept anders verstanden:

1.) Du schreibst ein Assembly in einer ersten Version (1.0) - also sozusagen eine DLL im .NET - Zwischencode, die weiterverwendet werden kann.

2.) Du schreibst eine andere Software, die diese Version benötigt.

3.) Du entwickelst Dein Assembly weiter (Version 2.0), und fügst hierbei zum Beispiel inkompatible Änderungen zu 1.0 ein.

4.) Jemand anderes verwendet Version 2.0 Deines Assemblys und liefert seine Software aus.

Ein Zielsystem, auf dem Die Software aus 2 und 4 laufen müsste, wäre ohne .NET jetzt ziemlich aufgeschmissen. Zwei Versionen einer DLL - dazu noch inkompatibel zueinander - mag Windows nicht wirklich.

Das .NET Framework hat hierbei den Vorteil, daß es sich die letztendlichen Kompilate beider Assemblys cached, und den Zugriff selber verwaltet. Somit können beide Versionen nebeneinander Existieren und bei Bedarf angesprochen werden.

[Christian Seehase]

Moin Sebastian,

Zitat von Phoenix:

Zwei Versionen einer DLL - dazu noch inkompatibel zueinander - mag Windows nicht wirklich.

Abgesehen davon, dass Du ggf. Deine DLLs dynamisch laden, und dabei einen Pfad vorgeben kannst, hast Du seit Windows 2000 die Möglichkeit die Nutzung von DLLs, die sich im Programmverzeichnis befinden zu erzwingen, so dass prinzipiell jedes Programm mit genau den DLLs arbeiten kann, die es braucht.
Einfach eine Datei (kann auch leer sein, der Name ist wichtig) mit dem Namen
<Name der Exe inclusive Extension>.local
im Programmverzeichnis ablegen, und schon werden als erstes mal die im Programmverzeichnis befindlichen DLLs benutzt.
Da dies betriebssystem- und nicht programmabhängig ist funktioniert es mit jedem Programm.

[ShadowCaster]

Also ich find eure Antworten bisher sehr gut und konstruktiv. Einige Dinge muss ich wohl nochmal überdenken, wenn das stimmt, das der vorcompilierte Code tatsächlich zu einer z.B. Exe auf dem System compiliert würde.

Allerdings beschäftige ich mich jetzt schon einige Wochen mit dem PE-Exe, bzw. Dll-Format. Das PE-Format ist seid Windows95 ins Rollen gekommen und stellt einen großen Schritt zur Plattformunabhänigkeit auf der microsoftschiene dar. Das heißt, Anwendungen im PE-Format (auch Dll's) sollen laut Microsoft sogar auf OS2-Systemen laufen. Die Struktur des PE-Formats find ich von Microsoft ziemlich gut durchdacht und auch sehr logisch. Ich denke nicht, dass dieses Format .NET dieses Format völlig verdrängen wird. Schließlich müssen die .NET-Interpreter oder Compiler ja auch irgendwie laufen und auf ihrer eigenen Struktur können sie das sicher nicht. Das wäre ja so als wenn sich der Compiler selbst interpretieren würde, was nicht geht, wenn der compiler vorcompiliert ist. Das normale PE-Exe-format wird sicher in absehbarer Zeit nicht abschaffbar sein, wenn man das aus der Sichtweise betrachtet.

Derzeit lerne ich übrigens (ja, glaubt es ruhit) so Stück für Stück Assembler und ich bin froh, dass ich mich auch mal mit dieser Systemebene auseinander gesetzt habe. Da lernt man sehr viel, wie das System aufgebaut ist, wie der Kernel ausführbare Programme abarbeitet. Wenn .NET also so arbeitet und ich es richtig verstanden habe, könnte man das ja ohne Probleme auch mit Delphi emulieren Man müsste nur hergehen und einen Delphicompiler und ein Batchfile beim Anwender installieren. Dann gibt man ihm die DCU's und das Batchfile und diese Datei ruft den Compiler auf, dieser compiliert die vorcompilierten DCU's zu Exe-Dateien und führt sie aus. Wenn ich es so betrachte. Also rein auf der Microsoftschiene läuft das sicher ohne Probleme, da Delphi auch auf jeder Windowsversion ab 95 oder 98 laufen sollte. Wenn .NET von Microsoft da also greifen soll, wo es gar nichts zu greifen gibt dann muss das einen anderen Grund haben. Und da denke ich kann es nur einen für geben. Jede Windowsversion, ob nun NT oder XP, hat unterschiedliche API-Befehle die neun hinzugekommen sind. Wird der Code jetzt auf Windows95 ausgeführt, der für WindowsXP gedacht war, kann es Probleme geben, sofern er Api-befehle ausführt die für XP gedacht waren.

Das wäre ein Argument für .NET auch auf der Windows-Schiene.

Falls noch jemand was verstanden hat ... der Text da oben sollte nur aussagen, dass es auch Argumente für Plattformunabhänigkeit und damit auch .NET auf der Windowsschiene gibt. Ich werd noch was , bis dann.

[Chewie]

Bezüglich dem PE-Format: So wie ich das verstanden hab, kann das PE-Format ruhig weiterverwendet werden. Nur erzeugt ein Delphi.NET- oder C#-Compiler dann keine Datei mehr im PE-Format, sondern das wird dann von der Laufzeitumgebung, dem .NET-Framework, bewerkstelligt.

[ShadowCaster]

ja das stimmt, das PE-Format wäre dann auch gar nicht mehr nötig, weil die ganzen Verweise auf Sektionen und API-Funktionen entfallen. Im Prinzip wäre dann nur eine Sektion nötig (back to the roots) Können wir ja gleich die alten Dos-Exes von 16 auf 32 Bit portieren, dann haben wir .NET von der Seite aus gesehen, da die alten Dos32 Exe-Files keinen PE-Header und keine Sektionen wie im heutigen PE-Header hatten.

[Phoenix]

Zitat von ShadowCaster:

Das heißt, Anwendungen im PE-Format (auch Dll's) sollen laut Microsoft sogar auf OS2-Systemen laufen. Die Struktur des PE-Formats find ich von Microsoft ziemlich gut durchdacht und auch sehr logisch.

Ist kein Kunststück. Der Windows NT 4.0 - Kern und der OS/2 - Kern stammen aus der gleichen Produktion.

Tatsächlich hatten IBM und Microsoft damals gemeinsam ein OS entwickeln wollen. Aus Sicherheitsgründen hat IBM dann aber angefangen, den OS-Kern (der eben mit NT identisch ist) mit einer eigenen Shell möglichst Dicht abzukapseln. Hauptaugenmerk lag hierbei auf Sicherheit (deswegen wird OS/2 Warp auch bei vielen Banken noch eingesetzt).

Die meisten API-Calls kommen bei OS/2 also gar nicht bis zum System runter. Wie das genau bei PE nun läuft weiss ich nicht, aber ich denke, da der Kern der gleiche ist, liegt das wahrscheinlich dann an der OS/2 Shell, die den DLL's bzw. Anwendungen nur den Zugriff auf den Kern erlauben muss, damit diese laufen.