Issue with _dbus_write_socket on windows

Havoc Pennington hp at
Sat Nov 18 13:04:34 PST 2006

Timothy Vismor wrote:
> The named mutex is a system-wide object. If you want one for the 
> system bus and one for each session bus, you have to devise a 
> suitable naming convention.

Found this suggestion on MSDN,

> If you are using a named mutex to limit your application to a single
> instance, a malicious user can create this mutex before you do and
> prevent your application from starting. To prevent this situation,
> create a randomly named mutex and store the name so that it can only
> be obtained by an authorized user. Alternatively, you can use a file
> for this purpose. To limit your application to one instance per user,
> create a locked file in the user's profile directory.

I *think* this is saying just use a lockfile and don't use the mutex at 
all if you want per-user, though I guess it could be saying store the 
mutex name in the lockfile.

File locking docs:

So autolaunch on Windows could use a locked file in the user's profile 
dir in place of an X selection.

The bus address could simply be stored in the locked file.

The next question is what is that bus address. Right now Windows is 
using TCP, but a problem is that it's unclear how to generate a per-user 
TCP address. I guess a random port can be picked, but that's likely to 
be evil (collide with other apps), I would think?

So it may be necessary to create a named pipe transport in addition to 
the socket transport, generate a random name for the named pipe just as 
we do for unix domain sockets, and then store the bus address (including 
name of the pipe) in the lock file.

This would mean creating a new "named-pipe:name=blahblah" kind of 
address for use on Windows.

I guess on Windows we could also use a window with messages instead of a 
named pipe, I have no idea what kind of tradeoffs there might be. The 
named pipe API _looks_ essentially equivalent to unix domain sockets...


More information about the dbus mailing list