wine and asyncronous file i/o

Martin Wilck Martin.Wilck at
Mon Nov 25 05:14:19 CST 2002

Am Mon, 2002-11-25 um 11.22 schrieb Martin Fuchs:

> 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().

We must distinguish 2 cases:

a) The file pointer in the overlapped structure is already beyond EOF.
   This condition is one where ReadFileEx() should arguably react as you
   are describing.

b) The file pointer in the overlapped structure is below eof, but the
   App wants to read more than available (file pointer + number of bytes
   to read is beyond EOF). If I understand you right, in this case
   ReadFileEx() returns TRUE, sets the last error to ERROR_HANDLE_EOF,
   reads as much as it can and calls the completion function
   with an Error code of 0. Right?

This is against what MSDN says: According to
the error code for the completion function is set to ERROR_HANDLE_EOF if
"the application tried to read past the end of file", which is case b)
to my understanding. 

But of course, Wine needs to behave like Windows behaves, and not like
it's supposed to behave.

> 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.

I'd say this broken behavior. However, Windows supports it, so :-/
> 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.

We had the direct read call until a few months ago. This is ok for
regular files, but not an option for any type of FIFOs like sockets,
pipes, or comm ports. The problem we have is that in general we don't
know if a file handle passed to ReadFile()/ReadFileEx() is a regular
file or not.

> 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.

It can't hurt, although your reports on real Windows behavior are more

Please tell me the exact behavior you are observing in case a and b


Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck at
D-33106 Paderborn 

More information about the wine-devel mailing list