Where can I find reference for windows functions called by asm?
I believe this question has already been answered zillion times in this forum but what the heck. Here is where you can find the Windows SDK:
http://msdn.microsoft.com
http://msdn.microsoft.com
Do a search for the file win32.hlp
The functions and parameters use C
but the assembly equivalent is usually similar.
Also some VB sites (pre .NET) cover WinAPI functions
which is usefull if you know the assembly equivalents.
The functions and parameters use C
but the assembly equivalent is usually similar.
Also some VB sites (pre .NET) cover WinAPI functions
which is usefull if you know the assembly equivalents.
No matter from asm or C or C++ - it's the same code you call, the same import-libraries, and ultimately - the same DLLs. All assembler packages have the definitions of the procedures, plus the libraries - thus you just use "invoke FuncName,params,..".
By default, the calling convention of WinAPI is "STDCALL" - meaning the function must clean the parameters from the stack itself.
In the "C-call" convention, the calling code must clean-up the stack (i.e "add esp,16"). It's only used by the function "wsprintf".
WinAPI's C things like "HANDLE", "HDC","HBITMAP" are all 32-bit integers. Even the WPARAM is 32-bit, despite some (probably old) remarks in the Win32Hlp.
So, the MSDN provides everything you need about the API. It's what all we Win32 asm coders use as a reference.
By default, the calling convention of WinAPI is "STDCALL" - meaning the function must clean the parameters from the stack itself.
In the "C-call" convention, the calling code must clean-up the stack (i.e "add esp,16"). It's only used by the function "wsprintf".
WinAPI's C things like "HANDLE", "HDC","HBITMAP" are all 32-bit integers. Even the WPARAM is 32-bit, despite some (probably old) remarks in the Win32Hlp.
So, the MSDN provides everything you need about the API. It's what all we Win32 asm coders use as a reference.
Just to be clear, WPARAM and LPARAM are both returned in the same 32 bit register. This means that WPARAM is NOT 32 bit.
Paul
Paul
MSG STRUCT
hwnd DWORD ?
message DWORD ?
wParam DWORD ?
lParam DWORD ?
time DWORD ?
pt POINT <>
MSG ENDS
And all my code for the last 5 years... against your post :)
lmfao - no comment, just lmfao :lol:
But in Win16 (aka Windows 3.0 and Windows 3.1), the MSG structure looked something like this:
and POINT is 32-bits in Win16.
MSG STRUCT
hwnd WORD ?
message WORD ?
wParam WORD ?
lParam DWORD ?
time DWORD ?
pt POINT <>
MSG ENDS
and POINT is 32-bits in Win16.
The world at large hasn't been using win16 for... how many years?, though :)
I do not think I did a good job of explaining my point. Even though it comes in a 32 bit dword, the information that is relevant is never larger than word hence you have been doing this for a long time.
Paul
mov eax, wParam ; Get message
and eax, 0FFFFh ; Just the LSWord
Paul
That's wrong too, paul - for some messages, part of your information is specified in the HIWORD, part in the LOWORD.
WM_COMMAND, for example:
wParam
The high-order word specifies the notification code if the message is from a control. If the message is from an accelerator, this value is 1. If the message is from a menu, this value is zero.
The low-order word specifies the identifier of the menu item, control, or accelerator.
lParam
Handle to the control sending the message if the message is from a control. Otherwise, this parameter is NULL.
WM_COMMAND, for example:
wParam
The high-order word specifies the notification code if the message is from a control. If the message is from an accelerator, this value is 1. If the message is from a menu, this value is zero.
The low-order word specifies the identifier of the menu item, control, or accelerator.
lParam
Handle to the control sending the message if the message is from a control. Otherwise, this parameter is NULL.
fodder,
Yeah, I give up, the whole thing is just too confusing to me. Whenever I need to access messaging services, I just copy in the archived code and let it do its thing. Sometimes, windows gives me a big headache. My wish would be for consistency.
You are brave to try to figure it all out.
Paul
Yeah, I give up, the whole thing is just too confusing to me. Whenever I need to access messaging services, I just copy in the archived code and let it do its thing. Sometimes, windows gives me a big headache. My wish would be for consistency.
You are brave to try to figure it all out.
Paul
fodder,
Yeah, I give up, the whole thing is just too confusing to me. Whenever I need to access messaging services, I just copy in the archived code and let it do its thing. Sometimes, windows gives me a big headache. My wish would be for consistency.
You are brave to try to figure it all out.
Paul
Hey, I know that feeling - I do the same, really. I spent a lot of time figuring the stuff out, though - and it wasn't all painless. And everytime you have to learn something new... *grumble*
One of the biggest problems with programming for windows is that it isn't all consistant. There's "islands of consistency"... Like, process/thread management, file management etc. - that's one area and one mindset. Basic GUI services, that's another. And then there's "common controls" which is kinda california tripping...
The worst is where MSDN is unclear or just plain wrong, for example VerSetConditionMask species a QWORD, DWORD and BYTE as parameters when it actually requires QWORD,DWORD,DWORD. Ofcourse you cannot really push 1 byte in 32 bit so it is essentially correct but very misleading...
VerSetConditionMask
VerSetConditionMask
donkey, i dont see anything wrong with that
.data
qw1 dq 0
dw1 dd 0
by1 db 0
.code
myproc proc q_:qword,d_:dword,b_:byte
ret
myproc endp
start:
invoke myproc,qw1,dw1,by1
invoke myproc,edx::eax,edi,cl
Hi Drizz,
The fact that it says it's a BYTE parameter would lead you to believe that it uses only 13 bytes of the stack (which is not possible) when in fact it uses 16 bytes. I don't use MASM and therefore don't have the problem you mentioned but using an oddity of x86-32 to push 4 bytes instead of the 1 specified is misleading, a byte is 8 bits and it is not possible to push a byte in 32 bit mode.
The fact that it says it's a BYTE parameter would lead you to believe that it uses only 13 bytes of the stack (which is not possible) when in fact it uses 16 bytes. I don't use MASM and therefore don't have the problem you mentioned but using an oddity of x86-32 to push 4 bytes instead of the 1 specified is misleading, a byte is 8 bits and it is not possible to push a byte in 32 bit mode.