Ayuda en la API WIN32 en la Asamblea

Question

¿Por qué las declaraciones de estructura en el ensamblaje son diferentes de las de la documentación de la API WIN32? (Vengo de C ++ y probando mi lenguaje de ensamblaje)

Por ejemplo, obtuve esta función prototipo de los tutoriales de Icezelion (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   

Oye, espera ... Sé que la estructura de "wndclassex", en mi versión fuera de línea de la documentación de la API Win32, se declara como ...

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; 

¿Por qué es que la versión ASM usa DWORD, contrario a lo que está en la documentación de la API WIN32?
¿Estoy usando los documentos equivocados o qué? Y si soy alguien, ¿puede alguien publicarme un enlace de descarga para la documentación de la API Win32 destinada a los programadores de ASM?
Ayuda, estoy confundido.

Editado: Aquí está el enlace al tutorial al que me refería:

Tutorial ASM WIN32 de ICZELION 3

Answer 1

Las DWORDS son un tipo de 32 bits en ventanas de 32 bits, al igual que todos los tipos de la versión C de la estructura. Por lo tanto, los dos son compatibles.

Answer 2

El lenguaje de ensamblaje no tiene la palabra: otras palabras clave simplemente indican el número de bytes que deben reservarse para una entidad específica. De hecho, dado que DWORD y sus primos no representan códigos OP/mnemonics, realmente son características del preprocesador macro.

Los tipos de c/c ++, como los de otros idiomas, están limitados por reglas como endian-ness, donde va el bit de signo, lo que se encuentran, conversos y tareas, etc. La versión C de la estructura que proporcionó es más específica que La versión del lenguaje de ensamblaje, pero es compatible.

Answer 3

El tamaño de todos esos diferentes tipos de C es DWORD. El ensamblaje no se escribe fuertemente: todo lo que sabe sobre cada variable es el número de bytes.

Answer 4

En un momento (ventanas de 16 bits) estos tipos tenían diferentes tamaños. Durante la migración a Win32, todos terminaron como tipos de datos de 32 bits. Como tal, un DWORD es compatible con todos ellos, en al menos cierto grado.

Contrariamente a la creencia popular, sin embargo, el lenguaje de ensamblaje (o al menos puede) tener tipos e incluso una seguridad de tipo bastante justo. Solo por ejemplo, considere lo que sucede cuando haces algo como:

mov lpszMenuName[ecx], 0

Con lpszMenuName definido como un DWORD, el ensamblador no aceptará esto, porque el '0' podría ser un byte, a word, a dword o (en un mundo de 64 bits) un qword. Para que funcione, debe agregar (esencialmente) un elenco de tipo:

mov byte ptr lpszMenuName[ecx], 0

Entonces el ensamblador sabe que quieres escribir un solo byte. Alternativamente, puedes definir lpszMenuName como:

lpszMenuName ptr byte

En cuyo caso, el ensamblador sabrá que debería tratarlo como apuntando a un byte sin indicar explícitamente que cada vez.

Answer 5

WNDProc, Uint, etc., se definen en los encabezados C, por lo que no hay ASM directo equivalente. Todas son cantidades de tamaño DWORD en sistemas de 32 bits, por lo que ese tutorial produce código de trabajo.

Answer 6

En el ensamblaje, independientemente de si una estructura de alto nivel tiene punteros o ints, la realidad es que sus tipos de datos de alto nivel asociados son de byte, word y dword, en su caso, la estructura son todos 32 bits, por lo tanto, dWord (una palabra es 16 bits , DWord es 32bits). No se engañe en pensar que la estructura en el ensamblaje es diferente a la estructura en C, es muy similar. El ensamblador tiene tipos de datos primitivos, independientemente de los punteros, estructuras, etc., lo que los distingue es cómo se carga en un registro (dependiendo de la sintaxis):

mov eax, dword ptr [bx]

Esta muestra de ensamblador es una demostración de cargar el eax Regístrese con el valor señalado por el bx registrarse, efectivamente lo mismo que

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

Espero que esto ayude, Saludos cordiales, Tom.

Answer 7

De hecho, MASM 6+ admite una forma de escritura, por lo que podría tener su estructura en MASM similar a la que tiene en C. pero primero tendrá que recrear la jerarquía de tipo, y pronto notará que los beneficios de La escritura con MASM está de alguna manera limitada (he estado allí, hecho eso). Le sugiero que busque en Google el archivo PDF de referencia del programador MASM 6: explica claramente las golosinas "HLL" en MASM, incluida la escritura, e incluye una serie de ejemplos. Una copia parece estar disponible en el siguiente enlace, pero hay otras flotando.

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