If a class is intended to be available to clients at any time, as most applications are, you usually register it through an installation and setup program. This means putting information about the application into the registry, including how and where its objects are to be instantiated. This information must be registered for all CLSIDs. Other information is optional. Win32 tools, such as Regsvr32, make it simple to write a setup program that registers servers at installation.
If you are not relying on system defaults, there are two important keys in the registry: CLSID and AppID. Among the important pieces of information under these keys is how the object is to be instantiated. Objects can be designated as in-process, out-of-process local, or out-of-process remote.
Under the new AppID key, are several named-values that define information specific to that application. Among these are RemoteServerName, and ActivateAtStorage, both of which can be used to permit a client with no built-in knowledge of the location of the server, to create an object. For more information on remote instantiation, see Locating a Remote Object and Instance Creation Helper Functions.
A server can also be installed as a Win32 service, or to run under a specific user account. For more information, see Installing as a Win32 Service or User Account.
A server or ROT object that is not a Win32 service or run under a specific user account can be referred to as an "activate as activator" server. For these servers, the security context and the window station/desktop of the client must match the server's. A client attempting to connect to a remote server is considered to have a NULL window station/desktop, so only the server security context (for information on Windows NT SID, see the security section of the Win32 SDK) is compared in this instance. COM caches the window station/desktop of a process when the process first connects to the distributed COM service. Thus, COM clients and servers should not change their window station or thread desktops of the process after calling CoInitialize or CoInitializeEX.
When a class is registered as in-process, a call to CoGetClassObject to create its class object is automatically passed by COM to the DllGetClassObject function, which the class must implement to give the calling object a pointer to its class object.
Classes implemented in executables can specify that COM should execute their process and wait for the process to register their class object's IClassFactory through a call to the CoRegisterClassObject function.
For detailed COM registry information, see Registering Components and COM Registry Keys.