D-Bus (short for "Desktop Bus"[4]) is a message-oriented middleware mechanism that allows communication between multiple processes running concurrently on the same machine.

[7][8][dead link‍] The freedesktop.org project also developed a free and open-source software library called libdbus, as a reference implementation of the specification.

[15]D-Bus provides a software-bus abstraction that gathers all the communications among a group of processes over a single shared virtual channel.

[19] D-Bus provides additional or simplifies existing functionality to the applications, including information-sharing, modularity and privilege separation.

For instance, an office suite can communicate through the session bus to share data between a word processor and a spreadsheet.

Unique connection names are easily recognizable because they start with the otherwise forbidden colon character.

That does not mean that D-Bus is somehow limited to OOP languages—in fact, the most used implementation (libdbus) is written in C, a procedural programming language.

A client can also listen to signals that an object emits when its state changes due to certain events, usually related to the underlying service.

[5][18] The object path is selected by the requesting process, and must be unique in the context of that bus connection.

To accomplish such goals, D-Bus communications are based on the exchange of messages between processes instead of "raw bytes".

[18][17] The body contains the data payload that the receiver process interprets—for instance the input or output arguments.

[5][17] Both processes must pass the same address to their respective communications libraries to establish the D-Bus connection between them.

The usual way is to always use a message bus daemon (i.e. dbus-daemon) as a communications central point to which each process should establish its point-to-point D-Bus connection.

This feature was originally implemented using setuid helpers,[23] but nowadays it can also be provided by systemd's service activation framework.

[18] D-Bus was started in 2002 by Havoc Pennington, Alex Larsson (Red Hat) and Anders Carlsson.

[25][26] An implementation of D-Bus supports most POSIX operating systems, and a port for Windows exists.

[8] The usage of D-Bus is steadily expanding beyond the initial scope of desktop environments to cover an increasing amount of system services.

For instance, the NetworkManager network daemon, BlueZ bluetooth stack and PulseAudio sound server use D-Bus to provide part or all of their services.

[27] Another heavy user of D-Bus is Polkit, whose policy authority daemon is implemented as a service connected to the system bus.

However, libdbus is a low-level implementation that was never meant to be used directly by application developers, but as a reference guide for other reimplementations of D-Bus (such as those included in standard libraries of desktop environments, or in programming language bindings).

[29] GDBus[9] is an implementation of D-Bus based on GIO streams included in GLib, aiming to be used by GTK+ and GNOME.

GDBus is not a wrapper of libdbus, but a complete and independent reimplementation of the D-Bus specification and protocol.

[citation needed] In 2013, the systemd project rewrote libdbus in an effort to simplify the code,[32] but it also resulted in a significant increase of the overall D-Bus performance.

In preliminary benchmarks, BMW found that the systemd's D-Bus library increased performance by 360%.

[34] kdbus was a project that aimed to reimplement D-Bus as a kernel-mediated peer-to-peer inter-process communication mechanism.

[38] kdbus inclusion in the Linux kernel proved controversial,[39] and was dropped in favor of BUS1, as a more generic inter-process communication.