The Component Object Model, or COM, is a specification that defines how interfaces work and how the root objects of components are created. The COM Library implements part of this specification to work in conjunction with custom component servers, DLLs or EXEs, that implement the rest. Through this interaction, a client can pass a CLSID to the COM Library, which locates the appropriate server implementation, brings that code into memory, and has that server create the root object of a component for the client. From that point on, the client communicates directly with the component's objects through interface pointers, with the COM Library providing transparent "marshaling," which enables the client to work with local (different process) and remote (different machine) objects as if they were in the client's own process space.
To support this architecture, a COM server must provide a class factory object (IClassFactory) that creates instances of objects on demand with optional support for licensing (IClassFactory2). A server must expose this class factory to the rest of the system and provide a means for unloading itself, the mechanisms for which depend on the type of server involved. Registry entries map the server's supported CLSID to its module location and can be used to mark one server as "emulating" another. These registry entries can be created from within the server itself if it supports self-registration. COM uses the registry to locate the implementation of a CLSID on behalf of a client in response to calls to CoCreateInstance or CoGetClassObject, the latter of which is the core means through which anything outside of a server gains access to that server's class factory.
Regardless of the type of server involved, its components can have any number of objects and those objects can have any number of interfaces. Some interfaces, however, do not have marshaling support, either because it is technically impossible or because specific marshaling support for those particular interfaces is not available in the system. This means that some interfaces can be implemented only from in-process objects, while others can be implemented in local and remote objects. The concept of an object handler provides the necessary means to supply a partial in-process object that communicates with its remaining implementation elsewhere.
This chapter includes a number of samples to demonstrate the basic mechanisms involved with COM clients and servers, as well as demonstrations of self-registration and licensing.