Glossary of basic terms

A COM (Component Object Module) object is an instance of a COM class (or coclass), which has been registered in the Windows registry. The class is often written using C++, but can be written in any language. The object's implementation (i.e. code) is stored in a .OCX, .DLL, or .EXE file, typically in the C:\WINDOWS\SYSTEM directory. Any application, in any language, can then use the object - the object is loaded when first referenced, and unloaded from memory when every reference has been released.

An interface is a set of functions provided by the COM object. The interface appears like a pointer to an abstract C++ class, that has no member variables, and only pure virtual functions: the interface pointer is used to directly call the member functions of the COM object. If the implementation of the object changes, only the file containing it needs to be updated: the application does not change. By contrast, a change to the implementation of a C++ class requires the re-compilation and linking of the application.

The IDL (Interface Definition Language) is used to define interfaces, in an enhanced C-like syntax.

OLE (Object Linking and Embedding) and ActiveX objects are both types of COM object: the distinction is fairly vague, and the different names are largely used for marketing reasons. They provide (at a minimum) certain defined interfaces. OLE objects are intended to allow different types of document (e.g. word processor, spreadsheet, etc.) to be embedded within one another.

A client is the user’s code, which uses (i.e. calls) the COM object.

A server is a DLL or EXE file that provides a class factory, i.e. code which can create COM objects of a particular type. A server can provide more than one class factory, and hence can create COM objects of more than one type.

GUID: Globally Unique Identifier. A 128-bit (16-byte) number, which is virtually guaranteed to uniquely identify one specific type of object:

CLSID: Class ID. A GUID which identifies one COM object.
Stored in the registry as keys HKEY_CLASSES_ROOT\CLSID\{12345678-1234-1234-1234-123456789ABC}.
The default value contains the name of the object, which is often the same as its ProgID.
The default value of the sub-key InprocServer32 contains the filename of the server DLL file.
The default value of the sub-key ProgID contains the ProgID.

IID: Interface ID. A GUID identifying one type of Interface to a COM object.
Stored in the registry as keys HKEY_CLASSES_ROOT\Interface\{12345678-1234-1234-1234-123456789ABC}.
The default value contains the name of the interface (e.g. "IUnknown").

ProgID: a text string of the form "vendor.component.version" (without any spaces) which identifies one COM object.
Stored in the registry as keys HKEY_CLASSES_ROOT\vendor.component.version.
The default value contains a descriptive name of the object.
The default value of the sub-key CLSID contains the CLSID.

COM objects can be found in one of the following "contexts":

inproc: the object’s code is loaded from a DLL file, and is located in the same process as the client.
Does not require marshalling.

local: the object’s code is in an EXE file, which is executed as a separate process on the client machine.
Uses marshalling.

remote: the object’s code is on a different machine.
Uses marshalling.

Marshalling is the process of passing function arguments and return values between processes. The user's code directly calls a proxy, which appears exactly like the COM object. The arguments to the function call are serialised, and transmitted to the other process (which can be running on the local machine, or a remote machine connected via a network). Stub code running in the COM object's process then makes the function call on the user's behalf, and the results from the call are transmitted back.