Issue with _dbus_write_socket on windows

Ralf Habacker ralf.habacker at freenet.de
Fri Nov 17 14:14:12 PST 2006


Havoc Pennington schrieb:
> Ralf Habacker wrote:
>> Havoc Pennington schrieb:
>>> 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?
>
spawn
> btw what is the answer here? (where do you guys have the windows code
> btw, can we look at the work in progress?)
>
Peter has answered already
>> 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.
>
> Maybe Windows should only have "autolaunch" and never start the daemon
> on login; unlike unix there might be a more reliable way to implement
> autolaunch. How does the registry solution work in terms of locking,
> i.e. say two buses start up simultaneously in the same session, one
> should exit and not be used. Is there a way to lock a registry entry
> or something that allows that to work?
> For the mugshot client we did single instance COM object with
> RegisterActiveObject() - that seems like one option. I'm not sure how
> it works if the user logs in multiple times (is that even possible?)
> though.
>
We are just starting to dig into this autolaunch stuff, which seems to
have much interests :-)
There are Registry based Security setting functions in the win32 api,
but I'm not sure at now, if these functions will fit our needs.
An other way is to use file locks on well known path.  For this the
LockFile(Ex) functions are usable

Windows desktop pc's are mainly single graphical user (except you are
using cywin sshd or similar to have more than one shell based session)
Windows Terminal Server are designed to run more parallel graphical
sessions. Here there is more work required to archive a uniq session
dbus-daemon. I think people will contribute to this area if it is time
to implement it.
Ralf



More information about the dbus mailing list