Interoperability between DBus implementations on Windows

[Tor Lillqvist]

> dbus-launch[-win.c] could be easily extended to return the session info if required

True, but on the other hand now when I think more about it, I don't
know if that is necessary after all.

On Unix / Linux desktops the situation is that dbus is a more or less
essential part of the desktop infrastructure, isn't it? So there it is
natural that the dbus daemon is started as part of the desktop session
startup, and the dbus-launch output is used to store the session bus
address in the environment of the desktop starting process, and thus
all its descendants, all processes in the desktop.

Not so on Windows. Here I assume the thought is that dbus is used by
individual applications (some of which might form an "interoperable
related set" of apps (for example, KDE apps), which, depending on the
case, might be run at some point, or not at all, in a typical session
of a user. There is no need to start the dbus daemon at login time,
and no natural and suitable way to put the dbus session address in the
environment of the desktop parent process / "shell", i.e. Explorer. So
on Windows I would say that indeed the dbus4win scheme to use a
fixed-name shared memory segment that the dbus daemon creates when it
is started on-demand is the natural way to store the session bus
address. The DBUS_SESSION_BUS_ADDRESS environment variable is mostly
used in debugging.

--tml