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
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Em Domingo 25. Outubro 2009, às 12.26.59, Tor Lillqvist escreveu:
> 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?

I doubt it.

See my reply on the subject dated April 21 (Message-Id:
<200904211833.35416.thiago@...>)
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Tor Lillqvist]

>> DBusSharp implements an altogether different
>> transport mechanism based on Windows named pipes [...] So should this named pipe transport then also
>> be added to the dbus4win (and/or upstream) implementations?

> I doubt it. See my reply on the subject dated April 21 (Message-Id:
> <200904211833.35416.thiago@...>)

Yep, I remember that message. I wonder how well the "win" transport in
DBusSharp actually works then? They don't seem to use it in their
daemon implementation, Daemon.cs says: string addr =
"tcp:host=localhost,port=12345";  and as far as I can see doesn't
offer a way to change that. (Those parts have been commented out.) So
probably the "win" (named pipe) transport in DBusSharp is/was just an
experiment that didn't succeed that well? Anybody from DBusSharp here?

--tml
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

Em Segunda-feira 26 Outubro 2009, às 09:17:42, você escreveu:

> >> DBusSharp implements an altogether different
> >> transport mechanism based on Windows named pipes [...] So should this
> >> named pipe transport then also be added to the dbus4win (and/or
> >> upstream) implementations?
> >
> > I doubt it. See my reply on the subject dated April 21 (Message-Id:
> > <200904211833.35416.thiago@...>)
>
> Yep, I remember that message. I wonder how well the "win" transport in
> DBusSharp actually works then? They don't seem to use it in their
> daemon implementation, Daemon.cs says: string addr =
> "tcp:host=localhost,port=12345";  and as far as I can see doesn't
> offer a way to change that. (Those parts have been commented out.) So
> probably the "win" (named pipe) transport in DBusSharp is/was just an
> experiment that didn't succeed that well? Anybody from DBusSharp here?

Probably.

Like I said, named pipes are a dead-end. They are not supported on Windows CE.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Ralf Habacker]

Tor Lillqvist schrieb:

> 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.)
>  

dbus-launch could be easily extended to return the session info if
required .
> 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.)
>  
yes. The dbus client library contains code to autostart the dbus-daemon
on first demand. After dbus-daemon is started the client library acess
the shared memory segment to fetch recent dbus connection parameters.

Regards

Ralf

_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[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
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus

[Tor Lillqvist]

I have worked on making DBusSharp a.k.a. Managed D-Bus interoperate
better with a dbus4win-style session daemon. Check
https://bugs.launchpad.net/ndesk-dbus/+bug/461988 . (While there, also
note https://bugs.launchpad.net/ndesk-dbus/+bug/465711 and
https://bugs.launchpad.net/ndesk-dbus/+bug/465716 .)

--tml
_______________________________________________
dbus mailing list
dbus@...
http://lists.freedesktop.org/mailman/listinfo/dbus