Home » Linux » Is there an equivalent to COM on *nix systems ? If not, what was the *nix approach to re-usability?

Is there an equivalent to COM on *nix systems ? If not, what was the *nix approach to re-usability?

Posted by: admin November 29, 2017 Leave a comment


I have an understanding of windows COM and the ideas behind it. I am trying to understand if *nix systems even have an equivalent or why they don’t?


The Unix model is built around the idea of lightweight processes that communicate with each other, through sockets, pipes, signals, and command lines. Historically, Unix didn’t have threads (the POSIX thread model is only about 10 years old IIRC), but processes on Unix have always been much cheaper than on Windows, so it was more performant to factor functionality into separate executables than to allow a single program to grow large and monolithic.

In COM, you define binary interfaces that allow shared-memory communication. COM is tied to an object-oriented paradigm. In the classic Unix model, you define stream-oriented interfaces that allow communication over pipes, without shared memory. Conceptually, this is much closer to a functional programming paradigm.

The Unix model encourages making small programs that can be easily coupled together by a lightweight “shell”, while the COM model encourages making large programs that expose “components” that can be reused by other large programs. It’s really an apples-and-oranges comparison, since both models provide benefits and drawbacks for different scenarios.

Of course, modern Unix systems can have COM-like facilities. Mozilla has XPCOM, a cross-platform framework built on the same principles as COM. GNOME for a long time used Bonobo, which is conceptually very similar to Microsoft OLE, which was the forerunner to COM. But recent versions of GNOME have been shifting away from Bonobo in favor of D-Bus, which is more of an event/messaging pattern.


The closest would probably be D-Bus. D-Bus is a lightweight IPC protocol and Object Request Broker (ORB) very similar to COM and heavily inspired by both COM and D-Bus’s predecessors DCOP (KDE) and CORBA (GNOME) as well as Netlink (Linux Kernel).

Before D-Bus, both major Unix desktop environments had their own component models and desktop busses. GNOME had Bonobo which was based on CORBA and KDE had KParts which was based on DCOP. And the Linux Kernel has Netlink which is a communication protocol between kernel and userspace which is used for example by the iproute2 tool whenever you configure a networking interface.

The kernel developers constantly got requests to release Netlink as a separate part for communication between userspace programs, however they feared that this would lead to feature bloat and maintenance problems. In the end, under the umbrella of the Free Desktop organization whose goal it is to create cros-desktop standards, both the KDE and GNOME developers got together to develop an IPC messaging system based on the best parts of DCOP and Netlink, and the result was D-Bus.

In current versions of both GNOME and KDE, D-Bus has completely replaced CORBA and DCOP, thus making it possible to run GNOME applications in KDE and vice-versa with much higher fidelity. D-Bus has also been picked up by many other desktop environments and applications, not only on Linux but other Unix systems, as well as OSX and even Windows.

An alternative that should at least be mentioned is Mozilla’s XPCOM, which is a cross-platform object model heavily inspired by CORBA and COM. (In fact, XPCOM is an acronym for Cross-Platform Component Object Model.) It uses an IDL very similar to CORBA called XPIDL. However, as far as I know, nobody actually uses XPCOM, it is recognized both by critics as well as developers of Firefox and other Mozilla applications as one major source of bloat, and the Mozila developers are in fact actively working on reducing the usage of XPCOM especially inside components like Gecko.

However, as @Daniel Pryden points out, there’s a lot of stuff already in Unix that should be preferred over D-Bus in cases where tight integration with a desktop is not needed. I am talking about stuff like pipes, named pipes and sockets.


Closest would probably be CORBA