【发布时间】：2011-03-05 01:09:05
【问题描述】：
我对 windows COM 及其背后的想法有所了解。我想了解 *nix 系统是否有等价物或为什么没有？
【问题讨论】：
标签： linux unix architecture com
【发布时间】：2011-03-05 01:09:05
【问题描述】：
Unix 模型是围绕通过套接字、管道、信号和命令行相互通信的轻量级进程的理念构建的。从历史上看，Unix 没有线程（POSIX 线程模型只有大约 10 年的历史 IIRC），但 Unix 上的进程总是比 Windows 上的便宜得多，因此将功能分解为单独的可执行文件比允许一个单个程序变得庞大而单一。
在 COM 中，您定义允许共享内存通信的二进制接口。 COM 与面向对象 范例相关联。在经典的 Unix 模型中，您定义了面向流的接口，允许通过管道进行通信，而无需共享内存。从概念上讲，这更接近于函数式编程范式。
Unix 模型鼓励制作可以通过轻量级“shell”轻松耦合在一起的小程序，而 COM 模型鼓励制作能够公开“组件”的大型程序，这些“组件”可以被其他大型程序重用。这实际上是一个苹果和橘子的比较，因为两种模型都针对不同的场景提供了优缺点。
当然，现代 Unix 系统可以具有类似 COM 的功能。 Mozilla 拥有 XPCOM，这是一个基于与 COM 相同原理构建的跨平台框架。 GNOME 长期使用 Bonobo，它在概念上与 Microsoft OLE 非常相似，后者是 COM 的前身。但最近版本的 GNOME 已经从 Bonobo 转向 D-Bus，这更像是一种事件/消息传递模式。
【讨论】：
-
+1。只需将 KDE 的 KParts 和 DCOP 放在那里，您就可以了解所有信息。 （吹毛求疵：shell 编程实际上更像是数据流编程而不是函数式编程。）
-
"POSIX 线程模型只有大约 10 年的 IIRC" 15 岁，实际上...作为 IEEE Std 1003.1c-1995。
-
COM 在创建时主要考虑了图形系统 (Windows) — 拖放、文档嵌入、第 3 方视频解码器等。要启用这些东西，您确实需要不可变的接口，与语言无关的数据布局和
AddRef/Release对。 COM 将 OOP 的多态性和封装思想推向了逻辑/荒谬的结局（不确定该选择什么词：但那里确实有大量 DI 和 IoC 的东西），所有这些工厂、代理和绰号等等......直到最近，GUI 才成为 Linux 的重中之重。所以在 Linux 上，COM 正在被重新发明。 -
声称可以避免巨大的过程是非常冒昧的。有多少进程和管道用于在 unix 上组成例如 googles chrome 浏览器？ ;) 认为这么多小流程范式涵盖了编写程序的整个空间，这有点荒谬。另外，我认为 *nix 没有像 COM 这样的东西的一个主要原因是，与 DLL 相比，共享库的加载速度更慢（大量的重定位操作）。至少几年前我上次检查时是这样的。
-
@BitTickler，我得出的结论是，缺少 COM 对基于 Linux 的平台上的软件造成了不可挽回的损害。整个生态系统都很好地完成了一件事，制作 Unix 克隆……就是这样。就像当时的 Unix 一样，它促进了中心化，……这导致了垄断的分裂或压迫。这就是为什么分发是必要的......为什么一个大型企业集团必须提供如此多的服务，它并不擅长提供促进充满活力的开源生态系统的通用操作系统，甚至是促进许多小型参与者的生态系统。
最接近的可能是D-Bus。 D-Bus 是一种轻量级 IPC 协议和对象请求代理 (ORB)，与 COM 非常相似，并且深受 COM 和 D-Bus 的前身 DCOP (KDE) 和 CORBA (GNOME) 以及 Netlink 的启发（ Linux 内核）。
在 D-Bus 之前，两个主要的 Unix 桌面环境都有自己的组件模型和桌面总线。 GNOME 有基于 CORBA 的 Bonobo，KDE 有基于 DCOP 的 KParts。 Linux 内核具有 Netlink，它是内核和用户空间之间的通信协议，例如，每当您配置网络接口时，iproute2 工具都会使用它。
内核开发人员不断收到要求发布 Netlink 作为用户空间程序之间通信的单独部分，但是他们担心这会导致功能膨胀和维护问题。最后，在以创建跨桌面标准为目标的 Free Desktop 组织的保护下，KDE 和 GNOME 开发人员共同开发了一个基于 DCOP 和 Netlink 最好部分的 IPC 消息传递系统，结果是 D-Bus。
在 GNOME 和 KDE 的当前版本中，D-Bus 已经完全取代了 CORBA 和 DCOP，因此可以在 KDE 中运行 GNOME 应用程序，反之亦然，并且保真度更高。 D-Bus 也被许多其他桌面环境和应用程序采用，不仅在 Linux 上，而且在其他 Unix 系统上，以及 OSX 甚至 Windows 上。
至少应该提到的一个替代方案是 Mozilla 的XPCOM，它是一个深受 CORBA 和 COM 启发的跨平台对象模型。 （实际上，XPCOM 是 Cross-Platform Component Object Model 的首字母缩写词。）它使用与 CORBA 非常相似的 IDL，称为 XPIDL。然而，据我所知，没有人真正使用 XPCOM，批评者以及 Firefox 和其他 Mozilla 应用程序的开发人员都认为它是臃肿的主要来源之一，而 Mozilla 开发人员实际上正在积极致力于减少XPCOM 尤其是内部 像 Gecko 这样的组件。
然而，正如@Daniel Pryden 指出的那样，在不需要与桌面紧密集成的情况下，Unix 中已经有很多东西应该优于 D-Bus。我说的是管道、命名管道和套接字之类的东西。
【讨论】：
-
优秀的答案。为什么 GNOME 和 KDE 的顶级开发人员会将他们的时间投入到 D-Bus 上？他们只能说：不需要 D-Bus，让我们都只使用管道、命名管道和套接字之类的“东西”。但他们没有。
最接近的可能是CORBA
【讨论】：