On 7 Jan 2002, Alexandre Julliard wrote:
But in our case Wine would be considered the service provider, so we can use the structure.
I wondered about that ... A "service provider" in Winsock terminology is something that implements low-level protocols below the winsock layer. To my understanding the winsock layer itself may not use it (the OS TCP/IP stack could :-). However, this may be a misunderstanding or overinterpretation on my part.
It seems you should be able to use the existing code by providing a different async_handler function, and storing the needed information in the WSAOVERLAPPED structure. That would be cleaner than having the low-level file I/O routines know about winsock structures.
Do you _really_ consider it "clean" to use the WSAOVERLAPPED fields for arbitrary, unrelated Wine-internal data? The code would have to be full of comments like /* Note: overlapped->OffsetHigh is the user-supplied struct sockaddr pointer */ I do not intend to make the low-level file I/O functions know anything about winsock. In the worst case i would have something like this in synchro.c (Pseudocode): struct async_private *ovl; if (ovl->type & ASYNC_TYPE_WINSOCK) { struct async_winsock *aws = (struct async_winsock*) ovl; aws->completion_func ( [4 arguments] ); } else { struct async_fileio *af = (struct async_fileio*) ovl; af->completion_func ( [3 arguments] ) } The only way to avoid these (admittedly unelegant) constructs is to use yet more function pointers, like ovl->call_completion_func (ovl); where ovl->call_completion_func would be a function that "knew" the number of arguments to pass to te completion function. As I said in the last mail, since we are talking about only 2 alternatives, the use of function pointers may be more elegant, but a little exaggerated to my taste. Martin -- Martin Wilck <mwilck(a)freenet.de> Physicist & Linux system engineer at FSC <Martin.Wilck(a)Fujitsu-Siemens.com>