>>>Mike,
>>>
>>>>I'd almost swear that DCOM servers can be DLLs that run within the DLLHOST.EXE process on the remote machine. In fact, I believe chapter 16 of the Programmer's Guide, to which I referred Bruce, illustrated how a DCOM DLL server runs in the process space of a proxy stub. I'll have to investigate tomorrow.
>>>
>>>DLL's only run remotely if run by MTS.
>>
>>Yep - a .DLL is an in-process server; in order to use DCOM, which clearly has to run out of process (since it's kind of hard to execute code running at least potentially on another processor on a different machine entirely), it's clearly running out-of-process, and must be hosted by a process (a .DLL runs in the process space of some process, rather than having its own process space.) MTS provides the process that hosts in-process servers and provides the pool management and connection services that handles attaching an in-process server to a remote connection.
>
>As Mike S mentioned yesterday, it's probably also relevant to state that some in-proc servers can be configured via the registry or OLEView to run remotely by using dllhost.exe to serve as a surrogate process. But this doesn't pertain to VFP servers.

Yep, the key here is surrogate process - it runs in the context of another process (DLLHOST.EXE) which actually handles the process of converting the marshalling between the in-process server and DCOM. MTS handles a good deal more than this.