push 0 appearing in between a function call ?

[gelatine1]

Hello, another question once again... (I hope I'm not bothering too much)

Code Select Expand


invoke WriteFile, fhandle, [pmem], [bytesToWrite], edx, ecx


my code crashed, okay, I checked the debugger but I saw something very weird. The function above got assembled like this:


I have no clue where this 0 comes from and I think it's not really normal. I believe it may be the cause of the crash (not sure though) but I have no clue what caused it or how to solve it.

Anyone knows what's going on ?

Thanks in advance,
Jannes

[dedndave]

the problem is....
bytesToWrite is defined as a WORD and should be defined as a DWORD

it would appear that the assembler is trying to maintain stack alignment

[jj2007]

it would appear that the assembler is trying to maintain stack alignment

it would appear that the assembler (ML 6.14 or 6.15) is doing a lousy job: the push 0 is a dword :(

BTW, JWasm and ML 10 do it correctly via movzx eax:

push ecx                                   ; pOverlapped
push edx                                   ; pBytesWritten
movzx eax, word ptr [bytesToWrite]
push eax                                   ; Size
push dword ptr [pmem]                      ; Buffer = 123456
push dword ptr [fhandle]                    ; hFile = 11111111
call WriteFile                              ; KERNEL32.WriteFile


Which does not mean that anybody here or at MSDN endorses using a WORD for bytesToWrite, Jannes

[dedndave]

that's an official bug, then

it should burp, "Invalid argument size", or something of that nature

[dedndave]

it's already on the list of known masm bugs - same for BYTE argument, as well

[KeepingRealBusy]

Dave,

Which version of MASM?

Dave.

[dedndave]

it seems to be 6.14 and 6.15, at least

Andreas (Japheth) keeps a list, i guess

[hutch--]

MASM bug = MASM feature you have not adapted to. 

[ragdog]

Hi

A bug in Masm?!?

i have test it withhout push 0 and word ptr
I use masm32v10

Code Select Expand


.data
fhandle dd ?
pmem dd ?
nsize dd ?

invoke WriteFile, fhandle, [pmem], [nsize], edx, ecx


Code Select Expand


00401000 >/$  51            PUSH ECX                                 ; /pOverlapped = NULL
00401001  |.  52            PUSH EDX                                 ; |pBytesWritten = Console.<ModuleEntryPoint>
00401002  |.  FF35 08304000 PUSH DWORD PTR DS:[403008]               ; |nBytesToWrite = 0
00401008  |.  FF35 04304000 PUSH DWORD PTR DS:[403004]               ; |Buffer = NULL
0040100E  |.  FF35 00304000 PUSH DWORD PTR DS:[403000]               ; |hFile = NULL
00401014  |.  E8 43000000   CALL <JMP.&kernel32.WriteFile>           ; \WriteFile

[jj2007]

it seems to be 6.14 and 6.15, at least

Andreas (Japheth) keeps a list, i guess

Indeed, and it's bug #1 :P

[gelatine1]

Thanks for the help guys!
Indeed when I changed bytesToWrite to a dword everything worked well :)

   Which does not mean that anybody here or at MSDN endorses using a WORD for bytesToWrite, Jannes 

Well I thought, bytesToWrite is small anyway so why not use a word (and save some very precious ram memory.. :p ) but I guess that was just a stupid idea :D

[dedndave]

ragdog....
try defining one of those as a WORD

Code Select Expand

.data
fhandle dd ?
pmem dw ?
nsize dd ?

[jj2007]

...so why not use a word (and save some very precious ram memory.. :p ) but I guess that was just a stupid idea :D

The idea as such is a good one, but Windows tends to be very strict regarding the parameters passed 8)
Go here and follow step 7 to get an old but incredibly useful *.hlp file that will show you which parameters to pass.

[ragdog]

Thanks Dave

But i think is not really a bug by Masm only by the user

[dedndave]

well - the bug is: masm should report an error in argument size
or maintain stack alignment, somehow