System Registry of Classes for the Local Computer
A CLSID to identify an object implementation is not very useful unless clients have a way of finding the CLSID. From Chapter 5, we know that there are a number of ways a client may come to know a CLSID. First of all, that client may be compiled to specifically depend on a specific CLSID, in which case it obtained the server's header files with the DEFINE_GUID macros present. But for the most part, clients will want to obtain CLSIDs at run-time, especially when that client displays a list of available objects to [an] end-user and creates an object of the selected type at the user's request. So there must be a way to dynamically locate and load CLSIDs for accessible objects.
Furthermore, there has to be some system-wide method for the COM Library to associate a given CLSID, regardless of how the client obtained it, to the server code that implements that class. In other words, the COM Library requires some persistent store of CLSID-to-server mappings that it uses to implement its locator services. It is up to the COM Library implementor, not the implementor of clients or servers, to define the store and how server applications would register their CLSIDs and server module names in that store.
The store must distinguish between in-process, local, and remote objects as well as object handlers in addition to any environment-specific differences. The COM implementation on Microsoft Windows uses the Windows system registry (also called the registration database, or RegDB for short) as a store for such information. In that registry there is a root key called "CLSID" (spelled out in those letters) under which servers are responsible to create entries that point to their modules. Usually these entries are created at installation time by the application's setup code, but can be done at run-time if desired.
When a server is installed under Windows, the installation program will create a subkey under "CLSID" for each class the server supports, using the standard string representation of the CLSID as the key name (including the curly braces).1. So the first key that the TextRender object would create appears as follows (CLSID is the root key the indentation of the object class implies a sub-key relationship with the one above it):
CLSID
{12345678-ABCD-1234-5678-9ABCDEF00000} = TextRender Example
Depending on the type of same-computer server that handles this CLSID there will be one or more subkeys created underneath the ASCII CLSID string:
Server Flavor | Subkey Name | Value |
In-Process | InprocServer32 | Pathname of the server .DLL |
Local | LocalServer32 | Pathname of the server .EXE |
Object Handler | InprocHandler32 | Pathname to the object handler .DLL. |
So, for example, if the TextRender object was implemented in a TEXTREND.DLL, its entries would appear as:
CLSID
{12345678-ABCD-1234-5678-9ABCDEF00000} = TextRender Example
InprocServer32 = c:\objects\textrend.dll
If it were implemented in an application, TEXTREND.EXE, and worked with an object handler in TEXTHAND.DLL, the entries would appear as:
CLSID
{12345678-ABCD-1234-5678-9ABCDEF00000} = TextRender Example
InprocHandler32 = c:\handlers\texthand.dll
LocalServer32 = c:\objects\textrend.exe
Over time, the registry will become populated with many CLSIDs and many such entries.