D-Bus spec issue (Was Re: Windows DBus shared memory name depends on _DEBUG?)

David Zeuthen zeuthen at gmail.com
Tue Sep 28 07:16:57 PDT 2010

Hey Ralf,

On Sun, Sep 26, 2010 at 1:21 PM, Ralf Habacker <ralf.habacker at freenet.de> wrote:
> If there are no more objectivies I will apply these patches in the next days
> along with the autolaunch spec update.

Thanks for the effort of writing the patch


documenting the autolaunch: transport. I don't think it's quite right:

First, autolaunch: isn't really a transport - it's an implementation
detail of the dbus codebase. It really shouldn't be in the spec. E.g.
we don't want to require every implementation of the D-Bus protocol
(such as GDBus or NDesk) to support such a complicated "transport"
(which isn't a transport in the first place - if anything, it's an
address string).

Second, in <sect3
id="transports-autolaunch-windows-implementation-notes"> you mention
how to obtain the session bus address on Windows (including possibly
launching a bus if necessary). This is good but it really isn't an
implementation detail - it's really necessary to implement this in
each and every D-Bus implementation that is supposed to work on

Here's what I would do

1. Revert the patch

2. Add a simple blurb to the "Login session message bus" subsection of
the "Well-known Message Bus Instances" section, see


that specifies how to obtain (and set) the session bus address on
Win32 (e.g. the part with cDBusDaemonMutex and DBusDaemonAddressInfo).
Ideally as simple as what we have for X11 [1]:

    If that variable is not set, applications may also try to read the
address from
    the X Window System root window property _DBUS_SESSION_BUS_ADDRESS.
    The root window property must have type STRING.

What do you think about this?


[1] : The X11 part of this is actually wrong and the spec needs to be
updated to reflect the current behavior. But that's orthogonal to the
problem at hand.

More information about the dbus mailing list