Help on win32 api in assembly

Question

why the structure declarations in the assembly are different from the declarations in the win32 api documentation. (I come from C ++ and try to use assembly language)

for example, I got this function prototype from tutorials on ice cream (tutorial3)

WNDCLASSEX STRUCT DWORD cbSize DWORD ? style DWORD ? lpfnWndProc DWORD ? cbClsExtra DWORD ? cbWndExtra DWORD ? hInstance DWORD ? hIcon DWORD ? hCursor DWORD ? hbrBackground DWORD ? lpszMenuName DWORD ? lpszClassName DWORD ? hIconSm DWORD ? WNDCLASSEX ENDS 

Hey wait ... I know that the WNDCLASSEX structure in my standalone win32 api documentation version is declared as ....

 typedef struct _WNDCLASSEX { // wc UINT cbSize; UINT style; WNDPROC lpfnWndProc; int cbClsExtra; int cbWndExtra; HANDLE hInstance; HICON hIcon; HCURSOR hCursor; HBRUSH hbrBackground; LPCTSTR lpszMenuName; LPCTSTR lpszClassName; HICON hIconSm; } WNDCLASSEX; 

Why is the asm version using DWORD only contrary to what is found in the win32 api documentation?
Am I using the wrong documents or what? and if I can anyone post a download link for the WIN32 api documentation intended for asm programmers?
Help, I'm confused.

Edited . Here is a link to the tutorial I referenced:

iczelion win32 asm tutorial 3

Answer 1

DWORDS is a 32-bit type in 32-bit windows, like all types in the version C structure. Therefore, they are compatible.

Answer 2

The assembly language does not matter - DWORD and other keywords simply indicate the number of bytes that should be reserved for a particular object. In fact, since DWORD and its cousins ​​do not represent opcodes / mnemonics, they are indeed macro preprocessor functions.

C / C ++ types, like other languages, are limited by rules such as endian-ness, where the sign bit goes, what casts, conversions, and assignments are possible, etc. The C version of the structure you provided is more specific than the assembler language version, but compatible.

Answer 3

The size of all these different types of C is DWORD. The assembly is NOT strongly typed - all it knows about each variable is the number of bytes.

Answer 4

At one time (16-bit Windows), these types had different sizes. During the transition to Win32, they all turned out to be 32-bit data types. Thus, DWORD compatible with all of them, at least to some extent.

Contrary to popular belief, assembly language (or at least it can) has types and even fairly fair type safety. For example, think about what happens when you do something like:

 mov lpszMenuName[ecx], 0 

With lpszMenuName defined as DWORD , the assembler will not accept this because '0' can be byte , a word , a DWORD or (in the 64-bit version of the world) a qword . To make it work, you must add a (essentially) cast type:

 mov byte ptr lpszMenuName[ecx], 0 

So the assembler knows that you want to write one byte. Alternatively, you can define lpszMenuName as:

 lpszMenuName ptr byte 

In this case, the assembler will know that it should consider it as pointing to a byte, without explicitly specifying each time.

Answer 5

WNDPROC, UINT, etc. defined in the C headers, so there is no direct ASM equivalent. All of them are DWORD dimensions in 32-bit systems, therefore this tutorial provides working code.

Answer 6

In the assembly, regardless of whether the high-level structure has pointers or ints, the reality is that the high-level data types associated with it have BYTE, WORD and DWORD, in your case the structure is all 32 bits, therefore DWORD (a WORD is 16 bits, DWORD - 32 bits). Do not be fooled into thinking that the structure in the assembly is different from the structure in C, it is very one and the same. The assembler has primitive data types, regardless of pointers, structures, etc. What distinguishes them is how it is loaded into the register (depending on the syntax):

  mov eax, dword ptr [bx]

This assembler sample is a demonstration of loading the eax register with the value indicated by bx , essentially the same as

  int bx = 5;
 int * eax;
 ptr = & bx;

Hope this helps, Regards, Tom.

Answer 7

In fact, MASM 6+ supports an input form, so you can create your own MASM structure similar to the one you have on C. But you need to recreate the type hierarchy first, and you will soon notice that the benefits of input using MASM are like- then limited (were there, did it). I offer you a Google MASM 6 Programmer Reference PDF file: it pretty clearly explains the “HLL” likes in MASM, including text input, and includes a number of examples. One instance seems to be available from the link below, but there are others floating around.

http://www.microlab.teipat.gr/upload/arxeshy/Microsoft_MASM_Programmers_Guide_v6.zip