Nouveaux Concepts: Utilisation de WinAsm
et MASM32 Nouvelles fonctions de l'API: ExitProcess
|
Utilisation de WinAsm La capture d'écran suivante illustre les différentes parties de l'interface de WinAsm. Le code source que vous saisissez apparaît dans le volet de l'éditeur de code (à gauche). Le volet de l'explorateur (à droite) affiche les fichiers qui font partie du projet en cours, y compris le code ASM, les fichiers d'inclusion, les ressources, etc. Dans la capture d'écran, le pointeur de la souris indique le bouton "Go All" qui, lorsqu'il est cliqué, assemble et lie votre code source, puis exécute le fichier résultant. Les commandes transmises à l'assembleur et au lieur, ainsi que les résultats, sont affichés dans le volet de sortie (en bas).
"Les 7 lignes de code ci-dessus représentent le plus petit programme qui sera réellement assemblé, lié et exécuté. Il se compose d'une seule instruction RET à l'entrée, qui, lorsqu'elle est exécutée, renvoie immédiatement le contrôle à Windows. Afin de transformer cela en un squelette utile autour duquel construire de vrais programmes, nous remplaçons le RET par un appel à ExitProcess - l'API standard pour quitter une application." "Afin de commencer à coder, ouvrez WinAsm et cliquez sur le bouton le plus à gauche de la barre d'outils. Notez que j'ai désactivé le gestionnaire de projets récents au démarrage et j'utilise le complément New Project Wizard, qui est une amélioration considérable des fonctionnalités existantes - voir ici. Si vous configurez votre système de la même manière, vous devriez voir ceci :
Cliquez sur Suivant, puis sur Terminer. Le type de projet Standard EXE est mis en surbrillance par défaut, ce qui définit les options d'assemblage et de liaison pour produire un exécutable Win32 GUI. WinAsm vous demandera de sauvegarder le nouveau fichier de projet et le nouveau fichier ASM, après quoi vous verrez l'écran vide de l'éditeur de code. Collez maintenant skeleton.asm de la section Sourcecode de ce fichier dans la fenêtre de l'éditeur de code. En cliquant sur "Go All", vous serez d'abord invité à sauvegarder le projet et le fichier asm dans un emplacement approprié avant de construire et d'exécuter votre fichier. Votre code devrait ressembler à ceci (consultez l'annexe 1 s'il y a des erreurs ou si la coloration syntaxique est désactivée) : Nous allons maintenant analyser cette ligne par ligne. La plupart de ce code représente des directives (instructions pour l'assembleur). Il n'y a qu'une seule ligne de code de programme réel - l'appel à la fonction API ExitProcess. .386 - Indique à MASM d'utiliser l'ensemble d'instructions Intel 80386. .model flat, stdcall - Spécifie le modèle de mémoire plat (flat memory model) et la convention d'appel standard (standard call calling convention). option casemap:none - Spécifie que les labels doivent être sensibles à la casse. include kernel32.inc - Indique à MASM de traiter le fichier portant le nom spécifié (comme si son contenu était copié dans la section sourcecode ici). includelib kernel32.lib - Indique au linker avec quelles bibliothèques d'importation effectuer la liaison (dans ce cas, kernel32.lib). .data - spécifie que les données initialisées (variables ayant une valeur de départ) sont placées ici. .data? - spécifie que les données non initialisées (variables n'ayant pas encore de valeur) sont placées ici. L'espace est alloué lorsque le programme est chargé en mémoire, mais la taille du fichier sur le disque n'est pas augmentée. .const - spécifie que les constantes sont déclarées ici. .code - spécifie que le code exécutable est placé ici. start: - étiquette arbitraire pour spécifier le début du code (notez que l'étiquette est suivie de ":" lorsqu'elle est déclarée pour la première fois). invoke ExitProcess,0 - l'exécution commence ici, à l'instruction immédiatement en dessous de l'étiquette spécifiée par la directive end. Il n'y a qu'une seule instruction ici, qui appelle la fonction API ExitProcess, méthode préférée pour terminer un programme et rendre la main à Windows. end start - marque la fin du module et définit le point d'entrée du programme sur l'étiquette spécifiée (notez que l'étiquette n'a pas besoin de ":" ici car elle a été déclarée précédemment). L'API Win32 L'API Windows (Interface de programmation d'applications)
comprend une vaste collection de types de données, de constantes,
de fonctions et de structures utilisés pour créer des applications
pour le système d'exploitation Windows. La plupart des fonctions de l'API,
y compris ExitProcess que nous avons utilisé précédemment, sont stockées dans 3 DLL principales : Si vous utilisez des fonctions de l'API Windows dans votre programme, votre programme doit "importer" les fonctions à partir des DLL. Les bibliothèques d'importation (.lib) contiennent les informations dont le linker a besoin pour résoudre les appels aux fonctions résidant dans les DLL, afin que le système puisse charger la DLL spécifiée et localiser les fonctions exportées nécessaires lors de l'exécution de votre code. Par exemple, pour appeler la fonction ExitProcess qui réside dans kernel32.dll, vous devez lier votre code avec la bibliothèque d'importation kernel32.lib. Cependant, le fichier de bibliothèque n'est pas la seule chose dont vous avez besoin. Un fichier d'inclusion (kernel32.inc) est également nécessaire. Les fichiers d'inclusion (.inc) contiennent les "prototypes" qui définissent les attributs de toutes les fonctions stockées dans la DLL du même nom. Ils peuvent être générés automatiquement à partir des fichiers de bibliothèque à l'aide de l'utilitaire lib2inc. Il n'y a pas de moyen facile de générer un fichier de bibliothèque à partir d'une DLL donnée, mais heureusement, la plupart des fonctions de l'API dont vous aurez besoin sont situées dans des DLL pour lesquelles la distribution MASM32 dispose de fichiers de bibliothèque appropriés. La documentation officielle de l'API Win32 est écrite pour les programmeurs C et C++, et une fonction API typique est définie selon le format suivant : ReturnType FunctionName ( ParamType1, ParamName1, ParamType2 ParamName2,...); En utilisant la fonction SetWindowText comme exemple à partir de la référence du programmeur Win32 : La syntaxe en C peut être facilement convertie en assembleur. Le mot BOOL est le type de données que la fonction est censée retourner en tant que résultat et peut être ignoré. HWND est répété une fois pour représenter la taille et le type de données fournies à la fonction (en réalité, juste un DWORD ici - ces types de données Windows sont tous définis dans le fichier windows.inc dans C:\masm32\include) et une deuxième fois comme nom des données (ici, cela signifie "handle de fenêtre"). C'est vraiment beaucoup plus simple en assembleur - les variables ou constantes dont la fonction a besoin sont PUSHées sur la pile et la fonction est CALLée par son nom : PUSH lpString Notez qu'en assembleur, les paramètres sont PUSHés sur la pile dans l'ordre inverse par rapport à la définition C de Win32.hlp, de droite à gauche. C'est la convention d'appel STDCALL qui est utilisée presque exclusivement en ASM Windows. Maintenant que vous savez comment utiliser les définitions API de Win32.hlp, vous pouvez vous y référer pour obtenir des explications sur les fonctions API que nous utiliserons lors de ces tutoriels. Utilisation de Invoke Inclure des prototypes dans votre code source présente 2 avantages en MASM. Le premier est que l'instruction INVOKE peut être utilisée à la place de la séquence traditionnelle PUSH/CALL. INVOKE est plus compacte et les paramètres n'ont pas besoin d'être disposés dans l'ordre inverse : INVOKE SetWindowText, hWnd, lpString Le deuxième avantage est qu'INVOKE permet une vérification des types, de sorte que le linker peut signaler une erreur si des paramètres incorrects sont passés à la fonction dans votre code. Les prototypes de fonctions individuelles peuvent être ajoutés manuellement dans le code plutôt que d'inclure un fichier .inc complet, mais ils doivent apparaître avant les instructions INVOKE. L'utilisation de prototypes et d'invoke peut être appliquée aux fonctions que vous écrivez vous-même, comme nous le verrons plus tard.
|
Copyright (C)- xtx Team (2021)