[announce] dbus4win

[Marc Mutz]

On Tuesday April 21 2009, Thiago Macieira wrote:
> But named pipes only get worse: Windows doesn't have the concept of non-
> blocking calls like Unix does (except for sockets, which are technically
> imported from BSD).

Yeah, Heisenpipes[1] :)

> Of course, then you enter a whole new world of problems, because the
> WinSock API is full of holes, bugs and incompatibilities...
>
> I don't envy the KDAB developers here.

The biggest problem we've seen so far is broken Firewalls that block 
connections on linux2win(lo). Then again, WinCE might indeed be a nasty 
surprise, but we have QLocalSocket for inspiration, then :)

<snip>
> Let's be frank: D-Bus was written on Unix and it has Unix in mind. It's
> only natural that it uses Unix concepts.
>
> Trying to map to Windows concepts will not work in all cases. I do agree
> with Havoc that we shouldn't use Unix emulation layers, but also going full
> Windows will be more trouble than it's worth. It would also make code
> maintenance a lot more difficult (more than it will be) because of the
> differing code paths.

And even more so because of lack of Windows developers. Consider: before we 
can attract those, we need to have stuff working. Since transports are 
pluggable, I don't see a problem in starting with something _we_ understand, 
even if it's not window-ish. If we succeed, _they_ will likely implement 
additional transports that are more Window-ish, if there's demand.

Thanks,
Marc

[1] measuring their state destroys said state (in order to find out whether 
you can read from them, you need to read from them).

-- 
Marc Mutz <marc at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions