Win32 Port

[Kosina, Martin]

Ralf Habacker wrote:

> to become a little familar with the stuff I tried to hack the sources
to 
> see how complicate a port would be. Tcp connections are mostly working

> and some data could already be exchanged, but test_names does not
finish 
> it's call. probably as Martin Kosina already stated.

> - initialisation of winsock library in dbus-sysdeps-utils-win32.c

I'd like to ask for suggestions on this, as well - it's a perenial
question for ported libraries that wrap Winsock. Any natural place this
could happen in the dbus stack? For now, I added something similar -
_dbus_win32_init() - but is there another place we could stick it that
would hide this [silly] step? It just needs to execute once (that could
be handled by a static flag) before any Winsock calls are made.

> - fixed socket/file incompatible write/read functions -> 
> dbus-sysdeps-win32.c has now a isSocket(), which are used in 
> _dbus_read/_dbus_write

Just curious - is your isSocket() something like _get_osfhandle()<0 ? Or
did you find a better WinAPI that answers the handle type precisely ?

> native _dbus_directory_open() , _dbus_directory_get_next_file () 
> implementations (not tested complete)

Got those working, as well, the usual FindNextFile() stuff with handles,
etc.

> - Because there are several places changed and some new files are
added 
> i've created a tarball at
http://webdev.cegit.de/snapshots/kde-windows/dbus-win

Thanks for sharing that - few other run-time things I had to add to mine
that turned out to be crucial:

- Sockets must be set non-blocking (this is pretty important or things
won't work right):

In _dbus_set_fd_nonblocking (), I used:

	u_long NonBlock;
	if (ioctlsocket(fd, FIONBIO, &NonBlock) == SOCKET_ERROR)
	{
		....
	}

- In dbus-transport-unix():do_reading(), I had to check
WSAGetLastError() == WSAEWOULDBLOCK (errno == EAGAIN won't give the
right answer with Winsock). Same with writing, when the descriptor is a
socket.

- vnsnprintf() is used to check required buffer size - the POSIX variant
returns the number of bytes that are required, on Windows the function
simply fails. _dbus_string_append_printf_valist() relies on the former
behavior.

Looks like we had couple different philosophies - I #ifdef'ed and
re-implemented individual calls or small blocks in the original
dbus-sysdeps* files, ala Tor's diff. The amount of platform-specific
linecount is ultimately pretty low, so duplicating lot of otherwise
independent logic seemed somehow undesirable. But the dual-file approach
has its merits, as well, so its ultimately up to the maintainers - which
approach is preferable? 

Cheers,

Martin

----
Martin Kosina
Intel Corporation / JF4-356
Hillsboro, Ore. 97124, USA 
+1-503-712-8162