RFC: Winsock todo's - wine-devel

24 Sep 2002


      This is a RFC for comments.
I may currently be the "offical" winsock maintainer in wine, but I wrote
only a very small part of the code. I invite everybody, especially the
authors of the other parts of winsock, to comment on these opinions.
On Son, 2002-09-22, 18.48 Thomas Wickline wrote:
...
Can you give me a update on winsock todo's ?
And any other todo that you are aware of ..
I have received very few bug reports lately, so I guess the basic
Winsock functionality is working. A few important patches went in after
the latest CVS snapshot, though.
In general, the Winsock implementation in wine has a few parts that look
really hackish and would need substantial cleanup. IMO this applies to
the async.c file in total, but maybe I am doing injustice to authors of
that file. I just find the code is really hard to read.
Things like the User-space callbacks in WSAAccept() are impossible to
implement correctly because the Unix accept() system call doesn't
support callbacks.
I do not like the fact that some Winsock1 calls, in particular select(),
use direct system calls instead of  using related wine APIs, e.g.
WaitforMultipleEvents(). Actually if you have sockets with overlapped IO
this may cause havoc. Changing this seems to be an average-difficulty
task, suitable for contributors with some insight into wine internals.
I'd like to see this fixed before 1.0.
There are quite a few stubs left in ws2_32.spec.
Some of these can probably be implemented easily and would be good work
for beginners or casual wine contributors looking for a simple task,
e.g. WSADuplicateSocketW(), WSAAddressToString[AW], WSAHtonl().
More unit tests need to be written, also a nice task for people
interested in Winsock.
Wine has no concept of the Winsock2 "provider" interface. All calls to
these functions are either stubs or dummy functions, such as
WSAEnumProtocols(). I had a patch for this, but never got it ready for
prime-time. It is unrealistic to support a "real" provider interface,
allowing (like Windows) to hook new protocol handlers in the network
stack, but at least we should pass some realistic information to
clients. Should be done for 1.0.
There is no such thing as a QOS or socket group concept in wine either,
but these seem to be rarely-used features -> post-1.0, if needed at all.
Although I had a relevant part in implementing the asynchronous IO in
winsock, I am not quite content with it because it is not really
asynchronous. Alexandre is against using threads. On Linux at least, Ben
LaHaise's asyncio can be expected to become part of the 
2.6 kernel series, and if that happens the wine asynchronous IO
functionality should be rewritten to use the asyncio API on systems that
support it. (I still havent't figured out whether aio will support
sockets, though).
A non-winsock todo that comes to my mind is support for NT security
concepts such as tokens. But that would be a big one and should probably
also be postponed after 1.0
Martin
-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy