winDBus authentication stage

[Alp Toker]

I have some managed D-Bus (http://www.ndesk.org/DBusSharp) users who are 
connecting to the winDBus daemon on Win32.

They are using the "tcp" transport and made a couple of observations:

1) winDBus doesn't accept a null byte at the very start of the stream. 
My users had to modify the managed tcp transport not to send the null 
byte. I had the impression that this byte would always be sent and 
accepted to provide consistency with other transports where it is used 
to provide peer credentials.

2) The EXTERNAL authentication mechanism used on the winDBus tcp 
transport seems to require a global atom representing the user SID as a 
string (where the unix uid would usually be as a string). What is the 
the reasoning behind this?

I'd like to provide interoperability between managed D-Bus and winDBus 
in my next release, so please advise as to whether (1) is a bug or a 
feature and whether I should integrate code to provide the functionality 
required by (2).

Cheers!