Interoperability between DBus implementations on Windows

[Tor Lillqvist]

The current (and apparently by its maintainers considered finished and
stable) dbus4win code uses a significantly different way to store the
session bus address for automatically connecting to it from clients
than the upstream "reference" implementation does on POSIX.

There is no dbus-launch program whose purpose would be to start the
dbus-daemon and print out (in either binary form, or in some shell
syntax) the bus address. (Well, there is dbus-launch-win.c but that is
just a program that runs dbus-daemon --session, passing no other
command line parameters, getting no information back to be printed
out.)

Instead, the session bus address is stored in a per-session shared
memory segment that the daemon creates and which exists only as long
as the daemon runs. (If I understand correctly.)

I assume that no environment variables are normally intended to be
used when using the dbus4win implementation. There is, as far as I can
see, no readily available way to learn the session bus address "from
the outside" once the bus is running, for which one on POSIX would
simply check the DBUS_SESSION_BUS_ADDRESS environment variable as set
by executing the shell code snippet dbus-launch prints during one's
desktop session initialisation.

Now, as such this presumably works fine as long as the dbus4win
implementation (or the "reference" implementation, if/once the
dbus4win fork is merged into that) is all there is on a Windows box.

However, there is also the managed (C#) DBusSharp implementation. That
wants to get the session bus address from the environment, like on
POSIX. So there is a problem here. Presumably DBusSharp is actively
used by some project also on Windows, or intends to be. And the
dbus4win implementation (and the "reference" one, if/once the dbus4win
code gets merged) is presumably also actively used by some other
projects.

It would be silly to have potentially two (or even more)
non-interoperable DBus session buses in a Windows session... Sigh.

I guess one immediately possible trivial thing would be to write a
minimal program to open the dbus4win-style per-session shared memory
segment print out the session bus address. That could be then used to
put it in the environment for DBusSharp's use. Or maybe just add code
to DBusSharp to check for the same shared memory segment that dbus4win
uses?

A second issue is that DBusSharp currently doesn't implement the
nonce-tcp transport that the dbus4win code wants to use. It *seems* to
be fairly trivial to do that, though. (I tried and as far as I could
see it worked, but for some other reason the DBusSharp client still
didn't manage to handshake correctly with a dbus4win/upstream -based
daemon. I didn't yet debug further.)

A third issue is that DBusSharp implements an altogether different
transport mechanism based on Windows named pipes (don't get confused
by the term, Windows named pipes are not really related to POSIX named
pipes). Possibly DBusSharp even considers this transport the default
one to use on Windows. So should this named pipe transport then also
be added to the dbus4win (and/or upstream) implementations?

--tml