How does COM / Automation do IPC under the hood?
In its simplest form, COM allows you to create instances of C ++ - like classes from DLLs in your application. It is basically a glorified wrapper around LoadLibrary and some interface conventions. This is called using the 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 the specified process and are passed to you transparently, so you don't care where they live. They can even be on another computer (DCOM). You can also retrieve objects from already running applications. A famous example is controlling MS Office through a script. This is called Automation (formerly OLE Automation, and there is a bit of confusion around what exactly this term covers).
There are some good articles explaining how (in-process) COM works at a low level (eg COM from scratch . I would like to know how it works when your component exits the process. In particular, IPC uses COM under the hood for inter-process communication? Messages in a window, shared memory, sockets or whatever? MSDN lists COM as an IPC method itselfbut I am guessing he should be using something else underneath. Are there 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 that this is still the same basic technology. And finally, how does picture sorting fit? I believe it is necessary to serialize method parameters to pass between processes, right?
source to share
According to this MSDN article , it is RPC.
When you instantiate an OOP component, the COM subsystem generates an in-process proxy module. This proxy is responsible for packing parameters and unpacking return values. It also generates a stub in the server process, which is expected to unpack parameters and packages, return values.
Interestingly, the entire marshaling process can be customized by implementing IMarshal
.
source to share
DCOM was originally added as an extension to COM, specifically for cross-apartment calls. Note that apartment cross-calls do not always occur from process to process. A process can have many apartments (0 or 1 MTA and / or 0 to n STA, etc.). Each process has at least one apartment, etc.
DCOM, a kind of "middleware", needed technology for all this low-level work: data presentation, callee / callee agreement, memory management, wiring marshaling, session handling, security, error handling, etc., so Microsoft naturally , used the internal DCE / RPC implementation: MSRPC . Please note that, as Microsoft states on its website,
"Except for some of its advanced features, Microsoft RPC is compatible with other vendor OSF RPC implementations."
There was some preliminary work to get this all implemented by other vendors, but mostly they were killed by the rise of the internet and HTTP.
Also, note that RPC uses Windows messages for STA messages. I suggest you read this document carefully (no longer available on Microsoft's site, shame on them :-) for more information: DCOM Architecture by Marcus Horstman and Mary Kirtland - July 23, 1997 .
See also this interesting case study on the DCOM / RCP issue, which should tell you about how the Windows RPC message works: DCOM Troubleshooting question: Case study
source to share