I have made an additional test with network files instead of files on the
disk.
To do it exactly like Windows, ReadFileEx() should check for a end-of-file
condition.
It there are any bytes to read from the file, it should return TRUE.
After that, when the thread goes into the alertable
Am Die, 2002-11-26 um 09.11 schrieb Martin Fuchs:
And yes, there is: If you read the same files as before, but now using a
network connect (even if the files are located on the same computer), now
Windows behaves a bit different. The completition function IS called in this
case with
Would the patch below satisfy your needs? It will call the completion
function with SUCCESS if any data was read (case (b)) and with EOF
otherwise. Thinking about it, this is also consistent with the EOF
conditions I've seen elsewhere (and my previous attempt wasn't:-().
This does still not
Am Die, 2002-11-26 um 19.28 schrieb Martin Fuchs:
Yes. Now my program does read the files without problems under wine.
Contradicting to the real windows environment overlapped file i/o is not very
fast, but at least it works. :-)
Sure. In Wine overlapped IO is probably slower than
Am Sam, 2002-11-23 um 11.54 schrieb Martin Fuchs:
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
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
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
My results in Windows XP showed the following results:
(The same would be true for Windows NT or 2000)
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
Hi again! ;-)
After investigating the problem a bit more, I found a better solution:
The completition function should NOT be called with STATUS_END_OF_FILE.
Instead ReadFileEx() should report the error, if there's no more to read.
This patch works better for me, although I don't think, it is a
Hi Mike!
What sort of file handle is the program trying to read from? Is it a
serial port, a socket, a pipe or a standard file?
-debugmsg +file,+comm,+server,+winsock should generate a good enough trace.
Mike
It's a standard file.
I think, there's missing the error code in the OVERLAPPED
Hi Martin,
I've attached the interesting section of the resulting trace file.
Maybe you see, what's going on.
The programs reads a file with 21517 bytes length.
After fetching five blocks of 4096 bytes correctly, it reads the remaining
1037 bytes. But it does not stop! It reads this last
Hi Martin,
What sort of file handle is the program trying to read from? Is it a
serial port, a socket, a pipe or a standard file?
-debugmsg +file,+comm,+server,+winsock should generate a good enough trace.
Mike
Martin Fuchs wrote:
Hi!
I've got an application, which uses an asynchron file
Thanks, Martin!
EOF conditions are nasty. Seems we got it wrong... Please try the
following patch (it should solve your problem). However I guess it needs
regression testing because it changes overlapped ReadFile() semantics
drastically. If this condition turns out to be right, we may
Hi!
I've got an application, which uses an asynchron file stream library. I uses
ReadFileEx() and alertable wait with SleepEx().
This doesn't work right with wine. It seems to get caught in an endless loop.
Wine and wineserver together use 100 % cpu power.
Does anyone already know, what's
14 matches
Mail list logo
