Hi Martin!
After investigating the problem a bit more, I found a better solution: The completition function should NOT be called with STATUS_END_OF_FILE.
Passing it STATUS_END_OF_FILE is of course a bug because we have to report a DOS error code, not an NT status. Please try the patch below.
Yes. That was another problem, which should be corrected.
Instead ReadFileEx() should report the error, if there's no more to
read.
Yeah, MSDN says that. I was hoping (so far) that it suffices to pass error conditions to the completion function. That should be the same to a reasonably well-written application because it must check the condition in the completion function anyway.
I've tested it under Windows XP. Windows doesn't call the completition function at all, if the file end has been reached. It simpy returns FALSE for the ReadFileEx() call, and reports ERROR_HANDLE_EOF (38) via GetLastError().
- if (ovp->lpOverlapped->Internal == STATUS_END_OF_FILE) {
ovp->completion_func( 0,ovp->lpOverlapped->InternalHigh,ovp->lpOverlapped );You report success when the condition is EOF - I don't consider that a good idea. Please try the patch below.
Yes. It's not really correct. It's only a work around. The problem with my library under wine is: If an end-of-file error code is signaled via the completition function, this is taken as an error condition. It doesn't even pass the partial last file block data to the application. And yes: It does run with "real" windows. ;-)
If you want to reproduce the exact behaving of windows with the currrent wine implementation, you have to change it a lot. You have to check file length, or try to call pread() directly in ReadFileEx(). Then call SetLastErorr(ERROR_HANDLE_EOF) and return FALSE without calling the completition function.
If you are interested, I can put a little test program on the web or send it per private mail. You could use it for testing. It simple reads a file, you can specify on the command line, and prints it to stdout.