At this point, we start adding a whole host of new terminology into the discussion, and we'll explain these terms in more depth as we go, but for the time being, if any are unclear, please just accept the terminology being used and move forward.
Firstly, a COM component is commonly referred to as an Object or COM Object and these terms may be used interchangeably. There are several types of Objects, but for this discussion, we are only interested in COM servers or automation servers.
From the programmer's perspective, we can visualize a COM component or Object as simply a "black box" that comprises a set of functions and associated data. Internally, these Objects usually contain one or more pieces of reusable code (functions), and provide ways for an application to call the object's functions and read/write its associated data through its Dispatch Interface.
These components usually take the form of an EXE, or DLL/OCX file, but the actual file extension is largely irrelevant. However, DLL/OCX versions of a component are generally referred to as "in-process" since they are loaded into the address space of the calling application, whereas EXE-versions are typically "out-of-process" because they will not share the address space of the calling application.
Technically speaking, an Object is a special form of code library (similar to a standard DLL) that conforms to the COM specification, provides at least one Dispatch Interface, and is identified by a globally unique PROGID and CLSID.
A PROGID is a unique alphanumeric name representing a CLSID of a COM Object (for example "SourceSafe.0"), and the CLSID is a globally unique 128-bit binary "string" identifying the same Object. These identification strings are stored in the Windows Registry when the COM component is installed. PowerBASIC programmers reference COM components by their PROGID string, and rarely by their CLSID. However, since these are stored in pairs, it is straightforward to retrieve the matching PROGID for a known CLSID, and vice versa.
Yet thanks to COM, we do not really need to know how a COM Object does its job or is internally identified and initialized, we need only be concerned with what the job of the Object is, and how to communicate with the Object from the outside. The internal workings are effectively "hidden" from the outside world, and this is referred to as encapsulation.
Since we have no ability to "look inside" a COM Object, it is not (directly) possible to manipulate internal variables or memory, so a COM Object provides a degree of security for its internal code. The programmer can only work with the functions and associated data the COM Object provides externally. In practice, this is very similar to the use of a standard DLL that contains a few exported routines, yet contains a great many private routines.
The next part of this topic compares the roles of the server and the client.
See Also