Scott W Gifford a écrit :
According to MSDN, the hEvent member of an OVERLAPPED structure can be NULL:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas... OVERLAPPED ... Members ... hEvent Handle to an event set to the signaled state when the operation has been completed. The calling process must set this member either to zero or a valid event handle before calling any overlapped functions.
A program I'm trying to run takes advantage of this, and as a result triggered a lot of these errors from Wine:
err:file:GetOverlappedResult lpOverlapped->hEvent was nullI wrote a patch that solves this, although it may not be the best solution.
If when ReadFile is called overlapped->hEvent is NULL, the patch generates a new event with CreateEventA and sets the structure member to that event. To create a unique name, it uses the hex address of the overlapped structure along with a fairly long string, which is pretty likely to be unique.
This works for the application I'm running. If this seems like a good enough solution, I can easily modify the other functions which initiate an overlapped read to do the same.
I'm not sure this is a correct fix: - you modify the passed overlapped structure (by filling in the hEvent), I'm not sure Windows does it this way - the low level functions (in ntdll) already support the case where hEvent is NULL (and recreate an internal event for the wait operation)
I'd rather say it's GetOverlappedResult which is to blame. If the hEvent is NULL, then we shouldn't return any error (as we do) but rather assume all wait operation succeed (if hEven is NULL, ReadFile and WriteFile operations are synchronous, so calling GetOverlappedResult is a no-op). But, this should be verified by small tests (and added to wine's test suite).
PS: some comments on your patch (not so useless regarding what I wrote above): - CreateEvent can take a NULL parameter (for the name) which would solve the name construction issue - you don't need to but the hEvent as a static variable
A+