How does COM/Automation do IPC under the hood?

6
votes

In its simplest form, COM allows you to instantiate C++-like classes from DLL in your application. Basically it's a glorified wrapper around LoadLibrary and some conventions regarding the interface. This is called using an in-process component.

But COM also supports out-of-process components. If you instantiate a class from such a component, COM starts a new process. Your objects live in said process, and are marshalled transparently over to you, so you don't care too much about where they live. They might even be on a different computer (DCOM). You can also fetch objects from already running applications. A well-known example is controlling MS Office via a script. This is called Automation (formerly OLE Automation, and there is a bit of confusion around what exactly this term encompasses).

There are a couple of nice articles explaining how (in-process) COM works low-level (e.g. COM from scratch. I'd like to know how it works when your component is out-of-process. Especially, what IPC does COM use beneath the hood to communicate between the processes? Window messages, shared memory, sockets, or something else? MSDN lists COM as an IPC method by itself, but I'm guessing it has to use something else underneath. Are different IPC methods used in different cases (instantiating an OOP component from C++, accessing an Excel document from VBScript, embedding a document in another via OLE)? It seems like it is all the same underlying technology. And lastly, how does marshalling fit in the picture? I believe it is neccessary to serialize method parameters for transmitting between processes, correct?

2
windowscomipc
the underlying transport is called RPC (Remote Procedure Call). It can also be used for inter-apartment calls within the same process, with an in-process server. – M.M
"Automation" means supporting IDispatch and only using parameter types and attributes that are compatible with automation – M.M
(oops, referenced deleted comment) ... What I wanted to say is, you can really take a simple COM DLL, call LoadLibrary, fetch its DllGetClassObject, and instantiate your class factory and your COM objects manually if you wanted to. I've actually tried this - not that it's advisable for a real application, but it's nice to see how it works beneath the hood. – jdm
I agree that it's good to understand how COM works, but I wouldn't call it a "glorified wrapper for LoadLibrary". That would be like calling a car a glorified wrapper for an ignition key. – M.M
technet.microsoft.com/en-us/library/cc738291%28v=WS.10%29.aspx – Hans Passant

2 Answers

2
votes

According to this MSDN article, it's RPC.

When you instantiate an OOP component, the COM subsystem generates an in-process proxy. This proxy is responsible for packing parameters and unpacking return values. It also generates a stub in the server process, which, expectably, unpacks parameters and packs return values.

Interestingly enough, the whole marshaling process can be customized, by implementing IMarshal.

1
votes

DCOM was originally added as an extension to COM, precisely for cross apartment calls. Note cross apartment calls are not always from process to process. A process can have many apartments (0 or 1 MTA and/or 0 to n STAs, etc.) . There is at least one apartment per process, etc.

DCOM, some kind of a "middleware", needed a technology for all this low-level work: data representation, caller/callee convention, memory management, wire marshaling, session handling, security, error handling, etc. so Microsoft naturally used the in-house implementation of DCE/RPC: MSRPC. Note that as Microsoft says on its site,

"With the exception of some of its advanced features, Microsoft RPC is interoperable with other vendors’ implementations of OSF RPC."

There was some tentative work to have all this implemented by other vendors, but they were basically killed by the rise of the internet and HTTP.

Also, note this RPC uses Windows Messages for STA apartement messages. I suggest you read carefully this document (not available any more on Microsoft site, shame on them :-) for more details: DCOM Architecture by Markus Horstmann and Mary Kirtland - July 23, 1997 .

See also this interesting case study about a DCOM/RCP issue that should tell you a lot of how RPC over Windows message works under the scene: Troubleshooting a DCOM issue: Case Study