Hi Izak,
The wineserver may also change the status of the request to STATUS_SUCCESS after a certain timeout is reached. The problem is most likely that the timeout is not being calculated properly.
The code to do that is in server/async.c and server/serial.c.
The timeouts are set by the SetCommTimeouts call. Try using the +serial debug channel to see what timeouts are being set. The parameters to the ReadFile command may also be important - check whether it is being called with an overlapped structure or not.
Mike
Izak Burger wrote:
trace:ntdll:FILE_AsyncReadService 0x42295b4f 0x42295fe1 1 trace:ntdll:FILE_AsyncReadService read 1 more bytes 9/1040 so far, io_status->u.Status=0x103
The tracing of io_status->u.Status was added by myself. I'm not sure if the problem is not perhaps caused by the fact that u.Status is always 0x103 (STATUS_PENDING) and never becomes 0x0 (STATUS_SUCCESS). Of course, if I change the FD_TYPE to FD_TYPE_SOCKET, the result is always STATUS_SUCCESS, which is probably what the app wants. Not knowing much about the API or how Windows implements it (haven't programmed in the windows environment for 7 years now) I'm not even sure if this is some kind of a windows quirk exploited by this app.
If my experience with unix in general is anything to go by, then it would be acceptable to provide a 1040 byte buffer, and read as much data into it as you can (which is almost always less than the 1040 you _could_ theoretically read in one go), then return STATUS_SUCCESS. Is it the same for windows? Obviously the above code will return STATUS_PENDING until it has read 1040 bytes, and only then will it return STATUS_SUCCESS.