Hi,
I`ve got some problems with accessing files using ReadFile function. In Win32 Programmer`s Reference I`ve found:
BOOL ReadFile(
HANDLE hFile, // handle of file to read
LPVOID lpBuffer, // address of buffer that receives data
DWORD nNumberOfBytesToRead, // number of bytes to read
LPDWORD lpNumberOfBytesRead, // address of number of bytes read
LPOVERLAPPED lpOverlapped // address of structure for data
);
I`d declared a buffer:
pBuffer DWORD ?
and allocated a memory using GlobalAlloc and GlobalLock functions.
I`d like to read 4 bytes from file, and check their value:
.if DWORD PTR pBuffer != 52494646h
jmp incorrect_file_format
.endif
Even though I`m sure that the first 4 bytes of a file are '52494646' it always jumps to incorrect_file_format :(
What is wrong?
Thanks in advance
Peter
If you are looking for a RIFF header then you need to compare your DWORD PTR pBuffer to 46464952h ('FFIR') since the processor is little-endian (I assume).
Quote
The hardware design in which the least significant bits of a multi-byte integer are stored in the byte with the lowest address. Little-endian order is the normal order in Intel processors, and optional in MIPS processors. Opposed to big-endian. (These terms are from Swift's Gulliver's Travels, in which the citizens of Lilliput and Blefescu are divided by the burning question of whether one's breakfast egg should be opened at the little or the big end.)
Not only that, but in ASM you can't get a variable's contents directly by its memory-pointer, when that pointer is stored in some memory-variable (instead of in a register). Currently you're simply comparing the address of your allocated memory to "FFIR".
mov eax,pBuffer
cmp dword ptr[eax],'FFIR'
jne incorrect_file_format
What you were doing is similar to:
mov eax,pBuffer
cmp eax,'FFIR' ; wrong line
jne incorrect_file_format
Ultrano,
are you saying that one cannot do like this?
.data
manydwords dd 1,2,3
.code
...
mov eax, DWORD PTR [manydwords+0]
mov ebx, DWORD PTR [manydwords+4]
then you're wrong
Surely you just do cmp pBuffer,'FFIR'
ETA Oops, didn't assimilate the GlobalAlloc :red
For sure mov eax,pBuffer
cmp [eax],'FFIR'
[shame]Now where's that corner[/shame]
Quote from: ramguru on March 26, 2007, 11:27:39 AM
Ultrano,
are you saying that one cannot do like this?
.data
manydwords dd 1,2,3
.code
...
mov eax, DWORD PTR [manydwords+0]
mov ebx, DWORD PTR [manydwords+4]
then you're wrong
I quickly edited my post, adding the "when that pointer is stored in some memory-variable" clarification - maybe you started reading my reply before the edit?
Some code with explanations.
If the contents of a memory variable is an address
(so the memory variable is a pointer to some buffer)
then to get the contents of the buffer,
copy the pointer to a register and use indirect addressing.
.data
Buffer db 52h, 49h, 46h, 46h, 1024 dup (50), 0
pBuffer dd 0
.code
mov pBuffer, offset Buffer
nop
mov eax, pBuffer
nop
.if dword ptr [eax] != 46464952h
jmp incorrect_file_format
.endif
The other code in question
.data
manydwords dd 1,2,3
.code
...
mov eax, DWORD PTR [manydwords+0]
mov ebx, DWORD PTR [manydwords+4]
is equivalent to
mov eax, manydwords+0
mov ebx, manydwords+4
which is using memory offsets which are resolved at assembly time
using dword ptr adds nothing in this case because manydwords already specifies dwords
and the [] also add nothing.
The dword ptr in this case is not to make something a pointer but to determine
how many bytes are to be retrieved.