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