Hi Jaques,
Please try the following patches and see if they change the results you see:
http://www.winehq.com/hypermail/wine-patches/2002/04/0020.html http://www.winehq.com/hypermail/wine-patches/2002/04/0021.html
(the second one is the relevant one in this context, but it requires the other to be applied first).
Apart from that, I have a few remarks on your posting:
I have been looking at those two functions and some specs. My understanding is that those function do not work at all in overlapped (async mode).
I have done a fair bit of testing on these very recently and think they do work. On what sort of file (regular, serial port, pipe, ...) are you reading/writing ?
Currently (latest stuff in CVS), both function handle overlap mode like this
This has been so for quite a while.
a) Give it a try in synchronous mode using a combination of pread/read and pwrite/write.
b) If not enough bytes were read or written, a request is sent to wineserver to perform and asynchronous operation. This request always fail. (don't know why yet).
What do you mean by "fail" ?
There is two problem here. If step a succeed, no event will ever be generated since step be is not performed. Application doing the following sequence
That's right. This is what the MSDN specs say:
<quote from ReadFile specs> If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the read operation starts at the offset specified in the OVERLAPPED structure and ReadFile may return before the read operation has been completed. In this case, ReadFile returns FALSE and the GetLastError function returns ERROR_IO_PENDING. This allows the calling process to continue while the read operation finishes. The event specified in the OVERLAPPED structure is set to the signaled state upon completion of the read operation. </quote>
The function may, but doesn't have to, return before the operation completes. Whether the event is signaled upon immediate completion is unclear. But then, compare the GetOverlappedResult spec:
<quote from GetOverlappedResult spec> The results reported by the GetOverlappedResult function are those of the specified handle's last overlapped operation to which the specified OVERLAPPED structure was provided, -->and for which the operation's results were pending<--. A pending operation is indicated when the function that started the operation returns FALSE, and the GetLastError function returns ERROR_IO_PENDING. When an I/O operation is pending, the function that started the operation resets the hEvent member of the OVERLAPPED structure to the nonsignaled state. Then when the pending operation has been completed, the system sets the event object to the signaled state. </quote>
(-->arrows inserted by me<--).
This is a bit clearer and indicates that the following code you quote:
ReadFile .. WaitOnSingleObject
is wrong unless the return state and error code of ReadFile() are checked between the two statements - WaitForSingleObject() should only be called if ReadFile fails with ERROR_IO_PENDING.
My understanding is that step a should never be done and only step b. Is that correct ?
No, but see the patches above - things can be done differently.
Now, why step b is failing is another story.
Indeed, that should be further investigated.
Martin