Win32 Port of D-Bus

[Kosina, Martin]

>Do you believe there are any changes needed that should go 
>into D-Bus before the 1.0 release that will facilitate your 
>Windows port?  What state is the Windows port in these days?  
>Thanks.

Hi,

So far, I don't see a need for changes in the public API, all
platform-specific changes have been confined to dbus-sysdeps.c,
dbus-sysdeps-utils.c, and dbus-spawn.c. The only thing I can think of
would be an abstraction for file descriptor implementation (lot of that
stuff can't be ints on Windows - see discussion bellow). Not sure right
now if there are even any parts of the public API that expose that
directly, but they would need to change to something like dbus_pipe_t,
dbus_socket_t, etc. Unless someone knows of a more clever way, the
library headers will also need to contain a macro in front of function
declarations and typedefs, something like:

DBUS_API typedef struct DBusTimeout DBusTimeout;
DBUS_API DBusConnection*  dbus_connection_open (const char *address,
DBusError *error);

On Windows, the DBUS_API macro will evaluate to the usual
_declspec(dllexport)/_declspec(dllimport) business, it would be #defined
empty with GCC.


For those interested in more details, here is the status: We have a
basic libdbus DLL and the daemon - the remaining issues are not
insurmountable, I've just been concentrating on adapting the core
protocol functionality for our in-house application (MSVC 2003 uncovered
some elusive array bounds overruns in the test suite, so sorting that
out was a [time consuming] priority). What's missing:

1. unix: domain socket transport is not available (only loopback tcp:
right now) Natural replacement would be named pipes, and the most
significant hurdle is the pervasive use of ints for all file descriptors
(pipes, sockets). Need to decide whether to ditch the
winsock2-compatible ints in favor of HANDLEs for everything (and
undertake the associated socket code refactoring), or treat sockets vs.
pipes/files separately.

2. no security (getuid/getgid returns zero for everyone and credential
exchange is always successful). Because of the Windows SID format UID
needs to be a string, not an int. dbus_uid_t already abstracts this, but
need to touch up all the places where variables get compared, allocated,
etc. Doesn't look hard, just lots of things to verify with the
underlaying type changing so significantly.

3. no component activation (dbus-spawn.c is mostly #ifdefe'd out). Not
sure if there is potentially any API impact here - the bus daemon only
appears to call dbus_spawn_async_with_babysitter(), so that currently
always fails on Win32. The main challenge there is some significant
refactoring of the babysitter logic, because of the usual fork() issues
that will have to be probably replaced by threads that communicate via
[synchronized] shared memory instead of the unix pipes. An easier
alternative might be a dedicated lightweight babysitter process that
communicates with bus via anonymous Windows pipes, that model maps more
directly into the existing layout of dbus-spawn.c

4. no way to disable verbose mode (no vararg macros in MSVC 6/7). VC8
(2005) is supposed to have this, haven't tried it yet.


Cheers,

Martin


----
Martin Kosina
Intel Corporation / JF4-356
Hillsboro, Ore. 97124, USA 
+1-503-712-8162