Comment faire un .exe facilement

[fonzi]

Comment faire un .exe qui est juste une fenêtre windows 640x480 pixels, 24bits RGB, et 96mo de ram à disposition 

me faudra juste savoir pour le memory mapping où sont les inputs claviers et où sont stockés les octets des 640x480 pixels 

Ce .exe me servira de base pour coder en assembleur x86/x64


Merci

[tapomag]

Si tu veux le faire sous windows, tu n'auras pas accès à la ram video ni aux périphériques comme ça.
Tu vas devoir appeller les APIs windows.

Pas envie d'essayer de le faire sous MS-DOS ? Ça serait bien plus simple.

[fonzi]

Pourquoi pas, mais ca se passe comment avec MS-DOS ? on pourra lancer le .exe depuis windows7 ou 10 ?

[tapomag]

Je pensais que c'était pour t'amuser en assembleur , auquel cas tu aurais pu utiliser dosbox.
Le sous-système 16 bits qui donnait la main aux programmes MSDOS et permettait de les faire tourner doit avoir disparu depuis longtemps.
Je ne peux pas t'en dire plus, je n'utilise plus windows depuis bien longtemps également.

Tu n'es pas obligé de créer une fenêtre (où tu seras obligé d'initialiser des choses, tels qu'une gestion des messages, même minimaliste).
Commence par une messagebox:
https://stackoverflow.com/questions/66323292/messagebox-program-in-x86-assembly

Ça va te montrer comment utiliser l'API.

Tu utilises quel assembleur (NASM est bien pour le x86) ? Tu as un projet particulier ?

[fonzi]

Mais c'est pour m'amuser en assembleur 

Langage machine directement , j'ouvre le .exe avec un éditeur hexadécimal et copie-colle mon code en hexadécimal (oui je sais je suis fou)

mon projet c'est faire un petit jeu en assembleur x86/x64

[tapomag]

Je vois que tu as choisi la voie de la facilité.

Le langage machine, c'est dès que tu fais de l'assembleur. Les mnémoniques ont une correspondance unique avec un code hexa, et servent juste à rendre plus humain le mécanisme.

[suisseretrogaming]

Essaye Windev. C'est graphique.

[fonzi]

ok , je suis entrain d'installer windev express , je vais voir ca...


c'est juste pour faire l'init de la fenetre en 640x480 24bit 60fps , et faire une fonction main vide qui attend mon code assembleur, apres je m'en sert plus de windev hein ?

[Kristof]

ce que tu veux faire, c'est un assembleur visiblement. C'est pas evident. Pourquoi tu veux pas utiliser un assembleur existant ? 
Ah tu mentionne que tu veux taper directement des opcode en hexadecimal ... J'ai du mal a comprendre....

[fonzi]

je me suis endormi , ca a mis 2heure  à telecharger;installer windev express ...

@Kristof
un assembleur existant a-t-il des librairies pour faire facilement une fenêtre qui répond à mes critères?

[tapomag]

Regarde comment faire un programme minimaliste en C. Ça sera très proche en assembleur. Je te conseille de trouver un livre tel que "programmation de windows" (Petzold).

[xinyingho]

Je pense pas qu'on puisse faire de l'assembleur en WinDev. Et plus personne ne développe en assembleur sous Windows depuis belle lurette, à part pour optimiser certaines routines. Avec le mode protégé de Windows, c'est devenu impossible d'aller taper les ressources systèmes directement en assembleur.

Si tu veux faire que de l'assembleur, il faut le faire dans un émulateur ou une machine virtuelle sous MS DOS ou Windows 95 par exemple.

[fonzi]

Je ne veux pas faire d'assembleur avec windev , si windev alors c'est juste pour faire la fenêtre 

Un .exe qui est un écran noir de 640x480 60fps , 96mo de ram à disposition ,et rien de plus, c'est pas compliqué à faire en 2023 ?


Apres je prends un editeur hexadecimal et ouvre le .exe , cherche la fonction main et y met mon code directement

[fonzi]

Sinon peut-etre plus simple , comme ca une fois que le .exe est fait , on ne le modifie plus


il y aura 2 fichiers le .exe et le fichier avec mon code assembleur

-On clique sur le .exe , 

1-il fait la fenêtre et alloue la ram
2-il se copie en ram 
3-il copie mon fichier code assembleur en ram
4-il jump au fichier code assembleur copié en ram et fait ce qu'il y a de codé dedans puis mon code assembleur rejump dans le .exe (celui copié en ram) 
5- *il regarde mon tableau de 940ko pour les 640x480 pixels et rafraîchit les pixels dans la fenetre
6-il retourne à ''4''


*après je ne sais pas si je peux moi directement en ''4" , modifier les octets des pixels de la fenêtre , ou sinon en ''5'' dire au .exe de lire les octets des pixels dans mon tableau et lui mettre ca dans les vrai octets des pixels de la fenêtre

[fonzi]

sinon faire ca pour dosbox  

comment ca se passe pour faire ca sur ms-dos ?

[tapomag]

oui fait ça avec dosbox.

Commence par installer dosbox si ce n'est pas déjà fait.

Ensuite récupère TASM (turbo assembleur).

Et go :)

Programme le plus simple sous dos:

mov ax,4C00h ; sors , avec code de sortie 0
int 21h

Et de mémoire pour passer en VGA 320×200 (256 couleurs)

mov ax,13h
int 10h

Attention, sous DOS tu utilises le modèle processeur v86 , donc avec des segments mémoire de 64Ko, le tout limité à 640Ko (en théorie, moins en pratique).
Pour adresser davantage de mémoire, tu as EMM, XMS, le flat-mode intel (un bit à placer, mais tu dois démarrer en real-mode, c'est à dire sans gestionnaire EMM ou XMS) ou carrément un dos-extender mais ces derniers étaient plutôt réservés aux compilos C.
Le reste, je l'ai plus ou moins oublié.

Alors, bon courage , et amuses toi bien :)

[65c02]

Je ne veux pas faire d'assembleur avec windev , si windev alors c'est juste pour faire la fenêtre 

Un .exe qui est un écran noir de 640x480 60fps , 96mo de ram à disposition ,et rien de plus, c'est pas compliqué à faire en 2023 ?


Apres je prends un editeur hexadecimal et ouvre le .exe , cherche la fonction main et y met mon code directement

Pourquoi tu t'emmerde à passer par le fichier exe ?
Tu peux directement linker ton assembleur dans ton code.
C'est beaucoup plus simple.

C'est quoi le fond de ta question ?

Comment juste ouvrir une fenêtre en 640x480 ? 
Comment ouvrir une fenêtre en 640x480 et afficher un buffer ? Si oui, dans quel format ? en palette en RGB ?
Comment ouvrir une fenêtre en 640x480 sur windows ?

Et puis c'est pas tout d'afficher une fenêtre en 640x480 mais il faudrait savoir dans quel langage tu veux faire ton exe.
Parce que suivant les cas, tu va avoir un code plus ou moins complexe dans ton exe.
Tu veux le faire en C++, en python, en assembleur ?
Tu veux un petit exe ou tu t'en fout ? 
Tu veux être dépendant de dll externes ?

Tu peux le faire à la mano old school en suivant le conseil de @tapomag.
Tu peux le faire à la mano, en C/C++ avec les GDI.
Tu peux le faire comme un vieux dev indé avec SDL.
Tu peux le faire comme un vieux nostalgique avec OpenGL.
Tu peux le faire comme un vieux pro avec DirectX.
Tu peux le faire comme un jeune pro avec Vulkan.
Tu peux le faire comme un gars qui n'a pas le temps en python avec PySDL2.

Bref, ce n'est pas simple de répondre à ta question.

C'est quoi ton objectif ?
La découverte de l'assembleur en jouant avec des effets graphiques ?

[fonzi]

le fond de ma question c'est comment faire une fenetre .exe qui fonctionne ainsi :

Il y aura 2 fichiers le .exe et le fichier avec mon code assembleur


On clique sur le .exe , 

1-il fait la fenêtre et alloue la ram
2-il se copie en ram 
3-il copie mon fichier code assembleur en ram
4-il jump au fichier code assembleur copié en ram et fait ce qu'il y a de codé dedans puis mon code assembleur rejump dans le .exe (celui copié en ram) 
5- *il regarde mon tableau de 940ko pour les 640x480 pixels et rafraîchit les pixels dans la fenetre
6-il retourne à ''4''


*après je ne sais pas si je peux moi directement en ''4" , modifier les octets des pixels de la fenêtre , ou sinon en ''5'' dire au .exe de lire les octets des pixels dans mon tableau et lui mettre ca dans les vrai octets des pixels de la fenêtre


le langage du .exe n'est pas important 

Mon code assembleur n'a besoin de rien , juste de pouvoir lire les  inputs clavier.
Il fait un buffer 24bit RGB

Je veux pas découvrir l'assembleur , je veux faire un .exe , puis y mettre mon code assembleur

[65c02]

Alors, ok, mais en ce n'est pas si simple.
C'est interdit de copier d'exécuter du code en ram.
Ils veulent éviter les stack overflow à tout prix.
Le processeur et l'O.S. ne te permettront pas cela.

D'ailleurs, on n'accède plus directement à la VRAM depuis un baille.
Tout est parallélisé à mort.
C'est fini le temps du modeX.

C'est peut être possible de contourner les sécurités avec un gros effort de hacking, mais cela semble bien un effort incroyable juste pour conserver un design bancal

Si ton but c'est de te simplifier la vie : perdu.

La meilleure solution me semble être dosbox + tasm + tu bosses en vga fullscreen

[Kristof]

je me suis endormi , ca a mis 2heure  à telecharger;installer windev express ...

@Kristof
un assembleur existant a-t-il des librairies pour faire facilement une fenêtre qui répond à mes critères?

"assembleur" ne rime pas avec "facilement" donc pas de solution a ton probleme.

Si jamais tu veux faire du code minimaliste, regarde sur pouet.net les demos en 64, 128 ou 256 octets. Ca utilise des commande bas niveau en assembleur pour init un écran et afficher des choses dedans. Mais c'est hyper pointu et très difficile. Comme tu dis "je veux pas apprendre l'assmbleur", j'ai toujours rien compris a ce que tu veux faire lol. Bon courage.

[fonzi]

Je fais de l'assembleur depuis des années , j'ai pas besoin d'apprendre à faire de l'assembleur

[65c02]

Je fais de l'assembleur depuis des années , j'ai pas besoin d'apprendre à faire de l'assembleur

Cool, c'est ça de moins à faire.

Du coup, tu veux tes exe en x64, en x86 ou un de chaque ? Parce que l'assembleur sur PC ça a bien changé depuis des années.
(je plaisante)

Plus sérieusement, pourquoi tu veux deux fichiers exe ?
Tu veux vendre l'un des deux en dlc ? 

Tu pourrais faire une dll pour le code "demo".
Le code "fenetre" loaderait la dll "demo" et lancerait la bonne fonction.

Fait comme ça, ce sera propre et tu trouvera plein de tutos sur internet pour t'aider.

[tapomag]

Tu connais la plateforme x86 ? Car c'est plus compliqué qu'un z80 (je ne connais que ce 8 bits).
Rien que pour générer des sauts relatifs et absolus, direct en hexa ça n'a aucun intérêt et c'est un coup à s'arracher les cheveux.
Donc ce qu'on te conseille, c'est d'utiliser un assembleur pour te faciliter la vie.

Le seul intérêt que je vois à injecter de l'hexa directement, c'est pour coller un virus dans une section vide du stub PE

Pour ce que tu veux faire, si vraiment tu veux t'acharner dans la voie windows (et non pas MSDOS ou Pico ou autre console virtuelle), c'est :
1) un exe qui ouvre la fenêtre avec les caractéristiques de ton choix (taille, couleur) et une gestion minimale des évenements (en gros intercepter l'ordre de sortie). Je te conseille de la faire en C, avec le bouquin de Petzold. C'est le premier listing qui doit faire une cinquantaine de lignes.

2) dans ta boucle d'évenements, tu as un watcher qui recharge ton fichier qui contient les opcodes hexa lorsqu'il est modifé (tester la date de la dernière écriture). Éventuellement avec une conversion binaire si c'est un fichier texte (peut-être plus « pratique » pour rentrer les instructions).
C'est là que ça devient coton, car toutes tes « instructions » devront être relogeables en mémoire vu que tu ne sais pas où tu vas atterir lors du chargement. Tu as différentes méthodes pour pallier au fait que tu es en train de faire le boulot du linker, on pourra en reparler si tu arrives jusque là. Ce n'est pas certain que Windows te laisse faire ça tranquillement, ça va surement lever une exception.
Une fois que tout est prêt (chargé en mémoire, sauts calculés, je ne parle pas de gestion de la pile car je ne pense pas que les subroutinse soient au programme), plus qu'à modifier EIP pour éxecuter ton buffer. Il faudra aussi penser à en revenir d'une façon ou d'une autre, sinon ça va continuer à fetcher-décoder-exécuter quand tu vas déborder, et Dieu sait ce qui va se passer (spoiler: rien de bon).

3) au bout de quelques semaines, prendre contact avec un monastère Tibétain pour une retraite spirituelle bien méritée.

Je ne raconte pas tout ça pour te décourager ou me foutre de toi, mais simplement pour que tu comprennes qu'il vaudrait mieux utiliser un assembleur avec un langage support (celui qui lance le progremme). En C, tu peux insérer de l'assembleur au milieu de ton code. Dans le pire des cas si ce n'est pas supporté par ton langage support , tu peux toujours faire une DLL qui contient l'assembleur. Je l'ai fait une fois (il y a bien longtemps) pour accélerer des traitement en visual basic (un projet que j'avais repris où j'étais coincé avec le langage), et ça fonctionnait très bien.

[65c02]

Mine de rien, il soulève une question intéressante :
Comment faire pour exécuter du code qui n'est pas dans un segment de code classique.

Pour rigoler, j'ai fais un petit programme sous visual, qui exécute un bout de code en assembleur.
Et je me suis amusé à faire un call 0, juste pour la déconne.
Evidement ça fait une erreur
0xC0000005 : Violation d'accès lors de l'exécution à l'emplacement 

Pareil si je lui fais faire un call sur une variable dans mon .data
Pas de surprise, le CPU veille au grain pour éviter ce genre de magouilles.

Il n'accepte que de faire des call en dehors du segment code

[tapomag]

Tu peux avoir un segment avec les droits d'exécution.
Et le CS, il doit recouvrir ton DS sur les OS modernes, voire se confondre. Je pense que ces subtilitées ont disparu avec les gigas de mémoire de nos machines (à vérifier avec un débugger).

Si il y a une distinction, le plus simple est soit la DLL, soit les data copiés à un endroit identifié du segment de code. Une fonction vide avec un buffer statique dedans, ça devrait fonctionner (grouiiiik !)

Mais on ne me retirera pas l'idée que c'est vraiment se faire chier pour rien.

[fonzi]

Je fais de l'assembleur depuis des années , j'ai pas besoin d'apprendre à faire de l'assembleur

Cool, c'est ça de moins à faire.

Du coup, tu veux tes exe en x64, en x86 ou un de chaque ? Parce que l'assembleur sur PC ça a bien changé depuis des années.
(je plaisante)

Plus sérieusement, pourquoi tu veux deux fichiers exe ?
Tu veux vendre l'un des deux en dlc ? 

Tu pourrais faire une dll pour le code "demo".
Le code "fenetre" loaderait la dll "demo" et lancerait la bonne fonction.

Fait comme ça, ce sera propre et tu trouvera plein de tutos sur internet pour t'aider.

il y aurai juste un .exe , l'autre fichier sera le jeu et son moteur graphique

le .exe fonctionnerai comme un "fantasy computer" , c'est comme une fantasy console mais sans moteur graphique , le moteur graphique est dans mon fichier jeu


à la base j'avais fait ce moteur graphique en assembleur 65c816 pour un "homebrew computer" imaginaire, et je me suis dit je vais le refaire en x86

[fonzi]

Tu connais la plateforme x86 ? Car c'est plus compliqué qu'un z80 (je ne connais que ce 8 bits).
Rien que pour générer des sauts relatifs et absolus, direct en hexa ça n'a aucun intérêt et c'est un coup à s'arracher les cheveux.
Donc ce qu'on te conseille, c'est d'utiliser un assembleur pour te faciliter la vie.

Le seul intérêt que je vois à injecter de l'hexa directement, c'est pour coller un virus dans une section vide du stub PE

Pour ce que tu veux faire, si vraiment tu veux t'acharner dans la voie windows (et non pas MSDOS ou Pico ou autre console virtuelle), c'est :
1) un exe qui ouvre la fenêtre avec les caractéristiques de ton choix (taille, couleur) et une gestion minimale des évenements (en gros intercepter l'ordre de sortie). Je te conseille de la faire en C, avec le bouquin de Petzold. C'est le premier listing qui doit faire une cinquantaine de lignes.

2) dans ta boucle d'évenements, tu as un watcher qui recharge ton fichier qui contient les opcodes hexa lorsqu'il est modifé (tester la date de la dernière écriture). Éventuellement avec une conversion binaire si c'est un fichier texte (peut-être plus « pratique » pour rentrer les instructions).
C'est là que ça devient coton, car toutes tes « instructions » devront être relogeables en mémoire vu que tu ne sais pas où tu vas atterir lors du chargement. Tu as différentes méthodes pour pallier au fait que tu es en train de faire le boulot du linker, on pourra en reparler si tu arrives jusque là. Ce n'est pas certain que Windows te laisse faire ça tranquillement, ça va surement lever une exception.
Une fois que tout est prêt (chargé en mémoire, sauts calculés, je ne parle pas de gestion de la pile car je ne pense pas que les subroutinse soient au programme), plus qu'à modifier EIP pour éxecuter ton buffer. Il faudra aussi penser à en revenir d'une façon ou d'une autre, sinon ça va continuer à fetcher-décoder-exécuter quand tu vas déborder, et Dieu sait ce qui va se passer (spoiler: rien de bon).

3) au bout de quelques semaines, prendre contact avec un monastère Tibétain pour une retraite spirituelle bien méritée.

Je ne raconte pas tout ça pour te décourager ou me foutre de toi, mais simplement pour que tu comprennes qu'il vaudrait mieux utiliser un assembleur avec un langage support (celui qui lance le progremme). En C, tu peux insérer de l'assembleur au milieu de ton code. Dans le pire des cas si ce n'est pas supporté par ton langage support , tu peux toujours faire une DLL qui contient l'assembleur. Je l'ai fait une fois (il y a bien longtemps) pour accélerer des traitement en visual basic (un projet que j'avais repris où j'étais coincé avec le langage), et ça fonctionnait très bien.

Non je connais rien sur la plate-forme x86 , 
c'est pour ca je voulais juste me concentrer sur l'assembleur x86/x64 ca ce n'est pas un problème 
et perso en hexa c'est plus cool je code direct sans me prendre la tete sur quoi que ce soit

[65c02]

Dans ce cas, la dll est ta solution.

Au lancement de ton fantasy computer, tu pourrais parcourir un répertoire supposément remplit de plein de dll de jeux.
Tu fais une passe de load + vérification de chaque dll pour voir si elles exposent les bonnes fonctions.
Tu en choisis une et tu la lance.

En plus, tu peux faire des dll avec plein de tools et de langages différents (dont l'assembleur).

[fonzi]

vu la complexité du truc sur windows et les limites de msdos, je vais me prendre une journée pour réfléchir entre faire un vrai homebrew computer ou programmer ce point .exe qui est aussi qu'un homebrew computer