COM objects can be implemented either in Windows DLLs or in separate Windows processes via an EXE.
Objects implemented in DLLs are loaded into the process of the calling object. For example, if your program creates an object implemented in a DLL, that object’s DLL is loaded into your process, and the object is used directly from the DLL. These objects are known as InProc objects.
Objects implemented in their own process, obviously, use their own
process. If your program creates a COM object implemented in an
EXE, COM automatically starts the process for
the object (if not already running) and manages the plumbing between
the two processes. Objects implemented in an EXE that run on the
local machine are known as
objects, while objects implemented in an EXE that run on a remote
machine are known as
objects. We discuss
RemoteServer objects in the
later section Python and DCOM.
These options are not mutually exclusive; any object can be registered so that it runs in either, all, or any combination of these.
In most cases, you don’t need to be aware of this COM implementation detail. You can simply create an object and exactly how that object is created is managed for you. There are, however, some instances where being able to explicitly control this behavior is to your advantage.
Python and COM support
objects, as discussed throughout this chapter.