我对windows COM及其背后的思想有一定的了解。我想知道 *nix系统是否有等效的COM,或者为什么没有?
dpiehjr41#
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,它更像是一种事件/消息传递模式。
aamkag612#
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作为用户空间程序之间通信的独立部分发布,但他们担心这会导致功能膨胀和维护问题。最终,在目标是创建跨桌面标准的自由桌面组织的保护伞下,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应用程序的开发人员都认为XPCOM是一个主要的膨胀源,事实上Mozilla开发人员正在积极地减少XPCOM的使用,特别是像Gecko这样的“内部”组件。然而,正如@丹尼尔Pryden所指出的,Unix中已经有很多东西在不需要与桌面紧密集成的情况下应该比D-Bus更受欢迎。我说的是管道、命名管道和套接字等。
iproute2
fjaof16o3#
最接近的可能是CORBA
3条答案
按热度按时间dpiehjr41#
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,它更像是一种事件/消息传递模式。
aamkag612#
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作为用户空间程序之间通信的独立部分发布,但他们担心这会导致功能膨胀和维护问题。最终,在目标是创建跨桌面标准的自由桌面组织的保护伞下,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应用程序的开发人员都认为XPCOM是一个主要的膨胀源,事实上Mozilla开发人员正在积极地减少XPCOM的使用,特别是像Gecko这样的“内部”组件。
然而,正如@丹尼尔Pryden所指出的,Unix中已经有很多东西在不需要与桌面紧密集成的情况下应该比D-Bus更受欢迎。我说的是管道、命名管道和套接字等。
fjaof16o3#
最接近的可能是CORBA