(D)COM(+)(-Server), OLE, .NET - So viele Begriffe, so wenig Ahnung

[Medium]

Richtig ist aber dennoch, dass .NET Java nicht unähnlich ist. Programmcode wird in die sog. "IL" (Intermediate Language) kompiliert (~Java Bytecode), und das ist, was in einer .NET-EXE (u.a.) steht. Auf dem Ziel-PC muss zur Ausführung das .NET-Framework installiert sein, welches die IL bei Ausführung in nativen Code über- und ausführt, sowie diverse Schnittstellen des Betriebssystems in geeigneter Form bereit hält. Der JVM also recht ähnlich. COM kommt hier insofern mit ins Spiel, als dass vieles im .NET Framework auf COM-Techniken basiert. Die beiden sind aber mitnichten verheiratet!

Was .NET so nett macht ist, dass es zum einen verspricht, die IL für die jeweilige Plattform optimiert zu kompilieren, auf der man es gerade ausführen will, vor allem aber auch die weitestgehend objekt-orientierte Kapselung der WinAPI. Und dazu noch ein (bzw. zwei) hübsche GUI Frameworks. (Winforms und WPF.) Zudem ist im .NET Framework einiges an Helfern und Dingen, die man so im Programmieralltag braucht bereits als fertige Lib enthalten, wofür man in vielen anderen Umgebungen erst 3rd-Party Code suchen müsste. Es ist alles in allem wohl vor allem ein deutlich weicheres Kissen als die nackte WinAPI, und zwar "ab Werk".

OLE ist ein Subsystem, dass es ermöglicht "Komponenten" Betriebssystemweit zu teilen. Quasi ein TButton, der sich via OLE in C, C++, C#, Delphi, etc. einsetzen ließe, und für alle Sprachen die selbe Codebasis und die selben Binaries hat. Windows regelt das Zusammenspiel zwischen deren Interface und der benutzenden Applikation. Ein Stichwort zu OLE wäre auch noch ActiveX, welches auf OLE basiert. (Die meisten OLE-Controls sind jedoch weit komplexer als ein Button, und teils gar ganze Programme in eigenen Prozessen, die via OLE programmgesteuert nutzbar werden - z.B. die Office Programme.)