Le début de tout : cherche "Hello World" en ASM pour Windows

Bonjour tout le monde,
Il y a quelques décennies j'utilisais MASM, ça se pourrait bien que j'y revienne.
Là j'ai Visual Studio d'installé. Avec ça il y a ML64, qui officiellement doit pouvoir compiler de l'assembleur.
Ah oui mais ... Encore s'agit-il de ne pas avoir oublié quelques bricoles.
Il fallait un programme tout prêt pour être sûr que la syntaxe soit bonne, alors j'ai copié le code de cette page :
https://github.com/s0lst1c3/hello.as...ster/hello.asm
pour le mettre dans le fichier HelloWorld.asm,
puis j'ai lancé

Code:

---

ML64 HelloWorld.asm

---

et ça m'a répondu ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Microsoft (R) Macro Assembler (x64) Version 14.16.27030.1 Copyright (C) Microsoft Corporation. All rights reserved.   Assembling: HelloWorld.asm HelloWorld.asm(1) : error A2008:syntax error : global HelloWorld.asm(3) : error A2008:syntax error : in directive HelloWorld.asm(5) : error A2008:syntax error : section HelloWorld.asm(6) : error A2034:must be in segment block HelloWorld.asm(7) : error A2034:must be in segment block HelloWorld.asm(9) : error A2008:syntax error : section HelloWorld.asm(10) : error A2034:must be in segment block HelloWorld.asm(11) : error A2034:must be in segment block HelloWorld.asm(12) : error A2034:must be in segment block HelloWorld.asm(13) : error A2034:must be in segment block HelloWorld.asm(15) : error A2034:must be in segment block HelloWorld.asm(17) : error A2034:must be in segment block HelloWorld.asm(17) : error A2088:END directive required at end of file

---

Ouais ... Ben j'ai la fâcheuse impression que ça ressemble davantage à une suite de messages d'erreurs qu'à un compte-rendu de compilation réussie.

Alors quelle est l'interprétation ?
Mauvais compilateur, changer compilateur ?
Mauvais programme, changer programme ?
Option manquante ?
Mauvais opérateur, changer opérateur ?

Le code asm montré , ça ressemble fortement à du code pour Nasm ou pour GCC/GNU Assembler :mrgreen:
Et puis mème si ça compilerait , ça marcherai pas sur Windows , 0x80 est une interruption pour Linux ;)

Ah ...
C'est vrai que j'étais plus familier de MOV AX que MOV EAX, mais chez Intel ça a bougé aussi, ça, alors ça ne m'a pas choqué.
J'ai fait confiance à Google :)

Qu'est-ce que je prendrais bien comme programme pour tester ?

Euh non je parlais pas de la syntaxe des mnémonique qui sont les mêmes (vu que tout les assembleur utilise la syntaxe Intel quasiment).
Mais plus la syntaxe du préprocesseur comme global _start , section .data etc etc

Oui chez intel ça a bien bouger vu que même EAX n'est plus trop d'actualité :mouarf:
De nos jours on manipule des registre 64 bits donc rax ;)

Pour le code montré il faut faire ceci pour l'éxécuter :

Code:

---

1 2 3 4

; assemble: nasm -f elf64 -l hello.lst hello.asm ; link: gcc -o hello hello.o ; run: ./hello

---

(Sur Linux donc)

OK OK, c'est bien ce qu'ils indiquent d'ailleurs, mais j'avais compris que ça pouvait fonctionner "aussi" sur Linux.

Pour Windows 10, tu me conseillerais quoi ?
C'est vrai que je pourrais piocher dans le forum pour trouver un programme qui tourne ...

Je n'utilise jamais Windows (et techniquement je ne fais jamais d'asm sur PC pour dire :aie: ).
Il y'a pas mal d'habitué ici qui utilise Windows + l'asm faudra attendre leur réponse ;)

OK merci. C'est bizarre de mettre les deux dans le même forum, et en même temps ça m'arrange, autrement ma question pouvait toujours attendre :)

Il s'agit ici d'un code assembleur pour Linux, pas pour Windows.

Il te faudrait faire un truc du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

.data       texte db 'Hello world!', 0   caption db 'Titre', 0       .code       main proc   push 0 ;MB_OK   push offset caption ;lpCaption   push offset texte ;lpText   push 0 ;hWnd   call MessageBoxA   push 0   call ExitProcess   main endp       end

---

Il doit manquer la déclaration des fonctions Windows.

Mais avec Visual Studio, tu devrais pouvoir faire un truc comme :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

int main() { cont char texte[]="texte"; const char caption[]="titre";   _asm { push 0 ;MB_OK mov eax,offset caption push eax ;lpCaption   mov eax,offset texte push eax ;lpText   push 0 ;hWnd   call MessageBoxA   push 0   call ExitProcess   } }

---

Pas dit que ça compile direct, je peux pas tester, mais tu as l'idée générale.

MessageBoxA est la fonction qui permet d'afficher une boite de dialogue, avec le texte de ton choix. la valeur hwnd correspond au handle de la fenêtre ou placer la boite de dialogue, avec une valeur 0, messageboxA va créer sa propre fenêtre (sans habillage).
Sur le même principe, tu dois pouvoir utiliser la focntion prinftf avec une application console, ou probablement une fonction spécialéisé windows du genre writeconsole (nom donné comme ça, vérfiier existence).

Tu pourras observer que la méthode d'appel de fonction système diffère de Linux.

Citation:

---

Envoyé par chrtophe

Il s'agit ici d'un code assembleur pour Linux, pas pour Windows.

---

Je ne sais pas si tu as remarqué, là-dessus, Kannagi a été rapide, sympa, précise.

Citation:

---

Il te faudrait faire un truc du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

.data       texte db 'Hello world!', 0   caption db 'Titre', 0       .code       main proc   push 0 ;MB_OK   push offset caption ;lpCaption   push offset texte ;lpText   push 0 ;hWnd   call MessageBoxA   push 0   call ExitProcess   main endp       end

---

Il doit manquer la déclaration des fonctions Windows.

Mais avec Visual Studio, tu devrais pouvoir faire un truc comme :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

int main() { cont char texte[]="texte"; const char caption[]="titre";   _asm { push 0 ;MB_OK mov eax,offset caption push eax ;lpCaption   mov eax,offset texte push eax ;lpText   push 0 ;hWnd   call MessageBoxA   push 0   call ExitProcess   } }

---

Pas dit que ça compile direct, je peux pas tester, mais tu as l'idée générale.

MessageBoxA est la fonction qui permet d'afficher une boite de dialogue, avec le texte de ton choix. la valeur hwnd correspond au handle de la fenêtre ou placer la boite de dialogue, avec une valeur 0, messageboxA va créer sa propre fenêtre (sans habillage).
Sur le même principe, tu dois pouvoir utiliser la focntion prinftf avec une application console, ou probablement une fonction spécialéisé windows du genre writeconsole (nom donné comme ça, vérfiier existence).

Tu pourras observer que la méthode d'appel de fonction système diffère de Linux.

---

Voilà déjà un début, merci. D'ailleurs, moi non plus je ne vais pas le faire avant Dimanche.
L'affichage d'un message ça crèche quelque part dans l'interruption 21h, si je me rappelle bien.
Peut-être la fonction 9 ?

Alors l'interruption 21h est une interruption MS-DOS qui n'existe plus sur Windows depuis belle lurette :mrgreen:
Pour Windows , il faut passer par l'API Windows pour afficher quelque chose (d'où l'appel de fonction MessageBoxA ).

Allez bon, ça aurait été trop simple !

C'est là que ça se passe ?
https://docs.microsoft.com/en-us/win...ser-messagebox

Ah il y en a quelques-unes en dessous ...

Bon OK je vais voir ça, merci.

Alors même en assembleur on appelle les DLL ?

Citation:

---

Envoyé par Gluups

Alors même en assembleur on appelle les DLL ?

---

Pourquoi est ce si étonnant ?
Un code compiler appelle bien des fonctions (qui se trouve dans des DLL) , et l'assembleur un langage assez proche du code machine et pas mal de compilo compile en asm avant de de le mettre en langage machine (donc appelle à des fonction extern qui se trouve dans des DLL).

Sur un OS , tu sera de toute façon obligé de passer par l'API ou une fonction externe que ça soit en asm ou en C , l'OS ne te permettra jamais de toucher au hardware.
(c'est aussi une autre raison qu'on conseille pas forcément de faire de l'asm sur un PC + OS , l’intérêt devient quasi-nul surtout que niveau optimisation les compilateurs x86 sont très performant).

À propos, pour une application console, je suppose que c'est une autre API qu'il faut appeler, pour afficher un texte ?

Je pense que pour la console, le mieux reste d'utiliser l'API pour le langage C , donc printf et compagnie ! :p

Ah oui à ce point-là ?
En fait, si je veux un programme qui contienne tout son code, ne fasse pas appel à une plate-forme sous-jacente (comme les programmes .Net), C est peut-être une meilleure idée que l'assembleur ?

Ben oui clairement , non seulement ça sera plus facile à l'écrire mais ton code sera mieux optimiser que si tu le code en asm (sauf si tu es un expert en asm).

J'ai pratiqué les deux, enfin il y a 25 ans, à ce que je me rappelle, avec Turbo C, le programme est beaucoup plus gros que le même en assembleur, parce que le Turbo C introduit tout le contenu des bibliothèques mentionnées, alors qu'en assembleur on met juste le code dont on a besoin, donc pour afficher un message et demander un choix, il y en a pour 30 octets (enfin pour un appel à l'Int 21h), plutôt que 4064. Et du coup je comptais dessus pour avoir tout dedans, mais c'est vrai que ça dépend quand même du système. Hum, pour un disque de démarrage Macrium, ils ont vraiment réinventé l'eau tiède, ou c'est des choses comme le pack .Net qui manquent ?

En revanche c'est vrai que si on veut quelque chose de lisible, les langages de haut niveau sont plus faits pour.
Ou il ne faut pas être trop avare en commentaires.

Citation:

---

avec Turbo C, le programme est beaucoup plus gros que le même en assembleur, parce que le Turbo C introduit tout le contenu des bibliothèques mentionnées, alors qu'en assembleur on met juste le code dont on a besoin

---

sous MS-DOS, il n'y avait pas de dll, le code des fonctions de type printf devait donc être intégré à ton code. Et printf c'est quand même plus compliqué qu'un simple appel à ah=9 int 0x21.

Citation:

---

il y en a pour 30 octets (enfin pour un appel à l'Int 21h), plutôt que 4064

---

Par rapport à la remarque précédente, j'ajouterais aussi qu'un compilateur C ne va pas chercher à faire le code le plus court en nombre d'octet, mais le code le plus efficace. Par exemple, si tu fais une boucle for avec un nombre fixe et faible de boucle, le compilateur va faire un déroulage de boucle, càd copier le code de la boucle autant ds fois que celle-ci doit être exécutée, le code sera plus long en terme d'octets, mais plus rapide car il n'y aura pas de tests à faire sur la valeur controlant le nombre d'itération de la boucle. Par ailleurs, un fichier .exe doit avoir un en-tête qui va occuper de l'espace, variable selon le nombre de fonctions, constantes et variables utilisées dans le fichier, contrairement au format .com, qui occupant que 256 octets de mémoire.
D'autre part, le code est alignée sur des adresses mémoires multiples de 4 voire 16, ce qui fait perdre également de la place.

Citation:

---

Hum, pour un disque de démarrage Macrium, ils ont vraiment réinventé l'eau tiède, ou c'est des choses comme le pack .Net qui manquent ?

---

Je ne connais pas le produit, mais je pense leur disque de démarrage est fait avec un environnement PE. Un peu comme les système préinstallés des constructeurs qui installent Windows plus d'autres logiciels automatiquement. Un membre dvp a fait un tutoriel sur la création d'un CD de maintenance en environnement WinPE, je te conseilles de le consulter. Tu peux intégrer un soft que tu as développé toi-même tant que tu y mets les dlls dépendantes. Pour .net, c'est théoriquement faisable (pas sûr à 100% sans avoir testé), mais un peu plus de boulot pour l'intégration à mon avis.

Citation:

---

Envoyé par Kannagi

Pourquoi est ce si étonnant ?
Un code compiler appelle bien des fonctions (qui se trouve dans des DLL) , et l'assembleur un langage assez proche du code machine et pas mal de compilo compile en asm avant de de le mettre en langage machine (donc appelle à des fonction extern qui se trouve dans des DLL).

Sur un OS , tu sera de toute façon obligé de passer par l'API ou une fonction externe que ça soit en asm ou en C , l'OS ne te permettra jamais de toucher au hardware.
(c'est aussi une autre raison qu'on conseille pas forcément de faire de l'asm sur un PC + OS , l’intérêt devient quasi-nul surtout que niveau optimisation les compilateurs x86 sont très performant).

---

Ok alors bonjour les gens moi c'est nul de chez nul qui a pas une foutu base en quoi que ce soit qui touche a l'assembleur et qui se pose une question. Tu dis que ça ne sert a rien sur pc+os. Alors tu peux utiliser l'assembleur sur quoi ?? Sur un pc sans OS ? ( Là même moi jsuis sur que je dis une connerie mais bon xD chut):mouarf:

Citation:

---

Envoyé par viper1094

Ok alors bonjour les gens moi c'est nul de chez nul qui a pas une foutu base en quoi que ce soit qui touche a l'assembleur et qui se pose une question. Tu dis que ça ne sert a rien sur pc+os. Alors tu peux utiliser l'assembleur sur quoi ?? Sur un pc sans OS ? ( Là même moi jsuis sur que je dis une connerie mais bon xD chut):mouarf:

---

T’inquiète Pas. Il y a pas mal de contre-vérités dans ce qui a été écrit précédemment, souvent nourries de fantasmes d’ailleurs. Je ne vais pas répéter ici ce que j’ai écrit ici en diverses occasions. La seule chose vraie, c’est qu’il y a 20 ans, tu gagnais à tous les coups en utilisant l’assembleur. Aujourd’hui, il te faut maîtriser toutes les techniques d’optimisation pour un résultat tangible. C’est d’ailleurs ça, l’intérêt de l’assembleur, aussi...