Server Flavors: In-Process and Out-Of-Process

As defined in the last section, a server in general is some piece of code that structures some object in such a way that COM implementor locator services can run that code and have it create objects. The section below, The COM Library, expands on the specific responsibilities of COM in this sense.

Any specific server can be implemented in one of a number of flavors depending on the structure of the code module and its relationship to the client process that will be using it. A server is either in-process which means its code executes in the same process space as the client, or out-of-process which means it runs in another process on the same computer or in another process on a remote computer. These three types of servers are called in-process, local, and remote, as defined below:

In-Process Server A server that can be loaded into the client's process space and serves in-process objects. Under Microsoft© Windows© and Microsoft Windows NT, these are implemented as dynamic link libraries or DLLs. This specification uses .DLL as a generic term to describe any piece of code that can be loaded in this fashion which will, of course, differ between operating systems.
Local Server A server that runs in a separate process on the same computer as the client and serves local objects. This type of server is another complete application of its own thus defining the separate process. This specification uses the terms .EXE or executable module to describe an application that runs in its own process, as opposed to a DLL which must be loaded into an existing process.
Remote Server A server that runs on a separate computer and therefore always runs in another process as well to serve remote objects. Remote servers may be implemented in either .DLLs or .EXEs; if a remote server is implemented in a .DLL, a surrogate process will be created for it on the remote computer.

Note that the same words in-process, local, and remote are used in this specification as a qualifier for the word object where emphasis is on the object more than the server.

Object implementors choose the type of server based on the requirements of implementation and deployment. COM is designed to handle all situations from those that require the deployment of many small, lightweight in-process objects (like controls, but conceivably even smaller) up to those that require deployment of a huge central corporate database server. Furthermore, COM does so in a transparent fashion, with what is called location transparency, the topic of the next section.