Issue with _dbus_write_socket on windows

[Havoc Pennington]

Hi,

Looking at the code you guys have in svn, it seems like the big question 
is how the session bus gets started. On unix, we have two answers:

  - normally, the session bus is started by X init scripts and then
    located with an environment variable

  - as a fallback, the bus can be autolaunched and then have its address
    stored in a file in the home directory that is
    per-machine-per-X-display

On Windows, I think just one answer is probably fine:

  - the bus is always autolaunched, and only one instance of
    it exists at a time (using whatever mechanism tbd)

My guess is that the --print-address is not useful because the mechanism 
for ensuring uniqueness will have to have a way to get the address of an 
existing bus that someone *didn't* spawn themselves. Which means there's 
no point having a special alternate mechanism if you did spawn the bus 
yourself.

If you did it the way you are now, it looks like you're passing a handle 
from _pipe() down to the child. Looking at MSDN, I get the impression 
that this kind of handle is not interoperable with the native handles 
e.g. if you used CreatePipe() (why not use CreatePipe() btw?). But maybe 
these handles are interchangeable? I don't know.

In any case, I would not name the thing in question here write_stream() 
since this can't be just any stream; it can't be a socket; it has to be 
a pipe. So I'd name the function write_pipe() or write_file_handle() or 
something like that. I don't know Windows well enough to make the right 
choice.

In general all the _pipe(), _open() API is some kind of weird 
unix-compat hack that wraps the real Windows API isn't it? For this 
windows-specific code I don't see much point using this unix compat API.

Havoc