Overlapped I/O + hEvent == NULL reopened + other questions

Thomas Charbonnel thomas at undata.org
Fri May 23 03:25:00 CDT 2003


I'm trying to migrate a proprietary TCP/IP client/server db application
from Windows NT to Linux using Wine, and am encountering some

* First of all the application uses overlapped I/O in an unconventionnal
way. The application scenario is as follows : Setup server socket
Call WSAAsyncSelect
On accept, create a new window associated with the new socket
Call WSAAsyncSelect for this new socket/window.
On network event on the new socket, if the FD_READ event is passed to
the WindowProc, call ReadFile with an overlapped struct, but hEvent ==
NULL On IO_PENDING_READ_ERROR, call GetOverlappedResult with bWait set
There was a thread about this on this list on November 2002 ("Overlapped
I/O without an hEvent"). At that time Martin Wilck submited a patch that
did not get commited to CVS. I got things working by slightly modifying
his patch. The idea was floating around in the November thread : in the
GetOverlappedResult function, if the bWait flag is set, then wait
calling WaitForSingleObjectEx with the socket handle passed in instead
of the overlapped structure handle. I suspect this method is unclean,
but works for me as the server app I'm trying to run instantiates a
window (thus a WindowProc) per client. I'm waiting for your comments and
suggestions on how to properly handle this.

* Next I have a problem with high network loads (maybe related to the
previous issue). When I run the sever app in Wine and access it with a
remote client, operations generating a high network load tend to be
unstable. Most of the time the client application hangs at some point, and
sometimes the server hangs too. This does not happen if I run the client
with Wine on the same machine as the server. Are they known issues with
the winsock implementation ?

* Wine used to crash because the server app called
WritePrivateProfileString with a NULL lpFileName. I fixed this by
returning FALSE if lpFileName == NULL, but I don't know how windows
handles this. The app calls WritePrivateProfileString with a proper file
name a couple of times before setting it to NULL, so I suspect windows is
caching the file name.

* The client comes with a printing helper app. They communicate through
dde. I get the 'fixme:class:get_class_ptr reading from class of other
process window' message. How is this supposed to be handled ?

* Minor remaining problems :
- the end of tooltip texts is garbled
- help doesn't work (it seems the help file name is not passed as a

Thanks for your attention,

More information about the wine-devel mailing list