Variable types, PROTOs and module-definition files

[Queue]

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

[oex]

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)

[GregL]

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.

[dedndave]

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

[Queue]

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

[GregL]

Here is a 32-bit Windows API function that has a 64-bit parameter, StrFormatByteSize64.  :P

Handy function, that one.

Here is the PROTO I use for it:

Code Select Expand


StrFormatByteSize64A PROTO :QWORD,:PTR BYTE,:DWORD
StrFormatByteSize64 EQU <StrFormatByteSize64A>


[Queue]

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

[hutch--]

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.

Code Select Expand


push [reg]
push [reg+4]


[GregL]

Queue,

If you use the PROTO I prefer to use, you would use INVOKE like so:

Code Select Expand


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:

Code Select Expand


; ====================================
; 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.

[clive]

Where you have a 64 bit integer as a memory operand [reg] do 2 pushes like normal to push 64 bits of data.

Code Select Expand


push [reg]
push [reg+4]


The other way round as the stack descends.

Code Select Expand


push [reg+4] ; Param#2
push [reg] ; Param#1


On the subroutine side, the following is workable

Code Select Expand


fild qword ptr [Param1] ; or fld for a 64-bit float