[Fwd: Re: D-BUS on Windows?]

[Havoc Pennington]

On Mon, 2004-11-29 at 06:56 -0600, Jon Trowbridge wrote:
> - There are some source files that are called *-unix.[ch], even if
>   they mostly aren't that Unix-specific, just contain more or less
>   nromal socket API calls. Would is still be better to just copy them
>   as *-win32.[ch], and modify appropriately, even if the bulk of the
>   code would be identical in the "unix" and "win32" versions? Or use
>   the *-unix.[ch] files also on Win32 (and modify them to use wrapper
>   functions/macros from dbus-sysdeps.[ch])?

This is my big question as well - do we want to create a sockets
abstraction in dbus-sysdeps.c and use the same code everywhere else,
or do we want dbus-transport-win32.c

My best guess is as follows:

 - duplicating all of dbus-transport-unix.c is probably a bad idea. 
   However we could potentially factor a lot of it out into 
   a base class and then have win32/unix subclasses.

 - from the point of view of the .conf file, we should treat whatever 
   the Windows transports are the same way we do pipes vs. unix domain 
   sockets vs. tcp sockets - that is, a distinct address 
   format for example. I'd expect to have different default .conf 
   files on Windows.

 - for the uid/gid I think we should use the sid on Windows, if the 
   user-based distinctions are even interesting on Windows; 
   basically we should allow writing a security policy which makes 
   sense for Windows using normal Windows access control and 
   identity mechanisms. 
   A fair starting point for now would be to just not allow 
   any of the uid/gid stuff on Windows, since it isn't 
   relevant for the session bus anyhow.

 - in short we want to use Windows native stuff, rather than 
   making the conf file all UNIX-looking and somehow making it run 
   on Windows

 - my suggestion is to figure out a conf file and public APIs 
   that are sensible for Windows, then implement that by 
   wrapping the Windows stuff thinly in dbus-sysdeps.c 
   (e.g. just have a _dbus_listen_windows_socket() perhaps)
   with #ifdef in the rest of the code, then figure out 
   whether/how we can do a higher-level "GIOChannel" type 
   of abstraction in dbus-sysdeps.c to drop the other 
   #ifdefs ... maybe actually doing some of those steps
   can be skipped, but conceptually I'd think of it that 
   way...

 - I don't want to have "ambiguous" file descriptor integers
   or something like that anywhere; it should be 100% clear
   at all points in the code whether an integer is an 
   abstraction windows/unix exported by sysdeps, or a UNIX 
   fd specifically...

Some thoughts, Tor is the expert here.

Havoc