在最简单的形式中，COM允许您在应用程序中从DLL实例化类似C ++的类。基本上它是LoadLibrary的一个美化包装器和一些关于接口的约定。这是使用进程内组件调用的。
但COM也支持进程外组件。如果从这样的组件实例化一个类，COM将启动一个新进程。你的对象生活在这个过程中，并且被透明地编组到你身上，所以你不太关心他们住在哪里。他们甚至可能在不同的计算机（DCOM）上。您还可以从已在运行的应用程序中获取对象。一个众所周知的例子是通过脚本控制MS Office。这称为自动化（以前称为OLE自动化，对于该术语究竟涵盖的内容存在一些混淆）。
有几篇很好的文章解释了（在进程中）COM如何工作低级（例如COM from scratch。我想知道当你的组件处于进程外时它是如何工作的。< strong>特别是，IPC在引擎盖下使用什么IPC来进行通信？窗口消息，共享内存，套接字或其他东西？MSDN lists COM as an IPC method by itself，但我猜它必须使用某些东西在不同情况下使用不同的IPC方法（从C ++实例化OOP组件，从VBScript访问Excel文档，通过OLE将文档嵌入到另一个中）？看起来它们都是相同的基础技术。最后，如何编组是否适合图片？我认为有必要序列化方法参数以便在进程之间进行传输，是否正确？
答案 0 :(得分：2)
根据this MSDN article，它是RPC。
实例化OOP组件时，COM子系统会生成进程内代理。此代理负责打包参数和解包返回值。它还在服务器进程中生成存根，期望解包参数并打包返回值。
有趣的是，通过实施IMarshal，可以自定义整个编组过程。
答案 1 :(得分：1)
最初添加DCOM作为COM的扩展，正好适用于跨公寓呼叫。注意跨公寓呼叫并不总是从过程到过程。一个过程可以有许多公寓（0或1个MTA和/或0到n个STA等）。每个过程至少有一个公寓等。
DCOM，某种中间件＆＃34;，需要一种技术来完成所有这些低级工作：数据表示，来电/被叫惯例，内存管理，有线编组，会话处理，安全性，错误处理等等，因此Microsoft自然地使用了DCE / RPC的内部实现：MSRPC。请注意，正如微软在其网站上所说的那样，
＆＃34;除了一些高级功能外，Microsoft RPC是 可与其他供应商的OSF RPC实现互操作。＆＃34;
有一些尝试性的工作要让其他供应商实施所有这些，但它们基本上都被互联网和HTTP的崛起所扼杀。
另请注意，此RPC使用Windows Messages for STA apartement消息。我建议你仔细阅读这份文件（微软网站上不再提供，羞辱他们:-)了解更多详情： DCOM Architecture by Markus Horstmann and Mary Kirtland - July 23, 1997
另请参阅这个有关DCOM / RCP问题的有趣案例研究，它应该告诉您很多RPC over Windows消息在场景下的工作原理：Troubleshooting a DCOM issue: Case Study