I'm already rose this topic but nobody answer. Please, check out this code. I dont want to think this is a WinAPI bug, but I really dont know what to think about it.
Here is the simple code which describe a problem - after first cycle ReadFile did not work. The point is to open file -> read it -> close it. And once again. I can not avoid closing handle and reopen it again.

Can someone explain what's going on

My text file is 4 byte length

buf_P db "text.txt",0
bufin_len dd 4096
offsdd 10h
bufin dd 4096 dup (?)
hPdd ?
jz @@final
mov hP, eax
invoke ReadFile, hP, ADDR bufin, bufin_len, ADDR bufin_len, 0
mov ecx, bufin_len
or ecx, ecx
jnz @@read
jmp @@exit
mov bufin_len, ecx
invoke CloseHandle, hP
add offs, 10h
cmp offs, 100h
jz @@final
jmp start
invoke ExitProcess,0
end start
Posted on 2002-03-18 09:32:27 by masquer
Try separating the bufin_len variable in to two. As you will always want to read in a maximum 4096 bytes.
In its current incarnation, on each sucessive itteration of the loop it is possible for the bufin_len to dwindle away (to possibly nothing) by virtue of the fact that the itteration before the number of bytes read back could be less than the maximum...

I would suggest something along the lines of this instead:

invoke ReadFile, hP, ADDR bufin, SIZEOF bufin, ADDR bufin_len, 0

Thus making the number of bytes to read independant of the number of bytes read back (on the subsequent itteration).

Posted on 2002-03-18 09:53:28 by Mirno
Thank you very much Mirno,
How can I miss it, I dont understand. Of course, if I pass as a parameter memory variable, function will change it :stupid:

Thanks again, problem is solved :alright:
Posted on 2002-03-18 10:40:19 by masquer
Hmmm, there is some unexplainable behaviour with the ReadFile function (on Win2K).

I was replacing some VB code today with API calls to speed it up, so i replaced the standard VB OpenFile and Input functions with CreateFile and ReadFile. This was my ReadFile loop:

If oProgress.Cancelled Then Exit Sub

If ReadFile(hFile, sFileBuff, 4096, lBytesRead, structOverlapped) Then

'check if we have a version token:
....code, some string manipulation.....
...extract a version string from the file data....

End If
Loop While lBytesRead = 4096 And Len(sVersion) = 0

I found that at some unpredictable* time during processing, i would successfully open a file, read the first 4096 bytes, not find a version, loop round to read the next 4096 bytes, but the file pointer had not been moved since the first read. I had this happen on several different files. As soon as i replaced the literal '4096' with 'LenB(sFileBuff)', it started working perfectly..... bizarre....

Posted on 2002-04-15 00:37:43 by sluggy
I doubt it's a problem with windows' code... I see you're passing
a "structOverlapped" to the ReadFile call, and while I've never used
overlapped file I/O myself, I recall reading that the I/O logic is a
bit more complicated than normal file I/O - perhaps that's the cause
of the bug?
Posted on 2002-04-15 07:57:42 by f0dder