this patch tries to implement a small part of the extended Winsock 2 functionality in Wine. It is very experimental, I have only made sure everything compiles. It is _NOT_ intended for people to try and run.

I am submitting this patch because I am pretty new to Wine hacking and I'd appreciate some Wine gurus to audit this for obvious stupidity, style incompatiblities, etc.

Features implemented:

• WSAAccept(), including callback functionality.
• WSASocket(): support for dwFlags parameter.

The real difficult stuff will follow when I start looking into WSARecv(), WSASend(), and WSAGetOverlappedResults().

Thus it'd be nice if someone pointed out my misconceptions before I put real work into the latter.

I will leave it to someone else to comment on the meat of the matter but still, here are a couple of comments:

* To answer your question:
/* Code copied largely from WSOCK32_accept() */
/* FIXME: Can we simply call WSOCK32_accept() instead ? */
/* I wasn't sure because of the AsyncSelect stuff at the end,
which presumably should only be called if the connection is accepted */

Winsock2 should not call the wsock32 library. It should be the opposite. One of the things on my todo list (but whether I will have time to actually do it is another matter) is to reorganize the winsock libraries so that wsock32 and winsock are together in dlls/wsock32. The reason is that they both implement the winsock1 API except one is 16bit and the other 32bits. Then in dlls/winsock we would be left with just ws2_32 which implements the winsock2 API. So having ws2_32 call to wsock32 is not going in the right direction :-)

• I am currently working on a big reorganization of the winsock headers (I'm a bit late in resubmitting my patches but I will resubmit them) so there is going to be a clash with 'winsock2.h'. But don't worry about it too much. I will try to integrate all the changes in your current patch in my version before submitting it. Then you will only have to take care of any later additions.
• Also, to give you a heads up, the prefix for all functions will switch from 'WSOCK32_' to 'WS_'. Well, it's not that hard to deal with.
• I don't think you need to specify which structures/fields are unsupported in the header file. After all they could be unsupported in one function and supported in another. I see that you also put this info in the relevant functions so it should be enough.

Looks good to me. Welcome to the Wine project. It's always good to have some new blood.

i don't know much about Winsock, but i can tell you how overlapped I/O is supposed to work in Wine.

The bulk of the implementation is in files/file.c and scheduler/synchro.c. When ReadFile is called on a handle, the following happens:

1. check that the handle is valid and was opened with FILE_FLAG_OVERLAPPED.
2. attempt to read any data that is available immediately, and perhaps return if we read enough already.
3. queue the operation onto CurrentTeb()->pending_list

When the thread waits upon any server object, all (unix) fds with pending overlapped operations are polled on. This is a minor problem in the design; if the thread never waits upon an object the overlapped can never complete, however the thread must wait upon the overlapped's hEvent to check whether it has completed...

The only part of the serial comms overlapped implementation the lives in the wineserver is the calculation of overlapped timeouts.

So to get winsock to do overlapped, you may have to modify the winsock code to work like that... but the winsock code uses the service thread to wait upon sockets. The task is definitely not impossible, but it might take a bit of work :-)

Maybe Ove K. can give you some advice?

Not really, the wineserver does the grunt work. The service thread is only used to implement WSAAsyncSelect, to post messages when the wineserver says that it should. Winsock2 code is unlikely to use WSAAsyncSelect, they'd rather do either WSAEventSelect (which doesn't use the service thread, but is 100% wineserver-based), *or* overlapped I/O.

The challenges for winsock2 should be pretty much the same as those for implementing something like ReadFileEx (which you've probably already done) and the above-mentioned overlapped ConnectNamedPipe.

I see a severe problem with the current overlapped I/O implementation, especially wrt extending it to Winsock2 overlapped I/O.

The problem I see is with buffer ordering.

For normal files, the file position from which to read is on the OVERLAPPED struct. This was not in the Wine implementation, the patch in my last email fixes it.

For sockets and other FIFOs, this makes no sense. In this case Windows specifies that buffers are read / written **in the same order they were submitted**. This matters only if users spawn several asynchronous I/O requests at the same time, but this is allowed and actually beneficial for application performance (at least on Windows).

Unless I oversee something essential, the current wine implementation does not guarantee such behaviour. Actually, since new requests are inserted at the head of the NtCurrentTeb() list, they will be considered first in subsequent asynchronous reads - i.e. the order will be reversed. If I/O requests don't complete in a single read() or write() call, the ordering will be basically random.

IMO this implies that for sockets, asynchronous reads and writes must be scheduled such that only one request for a given socket is actually reading at a time, and all others are blocked until this request is finished. Again, this holds only for FIFO-type files.

With the current structure, it seems to be very complex to sort this out. One could recheck the fd list in check_async and remove duplicate fds. One could also try to "lock" the fd somehow. Still it would be necessary to ascertain that the correct request gets the lock first.

With this min mind, it seems more natural for me to organize the asynchronous requests in the "file" data structure itself. One would have a reader's and a writers's list there, and make sure that for FIFOS only the first list element can actually issue a read(), write(), send(), or recv() system call. For normal files all elements in the lists could be doing IO at the same time, question is if that makes sense or not.

As I see it, this would mean both the readers and writers lists must be stored in the file data structure in the wine server. This would of course strongly affect the current implementation.

Note that with Winsock2 overlapped I/O in place, it must be possible to use also ReadFile(), ReadFileEx() etc. on overlapped sockets, and get correct behaviour. Thus the ReadFile() etc. code must be able to deal with both sockets and ordinary files, and it makes no sense to intriduce a different approach for sockets only.

You're right, i never considered multiple overlapped requests at the same time...

To fix the problem correctly, you will need to move (some of) the overlapped code back to the wineserver, so that requests from different processes can be handled correctly. (i moved it out of the wineserver about a year ago for efficiency reasons.)

Have a look at rev 1.7 of server/async.c to see how this worked.

http://cvs.winehq.com/cvsweb/wine/server/async.c?rev=1.7

The current overlapped code (with the above exception) is similar to what win 9x supports, so it does not support overlapped on normal files, and file offsets in OVERLAPPED structures. If that could be implemented too, it would be good.

i guess there is choice now... implement overlapped sockets with the existing structure, or make a rather large change to the wine architecture, which might take a while.

Maybe a good first step is to back out my change which put overlapped operations into the client side code... Alexandre thought this could be done using POLLIO instead...

You cannot use .lib files directly with Winelib. The reason is that winebuild does not support reading .lib files. Support for '.lib' files (or possibly even '.dll' files) could be added in but it is not there currently.

Exactly how you deal with that depends on what your situation:

1. if you have the sources of the library you want to link with, then the best solution is to compile it with Winelib too.
2. if you don't have the sources for this library (and it's not one of the standard Wine libraries), then you will have to write a stub library that you will use for just the purpose of linking your application.

In both cases you will need to create a '.spec' file containing a list of the functions (with parameters) exported by that library. See the following URL for a documentation of the exact format of .spec files:

http://wine.codeweavers.com/docs/winelib-user/spec-file.shtml

Case 1:

The '.spec' files generated by Winemaker are mostly useful for compiling applications that just import libraries. When Winemaker generates the build environment for a library it will not declare the exported functions in the '.spec' file because it has no knowledge of which functions are exported. Winemaker could potentially be extended to generate a list of exported functions when the '.dll' is available by interfacing it with winedump.
   So if your library only exports a few functions, the easiest solution is to just declare them manually in the '.spec' file. Otherwise you should use winedump much as described in case 2, and then copy the .spec file over to where you compile your library.

Case 2:

Generating a stub library: the best way to do so is to use winedump. For that I recommend that you read 'tools/winedump/README' and especially the section 'Generating stub DLLS'.
   Once you have linked your application with the stub library, it can run with just the native dll... unless we are talking about a C++ library.
   C++ libraries are troublesome because g++ does not use the same name mangling as Visual C++ (although maybe g++ 3.0 changed that). So you will need the stub library to do the bridging. But I am not sure whether winedump can handle this sort of bridging.

There is another roadblock that you may hit in both cases: winebuild does not support importing a variable from another library (because of ELF limitations). Importing functions is ok, but not variables. This means that if you are dealing with a C++ library you will need to link with it in the Unix sense. If we are talking about C code, then there are ways around it that require only relatively simple code changes. It is also another reason why you will never be able to use a native C++ library directly (because the virtual table pointers are handled as variables).

One last note: specmaker has been folded into winedump recently. So if you hear/read things about specmaker you know that you have to look for winedump.

ok... getting reasonable output, but now I have some questions.

First, it seems like wine can't find the audio codecs, though it seems to find the video ones. Is this a to-be-implemented or a bug and any clues on where to look?

Please feel free to forward this on to other developers or onto the Wine list.

I read the discussion about VirtualDub crashing the Wine loader with great interest today. (It's a bit weird that the only way I heard about a problem with my Win32 program was via a Unix-oriented mailing list.) Yes, the exports header points to garbage, and yes, it was caused by UPX -- UPX left the export header RVA and size in the PE32 optional header exactly was it was in the unpacked image. You can safely hex edit the bytes at 180-187 to null to kill the bogus export directory, since it turns out I exported those functions by mistake in some hasty cut-and-paste and they aren't used.

As for other compatibility problems with Wine, I have gotten VirtualDub to run in the past under Linux, although I ran into severe problems with the handling of custom templates in GetOpenFileName() and slow updates in the trackbar common control. The last time I tried I had to remove two calls to SetUnhandledExceptionFilter() to get it to run.

One more thing: There is an undocumented Wine compatibility switch /w that you can specify on the command line to force VirtualDub to use StretchDIBits() to blit to the screen instead of a DIB section. It was a workaround for an old problem where Wine wouldn't mark a GDI DIB section dirty if it was written to through an aliased, memory-mapped section.