Dieser Artikel behandelt die Software-Technologie COM/DCOM. Für Informationen zur seriellen Schnittstelle (COM1/COM2 etc.) siehe unter RS-232.
COM
Das Component Object Model (Abkürzung COM) ist eine von Microsoft entwickelte proprietäre Technologie, unter Windows Klassen aus DLLs zu exportieren (aus DLLs können nur Funktionen aufgerufen werden, die dann einen Zeiger auf eine Instanz einer Klasse als Rückgabewert haben müssen) und somit eine leichte Wiederverwendung von bereits geschriebenem Programmcode möglich machen soll. Viele der Funktionen des Windows Platform SDKs sind über COM zugänglich. COM ist die Basis, auf der OLE-Automation und ActiveX realisiert sind.
COM basiert auf dem Client/Server-Prinzip: Der COM-Server bietet die zu exportierenden Klassen - die sogenannten COM-Objekte - an (er beinhaltet den Code), die über ein COM-Interface definiert werden. Der Client ist das Programm, welches die Funktionen benutzt. Er kennt die Funktionen, die das COM-Objekt bietet, da diese im COM-Interface deklariert sind. Vermittlung zwischen Client und Server leistet der sogenannte Marshaler, der beispielsweise Datentypen konvertiert.
COM-Interface
Das COM-Interface selbst ist COM-intern ein Zeiger, der auf die sogenannte VTable zeigt, eine Tabelle, die wiederum Zeiger auf die Funktionen enthält, die vom COM-Objekt angeboten werden. Ein Interface hat außerdem eine weltweit einmalige Identifikationsnummer, die GUID (Global Uniqe Identifier), welche ein Interface eindeutig spezifiziert, so dass auch mehrere Interfaces mit demselben Namen existieren können (aber nicht mit derselben GUID).
Hier ein Beispiel: Ein Interface sieht in der speziell für COM-Objekte geschaffenen IDL (Interface Definition Language) wie folgt aus:
[
odl,
uuid(00000000-0000-0000-C000-000000000046)
]
interface IUnknown {
[restricted]
HRESULT _stdcall QueryInterface([in] GUID* rrid,
[out] void** ppvObj);
[restricted]
unsigned long _stdcall AddRef();
[restricted]
unsigned long _stdcall Release();
}
Jedes Interface muss die Funktionen von des hier gezeigten Interfaces IUnknown definieren, da dieses die vitalen Funktion für COM implementiert, u.a. AddRef() und Release() für die Referenzzählung: Ein COM-Objekt lebt nur so lange, wie es Referenzen auf sein Interface gibt. Eine Vererbung der Interfacedefinitionen ist möglich. Da Programmiersprachen wie Visual Basic Probleme mit Pointern haben, hat Microsoft eine zweite Möglichkeit entwickelt, Funktionen aus COM-Objekten aufzurufen. Für diese Möglichkeit muss das Interface die Funktionen des Interfaces IDispatch definieren. Dies erlaubt es dann dem Programmierer, ein IDispatch zu instanzieren und über dessen Funktion Invoke() die Funktionen des genutzten COM-Objekts abzurufen. Da der Zugriff über das Dispatchinterface sehr viel langsamer als der Zugriff über ein normales Interface ist, wird oft beides implementiert (Dual Interface), so dass sich der Programmierer bei Programmiersprachen, die Pointer beherrschen, sich den Weg des Zugriffs auf das COM-Objekt aussuchen kann.
COM Server
COM-Objekte werden von COM-Servern angeboten. Von diesen gibt es drei Typen.
In-process-Server
Im Falle des In-process-Servers ist das COM-Objekt in einer DLL implementiert (sie tragen unter Windows oft die Dateiendung OCX). Diese DLLs müssen die Funktionen DllGetClassObject(), DllCanUnloadNow(), DLLRegisterServer() und DllUnregisterServer() exportieren. Wird über ein Interface auf ein COM-Objekt zugegiffen, so wird der zugehörige Server (ein Server kann mehrere COM-Objekte anbieten) in den Prozess des Clients geladen. Dies ist der Grund dafür, warum diese Server nur als DLL existieren, denn unter Windows können nur diese in einen Prozess injeziert werden. In-process-Server sind besonders schnell, da der Zugriff auf die Funktionen der COM-Objekte keine Umwege nötig macht (sofern die Zugriffe auf die COM-Objekte nicht Thread-überschreitend sind, ist der Marshaler nicht nötig). Jedoch muss jeder Prozess, der ein COM-Objekt, das in einem In-process-Server implementiert ist, dieses für sich in den Speicher laden, was nicht besonders speicherschonend ist.
Local Server
Local Server sind unter Windows ausführbare Programme, die die COM-Objekte implementieren. Bei Zugriff auf ein COM-Objekt wird dieses Programm gestartet (sofern es nicht schon läuft). Zur Kommunikation zwischen Client und Server wird ein abgespecktes RPC-Protokoll (Remote Procedure Call) benutzt. Local Server haben den Vorteil, dass sie nur einmal gestartet werden müssen und dann viele Clients bedienen können, was speicherschonend ist. Die Zugriffe über RPC sind allerdings langsamer.
Remote Server
Befindet sich zwischen Server und Client ein Netzwerk, so kommt DCOM (Distributed COM) zum Einsatz. Der Einatz von DCOM macht es theoretisch möglich, dass Server und Client auf unterschiedlichen Betriebssystemen laufen. DCOM benutzt im Gegensatz zum Local Server ein vollständig implemetiertes RPC, was die Aufrufe jedoch (auch bei sehr geringer Netzwerkauslatung) deutlich verlangsamt. Die Implemetierung vom DCOM unterscheidet sich von der von COM mit Local Server zusätzlich noch durch den vorgeschalteten Protokollstack. Durch eine Sicherheitslücke in der RPC-Implementation von DCOM wurde die Angriffsweise des bekannten Wurms W32.Blaster möglich.