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.)
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)