MASM32's includes generally define all function parameters as :DWORD. When translated to a module-definition file, that :DWORD is worth 4 bytes for the external function definition. For example:
DllGetVersion PROTO :DWORD
would be defined in a .DEF file as:
_DllGetVersion@4
Are all function parameters passed as 4 bytes? If it was DllGetVersion PROTO :WORD, would it be _DllGetVersion@2 instead? How big are function parameters on a 64-bit version of Windows?
Queue
I believe on 32 bit windows all parameters on function calls are 4 bytes and 64 bit are 8 bytes (even if the PARAM is :WORD or :BYTE)
There are a few 32-bit Windows API functions that have 64-bit parameters. I can't think of an example at the moment though.
i can think of CRT lib functions that use qwords, but not any API functions
in the case of the CRT lib, you can push 2 dwords (high dword, then low dword) and call it a qword
at any rate, if the function only requires a byte or word, a dword is pushed to maintain stack alignment
things are similar in the 64-bit world - of course they have a larger stack alignment
i guess it's 16 bytes - even though you'd think 8 would be enough :P
Quote from: dedndave on July 03, 2010, 07:34:47 PM
at any rate, if the function only requires a byte or word, a dword is pushed to maintain stack alignment
Kinda smacking myself in the forehead here, that makes perfect sense. For some reason I was ignoring HOW parameters are sent to a function.
Thanks everyone.
Queue
Here is a 32-bit Windows API function that has a 64-bit parameter, StrFormatByteSize64 (http://msdn.microsoft.com/en-us/library/bb759971%28VS.85%29.aspx). :P
Handy function, that one.
Here is the PROTO I use for it:
StrFormatByteSize64A PROTO :QWORD,:PTR BYTE,:DWORD
StrFormatByteSize64 EQU <StrFormatByteSize64A>
With MASM32, in shlwapi.inc, StrFormatByteSize64 is defined as :DWORD, :DWORD, :DWORD, :DWORD. If you have it defined as (basically) :QWORD, :DWORD, :DWORD, what happens when you INVOKE the function passing it 3 parameters? A qword just pushes onto the stack using 8 bytes instead of a dword's 4 so there's no problem?
Queue
Remember that in 32 bit you can only push 4 bytes at one time.
Where you have a 64 bit integer as a memory operand [reg] do 2 pushes like normal to push 64 bits of data.
push [reg]
push [reg+4]
Queue,
If you use the PROTO I prefer to use, you would use INVOKE like so:
INVOKE StrFormatByteSize64, TotalNumberOfBytes, ADDR szTotalBuffer, SIZEOF szTotalBuffer
If you use the PROTO from the MASM32 includes you would use PUSH/CALL style or you could use INVOKE with macros like so:
; ====================================
; MASM 8.0 has a macro with the same name and function built in
LOW32 MACRO Q:REQ
lea edx, Q
mov eax, DWORD PTR [edx]
EXITM <eax>
ENDM
; ====================================
; MASM 8.0 has a macro with the same name and function built in
HIGH32 MACRO Q:REQ
lea edx, Q
mov eax, DWORD PTR [edx+4]
EXITM <eax>
ENDM
INVOKE StrFormatByteSize64, LOW32(TotalNumberOfBytes), HIGH32(TotalNumberOfBytes), ADDR szTotalBuffer, SIZEOF szTotalBuffer
Hutch has the include file generation automated, so there's a good reason they are like that.
Quote from: hutch-- on July 04, 2010, 01:02:33 AM
Where you have a 64 bit integer as a memory operand [reg] do 2 pushes like normal to push 64 bits of data.
push [reg]
push [reg+4]
The other way round as the stack descends.
push [reg+4] ; Param#2
push [reg] ; Param#1
On the subroutine side, the following is workable
fild qword ptr [Param1] ; or fld for a 64-bit float