Issue with _dbus_write_socket on windows

[Ralf Habacker]

Havoc Pennington schrieb:
> Christian Ehrlicher wrote:
>>
>> Because we implemented the _dbus_get_autolaunch_address() like unix does
>> - calling dbus-daemon and get back ip:port by printing to stdout. What's
>> wrong here?
>>
>
> I don't know exactly, since I don't know how this works on Windows. 
> What is the "fd" you pass to the daemon's --print-addr-fd function? Is 
> it a pipe or a socket or what is it? On UNIX autolaunch does a 
> fork/exec, what does it do on Windows?
>
> A larger question is why do we need autolaunch on Windows - autolaunch 
> is used in two cases on UNIX, 1) ssh to a remote machine and 
> displaying an X app on the local machine 2) logging in as another user 
> and displaying an X app on this user's display. I don't know that 
> either thing really comes up in the Windows case.
On windows services like dbus-daemon may be run as services started 
before any user logs on like in unix. Another option would be that a 
user has installed dbus but not registrated as service. In this case the 
dbus-daemon should be started on demand using the autolaunch stuff, 
which works already nice.
> How does the bus get found in the session normally? There are lots of 
> single-instance apps in Windows, we should be single-instance probably 
> using a similar mechanism. The DBUS_SESSION_BUS_ADDRESS env variable 
> doesn't seem very good on Windows 
yes
> since we have no way to arrange for it to be set for every process in 
> the session afaik, and it would require logout in any case.

We are thinking to store the recently used dbus address in the registry, 
which allows the autolaunch code to detect a running dbus-daemon  and to 
be able to connect to it.

>
> Again, don't emulate UNIX. Do what makes sense on Windows natively... 
> the command line options, config files, bus addresses, etc. can be 
> different on Windows when the UNIX versions don't make sense.
>
The use cases are different; as far as we can see does the related 
command line options (--print-address)  and already implemented 
autolaunch support located into libdbus [ i mean 
_dbus_get_autolaunch_address()] fits very well for this use cases, so we 
don't have to reinvent the wheel :-)

Ralf