programmation avec MSNA dans Windows XP

Question

J'ai le code suivant qui assemble et fonctionne très bien sur Windows XP 32 bits, 02/09/08 MSNA:

; how to compile: nasm -f elf test.asm 
; how to link: ld -o test.exe test.o 

section .data 

section .text 

;global _WinMain@16 
;_WinMain@16: 

;global _start 
_start: 
    mov ax,4   

    jmp $ 

Selon de nombreux tutoriels sur MSNA le fichier asm a besoin ce qui suit dans il:

global _WinMain@16 
_WinMain@16: 
... 

Comme vous pouvez le voir, mon fichier ASM ne contient pas cela. (il est commenté, tout ce qu'il a est _start). Alors, quel est le problème avec tous ces didacticiels qui mentionnent le besoin de la fonctionnalité globale _WinMain @ 16 lorsque mon programme d'assemblage ne l'a pas et fonctionne?

est la commande pour assembler: nasm -f elfe test.asm
est la commande de lien: ld -o test.exe test.o

Answer 1

Il existe plusieurs types d'application sous Windows avec différents points d'entrée en fonction de quel type ils sont. Par l'option link.exe:

• /SUBSYSTEM:CONSOLE - nécessite main et la liaison avec msvcrXX.dll. Ces applications s'exécutent dans les fenêtres de la console; Si vous n'exécutez pas une instance de cmd.exe, une sera ouverte.
• /SUBSYSTEM:WINDOWS - WinMain est le point de départ. Voir here. Habituellement en C, ces #include <windows.h> et sont directement liés à kernel32.dll. Ces applications sont un gui et sont presque certainement liés avec user32.dll et éventuellement advapi32.dll ainsi.
• /SUBSYSTEM:NATIVE - il existe deux types d'application ici; pilotes et applications. Les applications NT natives s'exécutent au démarrage de Windows et requièrent NtProcessSStartup comme point d'entrée. Il n'y a pas de libc dans les applications natives. Les pilotes sont différents à nouveau.

Une liste complète des sous-systèmes Windows pris en charge par link.exe est disponible here.

_start est le symbole dans lequel les codes démarreront votre code. Normalement, libc ou similaire gère réellement _start et fait une configuration initiale, de sorte que votre programme ne commence pas réellement à _main. Si vous vouliez lier avec libc vous auriez des problèmes, puisque vous auriez des symboles contradictoires avec la bibliothèque libc. Si toutefois vous n'avez jamais l'intention d'appeler des fonctions faisant partie des bibliothèques standard C ou C++, vous pouvez utiliser _start.

Modifier beurk Je viens de remarquer ceci:

; how to compile: nasm -f elf test.asm 
; how to link: ld -o test.exe test.o 

Je suppose que vous n'êtes pas en utilisant l'un -f elf. ELF (format exécutable et lisible) est le format linux pour les exécutables; Windows nécessite des images PE (Portable Executable). L'option nasm est -f win32 ou pour dos nasm -f coff.

Éditer 2 Juste pour vérifier, j'ai assemblé le code et l'ai démonté à nouveau. J'ai aussi utilisé mingw.Quoi qu'il en soit, j'ai:

SECTION .text align=16 execute      ; section number 1, code 
Entry_point:; Function begin 
; Note: Length-changing prefix causes delay on Intel processors 
     mov  ax, 4         ; 00401000 _ 66: B8, 0004 
?_001: jmp  ?_001         ; 00401004 _ EB, FE 
; Entry_point End of function 
; Note: Length-changing prefix causes delay on Intel processors 
     mov  ax, 4         ; 00401006 _ 66: B8, 0004 
?_002: jmp  ?_002         ; 0040100A _ EB, FE 

Le reste de l'en-tête semble être un exécutable au format PE valide sans spécification de point d'entrée. Je crois donc que le code est simplement "tombant" sur le premier morceau du code de montage pour commencer. Je ne conseillerais pas ce comportement, en particulier lorsque vous liez plusieurs objets car je n'ai aucune idée de ce qui se passerait. Utilisez -entry.

le fichier Désassemblage objet elfe je reçois ceci:

SECTION .data align=4 noexecute      ; section number 1, data 
SECTION .text align=16 execute      ; section number 2, code 
_start_here:; Local function 
; Note: Length-changing prefix causes delay on Intel processors 
     mov  ax, 4         ; 0000 _ 66: B8, 0004 
?_001: jmp  ?_001         ; 0004 _ EB, FE 
_another_symbol:; Local function 
; Note: Length-changing prefix causes delay on Intel processors 
     mov  ax, 4         ; 0006 _ 66: B8, 0004 
?_002: jmp  ?_002  

En d'autres termes, il n'y a pas de têtes ELF-format spécifique en elle. Je crois que tu as de la chance sur celui-ci; commencer à importer ou essayer de lier avec d'autres modules de code et les choses vont commencer à devenir plus difficile.

Pour Windows/MinGW, vous voulez:

nasm -f win32 file.asm 

pour chaque fichier que vous souhaitez assembler. Remplacez win32 par win64 si nécessaire. ld fera très bien pour la liaison.

Juste une pensée - je n'ai jamais expliqué la partie @16. Les fonctions sont alignées sur 16 octets sur Windows, alors que, comme vous pouvez le constater, les données ne sont alignées que sur quatre octets. Voir this explanation pour le pourquoi.