Where can I find reference for windows functions called by asm?
Posted on 2006-09-29 12:00:54 by Diego
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
Posted on 2006-09-29 13:06:56 by XCHG
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.
Posted on 2006-10-03 14:44:00 by dsouza123
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.
Posted on 2006-10-03 17:19:50 by Ultrano
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
Posted on 2006-10-03 22:37:27 by PBrennick

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 :)
Posted on 2006-10-03 22:44:04 by Ultrano
lmfao - no comment, just lmfao  :lol:
Posted on 2006-10-04 00:15:15 by Homer
But in Win16 (aka Windows 3.0 and Windows 3.1), the MSG structure looked something like this:
MSG STRUCT
  hwnd      WORD      ?
  message  WORD      ?
  wParam    WORD      ?
  lParam    DWORD      ?
  time      DWORD      ?
  pt        POINT      <>
MSG ENDS


and POINT is 32-bits in Win16.
Posted on 2006-10-05 16:52:30 by tenkey
The world at large hasn't been using win16 for... how many years?, though :)
Posted on 2006-10-05 17:00:19 by f0dder
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.


          mov  eax, wParam              ; Get message
          and  eax, 0FFFFh                ; Just the LSWord


Paul
Posted on 2006-10-06 07:43:18 by PBrennick
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.

Posted on 2006-10-06 07:47:38 by f0dder
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
Posted on 2006-10-06 17:20:55 by PBrennick

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...
Posted on 2006-10-06 18:43:26 by f0dder
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
Posted on 2006-10-06 20:04:05 by donkey
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
though masm has a bug when extending parameters...but thats another story
Posted on 2006-10-07 09:04:59 by drizz
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.
Posted on 2006-10-07 09:40:05 by donkey