> Now I know I am showing my ignorance, but others will benefit from the
> conversation. Often you cannot learn if you do not show your ignorance.

And, at the risk of sounding like a very mean person, ignorance can be cured. :-)

>So a DCOM object behaves like a stored procedure on a server.

Umm, sort of...I guess; probably not the best analogy, though. It actually behaves just like a regular COM server, it's just running on a remote machine. AFAIK, that's the only practical difference. When you issue 'CreateObjectEx("MyServer.Foo", "ARemoteMachine")', a COM object is created just like it would normally using CreateObject(). The only difference is that it's running on the remote box, not the local box. I highly recommend that you read the latter parts of Chapter 16 in the Programmer's Guide before proceeding further; all of this is explained pretty well in that chapter.

>Can a DCOM object be run on a standalone Win95 or Win98 workstation?

Yup.

>How about NT Workstation or Windows 2000?

Yup.

>Of course it can run standalone on an NT Server since it would likely be
>running as a service.

Nope. NT Services are an entire different matter. On an NT/Win2K Server, it runs just like it would on any other box. If it's an EXE, it runs in it's on process space. If a DLL, there's an EXE on the remote box that serves as a DLL host (DLLHOST.EXE, I believe), since a DLL can't run on it's own.

>In a nutshell, what is the difference between DCOM, COM, and DLLs?

DCOM runs COM servers on remote machines, COM doesn't. DLLs run within the process space of the COM client (or DLL host, in the case of DCOM), EXEs run in their own process space outside of the process space of the COM client. Given this, a flaky COM DLL can take down the client process, whereas an EXE won't since it's running outside the client process space. Have I mentioned that it would be a good idea to peruse chapter 16 of the Programmer's Guide? :-)