Win32 Port of D-Bus

[Havoc Pennington]

Hi,

Kosina, Martin wrote:
> 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);
> 

I believe it's possible to use a separate symbols file? (doesn't gtk do so?)

If so, this file can be autogenerated because all symbols not starting 
with "_" are guaranteed public. We could do things like make the build 
fail on unix if a symbol is missing, or something. Again maybe glib/gtk 
already have this solved someway as they use a similar "_" convention.

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

Maybe a simple abstraction around file descriptors / winsock / HANDLE 
would be good and help isolate the platform specifics... #ifdef should 
be as limited as possible, and type safety (e.g. for files vs. sockets) 
cross-platform if possible. Don't be afraid to rearrange existing code 
when required.

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

Suggest doing this (and probably the file abstraction) with a fully 
opaque type (dbus has lots of examples already). This way it's very 
clear what the primitive operations are, and we can know the code isn't 
"cheating" anywhere. Any "cheat" functions should have _unix_ or _win32_ 
in the name (there's a little bit of API like that already).

Feel free to split out discrete units of functionality from 
dbus-sysdeps.c into their own files as needed.

> 3. no component activation (dbus-spawn.c is mostly #ifdefe'd out).

My guess is, it'd be cleaner to simply have a whole separate setup on 
win32 than try to make dbus-spawn.c portable.

Don't make a big #ifdef mess to avoid changing code in the daemon or 
changing internal API; those things are fine to change. Even external 
API change is worth considering if it avoids a hack that's going to be 
broken all the time.

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

Can you use a no-op inline function instead of a macro maybe?

VC2005 has a free version ("Express") you could play with.

Havoc