Question

pourquoi la structure de déclarations à l'assemblée différents de ceux dans la documentation de l'api win32.(je viens de c++ et de tenter ma part à l'assemblée de la langue)

par exemple j'ai eu ce prototype de fonction de icezelion des tutoriels(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   

Hé, attendez...je sais que "WNDCLASSEX" de la structure, dans ma version hors ligne de la documentation de l'api win32, son déclarée....

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; 

Pourquoi est-il que l'asm version utilise DWORD seul contrairement à ce qui est dans la documentation de l'api win32?
Suis-je utiliser le mauvais docs ou quoi?et si je suis quelqu'un peut me poster un lien de téléchargement pour la documentation de l'api WIN32 signifiait pour les programmeurs asm?
Aider, je suis confus.

Édité:Voici le lien pour le tutoriel, j'ai été fait référence à:

iczelion win32 asm tutoriel 3

Était-ce utile?

La solution

DWORDS est un type 32 bits sur des fenêtres 32 bits, tout comme tous les types de la version C de la structure. Les deux sont donc compatibles.

Autres conseils

Langage d'assemblage est sans type - DWORD et autres mots-clés se contenter d'indiquer le nombre d'octets qui devrait être réservé à une entité spécifique.En fait, depuis DWORD et ses cousins ne représentent pas les opcodes/mnémoniques, ils sont vraiment caractéristiques de la macro du préprocesseur.

C/C++ types, comme ceux des autres langues, sont contraints par les règles telles que endian-ness, où le bit de signe va, ce que les distributions, les convertit et les affectations sont possibles, etc.La version C de la structure que vous avez fournie est plus spécifique que la langue de l'assembly version, mais il est compatible.

La taille de tous ces différents types C est DWORD. L'assemblage n'est pas fortement tapé - tout ce qu'il sait sur chaque variable est le nombre d'octets.

À un moment donné (Windows 16 bits), ces types avaient des tailles différentes. Pendant la migration vers Win32, ils se sont tous retrouvés comme des types de données 32 bits. En tant que tel, un DWORD est compatible avec tous, à au moins un certain degré.

Contrairement à la croyance populaire, cependant, le langage d'assemblage a (ou du moins peut) avoir des types et même une sécurité assez équitable. Par exemple, considérez ce qui se passe lorsque vous faites quelque chose comme:

mov lpszMenuName[ecx], 0

Avec lpszMenuName défini comme un DWORD, l'assembleur n'acceptera pas cela, car le «0» pourrait être un byte, un word, un dword ou (dans un monde 64 bits) un qword. Pour le faire fonctionner, vous devez ajouter (essentiellement) un casting de type:

mov byte ptr lpszMenuName[ecx], 0

Donc, l'assembleur sait que vous voulez écrire un seul octet. Alternativement, vous pouvez définir lpszMenuName comme:

lpszMenuName ptr byte

Dans ce cas, l'assembleur saura qu'il devrait le traiter comme pointant un octet sans indiquer explicitement cela à chaque fois.

WNDProc, Uint, etc., sont définis dans les en-têtes C, il n'y a donc pas d'équivalent ASM direct. Ce sont toutes des quantités de taille DWORD sur des systèmes 32 bits, c'est pourquoi ce tutoriel produit du code de travail.

En assemblage, que la structure de haut niveau ait des pointeurs ou des INT, la réalité est que leurs données de haut niveau associées sont d'octets, de mot et de DWOR , Dword est 32bits). Ne soyez pas induit en erreur en pensant que la structure dans l'assemblage est différente de la structure en C, elle est à peu près la même. L'assembleur a des types de données primitifs, quels que soient les pointeurs, les structures, etc., ce qui les distingue, c'est comment il est chargé dans un registre (selon la syntaxe):

mov eax, dword ptr [bx]

Cet échantillon d'assembleur est une démonstration du chargement du eax Inscrivez-vous avec la valeur indiquée par le bx s'inscrire, efficacement la même chose que

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

J'espère que cela aide, les meilleures salutations, Tom.

En fait, Masm 6+ prend en charge une forme de frappe, vous pouvez donc avoir votre structure dans Masm similaire à celle que vous avez en C. Mais vous devrez d'abord recréer la hiérarchie de type, et vous remarqueriez bientôt que les avantages des avantages des avantages des avantages des avantages La saisie avec MASM est en quelque sorte limitée (été là, celle-ci). Je vous suggère de Google le fichier PDF de référence du programmeur MASM 6: il explique assez clairement les goodies "HLL" dans MASM, y compris la frappe, et comprend un certain nombre d'exemples. Une copie semble être disponible sur le lien ci-dessous, mais il y en a d'autres flottant.

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top