Discussion :

[Kitsune64]

Bonjour,

Je viens de faire un petit programme en C qui crée un fichier COM pour MS-DOS / peut qu'il marche sur d'autre système DOS (testé sous MS-DOS 6.22).

En premier lieu j'ai créé un programme COM minimal en assembleur qui s'ouvre et se ferme directement sous DOS sans rien faire d'autre.

En visionnant le code hexadecimal de ce programme ça se résume à ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

B8 00 4C CD 21

J'ai voullu pour étude créer un logiciel en C capable de générer ce même programme en se lancant.

J'ai réussi au final a avoir un code similaire généré par mon programme C, cependant il y a 2 '0' en plus à la fin du fichier COM c.a.d ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

B8 00 4C CD 21 00

A savoir j'utilise la fonction C fwrite() pour générer du code dans mon fichier en mode binaire.

Voici le code source du programme en C capable de générer le fichier COM éxecutable.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <stdio.h>
int main(void){
        int a=0;
        FILE *fp;
        char str[8];
        fp=fopen("file.com","wb");
 
        if (fp==NULL)
                return -1;
        a=184; /*org 100*/
        fwrite (&a,sizeof(a),1,fp);
        a=52556;
        fwrite (&a,sizeof(a),1,fp);
        a=33;
        fwrite (&a,sizeof(a),1,fp);
        fclose(fp);
        return 0;
}

Dans l'exemple ici j'ai du faire quelques calcule pour tomber sur les chiffres en mode décimal pour correspondre aux chiffres hexadécimaux.
Ce concernant je n'ai pas vraiment tout compris car j'ai du inverser les lettre 4C CD en C4 DC pour effectuer mon calcul final

C*16^0 + 4*16^1 + D*16^2 + C*16^3 = 4CCD (C'est ce que je n'ai pas compris car c'est inversé par paire)
12+64+3328+49152=52556

21h = 33

Si vous pouvez m'explique la raison pour laquelle j'ai du inverser les lettres pour le calcul de 4CCD?

Aussi pourquoi fwrite() place 00 à la fin de mon fichier COM? Est-ce impossible d'omettre ce '00'?

Cependant le fichier COM final s'execute correctement.

[hurukan]

Je pense que cela est lié à "l'endianness"... les "processeurs" lisent les informations dans les registres en fonction du poids le plus fort (Big Endian) ou du poids le plus faible (Little Endian)
Maintenant j'ignore si à la compilation il est possible de modifier cet "endianness"...

Concernant fwrite() je suis pas certain que ce soit la bonne fonction à utiliser (essaie write() tout court) -- peut-être qu'elle ajoute le '\0' de fin de chaîne.

[Obsidian]

Bonjour !

Si vous pouvez m'explique la raison pour laquelle j'ai du inverser les lettres pour le calcul de 4CCD?

C'est effectivement lié à l'endianess ou « boutisme » en français.

Les processeurs Motorola sont typiquement grand-boutistes (6809, 68000…), ce qui est une des raisons qui les rendaient plus faciles et donc plus populaires auprès des jeunes programmeurs (que nous étions quand on pouvait encore faire de l'assembleur de façon sérieuse) là où les Intel, dont le x86, sont généralement petit-boutistes.

La raison à cela est que les données au format grand-boutiste sont plus faciles à lire par le programmeur quand on explore un dump hexadécimal (donc sommes toutes relativement rarement) alors que le format petit-boutiste est beaucoup plus facile à traiter pour les machines et peut, dans une certaine mesure, améliorer les performances et rendre un processeur sensiblement plus rapide à technologie équivalente. Cela est dû au fait qu'en déposant les octets de poids faible d'abord, les octets qui occupent une même position au sein d'un registre de longueur arbitraire occupent également la même place en mémoire. Par exemple, les valeurs « CD », « 45CD » et « 3B2F45CD » se retrouvent codées en mémoire :

CD
CD 45
CD 45 2F 3B

… ce qui permet en fait au microprocesseur d'utiliser les mêmes mécanismes pour remplir les registres 8 bits, 16 bits, 32 bits ou plus larges encore, en se contentant de s'arrêter quand le registre est rempli.

C'est d'ailleurs ce que tu vois dans ton premier exemple. Dans la série B8 00 4C CD 21, B8 00 4C correspond à MOV AX,4c00h, qui dépose dans AH le code 4Ch qui indique au DOS que le programme prend fin, et dans AL la valeur 00, qui est en fait le paramètre de l'opération et qui, ici, correspond à la valeur de retour renvoyée et retournée à la ligne de commande ou au script BAT s'il existe. C'est cette valeur qui est renvoyée par return dans main ou par exit() quand on travaille en langage C.

Les codes CD 21, quant à eux, correspondent à int 21h.

J'ai réussi au final a avoir un code similaire généré par mon programme C, cependant il y a 2 '0' en plus à la fin du fichier COM c.a.d ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

B8 00 4C CD 21 00

Je ne sais pas pourquoi le compilateur ajoute un zéro mais il est déjà assez remarquable qu'il ne s'en tienne qu'à ça. D'habitude, même avec la meilleure volonté du monde, les compilateurs remplissent les petits fichiers de données inutiles. Le bénéfice se fait sentir à plus grande échelle.

Ce zéro peut correspondre à n'importe quoi : une sentinelle pour détecter la fin des données, une place réservée pour insérer un hook à l'usage du débogueur, une manière de séparer le code chargé en mémoire de ce qui s'y trouvait avant ou, parfois, du padding (rembourrage) pour aligner la prochaine instruction sur une adresse multiple de la taille du bus (mais ça ne semble pas être le cas ici).

[kaitlyn]

Salut,

Ce zéro peut correspondre à n'importe quoi

C'est parce que le int est codé ici sur 2 octets,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
0x00B8 devient B8 00 en mémoire, fwrite ecrit B8 00
0x4CCD devient CD 4C en mémoire, fwrite ecrit CD 4C
0x0021 devient 21 00 en mémoire, fwrite ecrit 21 00

[Obsidian]

C'est parce que le int est codé ici sur 2 octets,

Ah oui ! En effet, j'ai lu un peu trop vite. Ce n'est pas la compilation d'un programme C qui a donné directement lieu à ce fichier objet mais c'est le résultat de son générateur qui, lui, est écrit en C.

Bien vu.

[Kitsune64]

Merci pour toutes ces infos ça éclaircit pas mal de choses concernant le code de ce post.

Salut,
C'est parce que le int est codé ici sur 2 octets,

0x0021 devient 21 00 en mémoire, fwrite ecrit 21 00[/CODE]

Je tournais autour de ce problème tout à l'heure, je pense que je dois passer vers un unsigned char...Pour coder par un seul octet; peut être.
J'ai croisé un code source tout à l'heure qui indiquais d'utiliser unsigned char avec fwrite pour l'écriture en binaire. Sauf que mon compilateur ne gère pas par défaut ce type de déclaration.
Je pense que je vais devoir définir (si j'y arrive avec ce compilateur) ce qu'est un unsigned char.

Concernant le compilateur utilisé:
Pour information, j'utilisais le compilateur SubC cette fois. Ce choix est du au fait que c'est un de seul compilateur pour le langage C dans le domaine publique.
La dernière version que j'ai trouvée compilée pour DOS est de 2014, il gère la norme C89 normalement mais est en phase expérimentale dans sa version DOS

---Réédition---

Ca marche avec simplement un char à la place du int cette histoire de zero...Sous DOS donc et avec ce compilateur, donc je ne sais pas si Turbo C réagirai de la même manière par exemple.

Le dernier code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
#include <stdio.h>
 
void xfile(char a,FILE *fp);
 
int main(void){
        FILE *fp;
 
        printf("%d\n",sizeof(int));   /* 2 (octets) */
        printf("%d\n",sizeof(char));  /* 1 (octet) */
 
        fp=fopen("file.com","wb");
 
        if (fp==NULL)
                return -1;
 
        xfile(184,fp); /* B8 */
        xfile(0,fp);   /* 00 */
        xfile(76,fp);  /* 4C */
        xfile(205,fp); /* CD */
        xfile(33,fp);  /* 21 */
 
        fclose(fp);
        return 0;
}
 
void xfile(char a,FILE *fp){
        fwrite(&a,sizeof(a),1,fp);
}

C'est plus simple en codant sur un seul octet en revanche ça demande 2 fois plus l'utilisation de la fonction fwrite(). Et donc je n'ai plus 00 a la fin du fichier généré...Encore merci!

[kaitlyn]

donc je ne sais pas si Turbo C réagirai de la même manière par exemple.

Dans la mesure où les compilateurs répondent au même standard, ce sera pareil.
djgpp et open watcom peuvent vraisemblablement générer des exécutables pour ms-dos. Attention à bien télécharger sur les sites officiels.
Sinon, pour ce que tu tentes de faire, tu peux écrire quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
unsigned char buffer[]= {0xB8, 0x00, 0x4C, 0xCD, 0x21};
/* ... */
fwrite(buffer, 1, sizeof buffer, fp);  /* ou plus généralement:
fwrite(buffer, sizeof buffer[0], sizeof buffer / sizeof buffer[0], fp);
*/

[Kitsune64]

Merci pour le raccourcis, ça simplifiera grandement la mise en place d'écrire ainsi.

Je vais d’abord essayer ta portion de code sur SubC pour le moment. unsigned char ne passe pas sur celui-ci, simplement char ce qui correspond a un seul octet via ce compilateur.

DJGPP, je l'aimais bien, mais je ne pense pas qu'il génère des programme de base en mode réel (16bits);il faut un extenseur mémoire DPMI de souvenir.
Je (re)ferai des tests avec ce compilateur pour en avoir le cœur net.

---Réédition---

Le compilateur SubC n'a pas voulu initialiser la chaine de caractères correctement.

DJGPP ne compile qu'en 32 bits sans générer d'erreurs lors du lancement du programme

Conclusion je suis passé à Open Watcom!

Voici le code fonctionnel sous ce compilateur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
#include <stdio.h>
 
int main(void){
        FILE *fp;
        unsigned char binary[5]={0xb8,0x00,0x4c,0xcd,0x21};
        printf("%d\n",sizeof(int));   /* 2 (octets) */
        printf("%d\n",sizeof(char));  /* 1 (octet) */
 
        fp=fopen("file.com","wb");
 
        if (fp==NULL)
                return -1;
        fwrite(binary,1,sizeof(binary),fp);
 
        fclose(fp);
        return 0;
}

pour compiler j'ai utilisé ces deux commandes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
wcc -3 nom_du_fichier.C
wcl nom_du_fichier.OBJ

[Sve@r]

Bonjour

unsigned char ne passe pas sur celui-ci, simplement char ce qui correspond a un seul octet via ce compilateur.

En fait, il n'y a absolument aucune différence entre un "unsigned char" et un "char". Tu as parfaitement le droit d'écrire unsigned char c=-12 non seulement ça compilera mais en plus ça fonctionnera. Y compris si tu t'amuses à calculer ensuite avec ce "c". En interne, le codage est exactement le même (0xF4).
La différence arrive quand on copie ce "c" dans une variable plus large (char dans short, short dans int, etc). A ce moment là, si la variable est déclarée signée et que le bit de signe est à 1, le bit est alors étendu sur la partie gauche de la copie (pour que par exemple -5 en signed char continue à valoir -5 en signed short). Typiquement 0xF4 signé copié dans un short donne 0xFFF4.
Et si la variable n'est pas signée, alors pas d'extension. Dans ce cas 0xF4 non signé copié dans un short donne 0x00F4.

[Kitsune64]

En fait, il n'y a absolument aucune différence entre un "unsigned char" et un "char". Tu as parfaitement le droit d'écrire

Je voulais dire par là que SubC ne gère pas le terme unsigned char ...Donc je suis obligé de passer par le terme char tout court sur ce compilateur.
Du coup je me disais que cette notion d'unsigned char / char se différencie peut-être d'une version d'un compilateur à l'autre et aussi peut-être de l'OS sur lequel tourne le compilateur (MS-DOS ici en l’occurrence).

Cependant merci pour toutes ces explication et précisions par rapport au char.
---
Aussi en revenant sur une proposition cité dans un des post ci-dessus concernant la compilation via DJGPP; j'ai tenté à mainte reprises de compilé une application en 16 bits/mode réel avec GCC (inclut dans l"environnement de DJGPP), mais je n'y suis jamais parvenu!

Même en utilisant des paramètres que j'ai trouvé en ligne de type -m16 pour GCC ou de l'assembleur "Inline" précisant de passer "en mode" 16 bits...Le code généré par GCC sous DOS concerne des registres accessibles en 32 bits (option -S via GCC permetant de voir le code assembleur généré).

Du coup je ne vois plus qu'Open Watcom dans les solution open-source pour DOS qui permet de compiler des application soit en 16 ou en 32bits.

J'aime beaucoup Turbo C aussi mais j'ignore si c'est vraiment un outils gratuit à l'heure actuelle bien que je sais qu'il est facilement trouvable en ligne. Officieusement gratuit, officiellement je n'ai pas idée concernant ce compilateur.

[kaitlyn]

Salut,

Du coup je me disais que cette notion d'unsigned char / char se différencie peut-être d'une version d'un compilateur à l'autre et aussi peut-être de l'OS sur lequel tourne le compilateur (MS-DOS ici en l’occurrence)

Non, en fait SubC est un compilateur expérimental qui n'implémente qu'un tout petit sous-ensemble de C, d'où son nom.
Quand j'avais cherché une alternative, Turbo C était ressorti, mais il n'y avait plus de lien officiel mais seulement pour du 32bits (BCB32), cela dit, open-watcom est probablement meilleur.

---Réédition---

Il faut faire attention avec les rééditions, car contrairement aux nouveaux messages, sur ce forum, elles ne sont ni taguées ni signalées, et passent le plus souvent complètement inaperçues.

Sinon j'ai pu lire que sur ms-dos, certains utilisaient l'utilitaire intégré ou éditeur debug.com (ou debug.exe ?) pour faire exactement ce que tu fais, bien que dans ton cas, je ne vois pas l'intérêt de faire cela puisque tu disposes déjà d'un compilateur.
En plus, avec la bibliothèque ncurses, il est possible de faire pratiquement tout, en tout cas en interface utilisateur (conf. TUI, text user interface).

[Kitsune64]

Sinon j'ai pu lire que sur ms-dos, certains utilisaient l'utilitaire intégré ou éditeur debug.com (ou debug.exe ?) pour faire exactement ce que tu fais, bien que dans ton cas, je ne vois pas l'intérêt de faire cela puisque tu disposes déjà d'un compilateur.
En plus, avec la bibliothèque ncurses, il est possible de faire pratiquement tout, en tout cas en interface utilisateur (conf. TUI, text user interface).

Je ne comprends pas tout à fait ici ce que tu à voulus dire par "pour faire exactement ce que tu fais...". Donc ici dans mon cas il s'agissait de générer un fichier "*.COM" à partir d'un programme.
Cependant c'était surtout à titre de recherche et de curiosité de procédé ainsi. Je me dis que ça pourrait servir à créer (si je continue sur cette lancée) une sorte de compilateur. Parce que l'idée de base était là...C'est à dire que j'aurai bien voulu créé un mini compilateur/assembleur et le placer dans le domaine public mais c'est quand même pas une mince affaire de créer un assembleur.

Cependant concernant DEBUG, je l'ai justement utilisé récemment, programme fournit dans MS-DOS et j'ai pu créer un petit programme (a partir d'un tutoriel trouvé en ligne ) en injectant du code assembleur dans DEBUG. Donc il peut aussi servir d'assembleur (je ne sais pas si c'est ça que tu à voulu me transmettre) bien que je le trouve moins pratique à utiliser qu'un assembleur traditionnel comme NASM, FASM ou TASM de Borland,...Mais je suis certain que le programme DEBUG offres d'autres possibilités que j'ignore encore.

[kaitlyn]

Oui c'est bien à cela que je faisais allusion. Mais disons qu'à notre époque, la tendance c'est 64bits et multiplateforme. Avec du ms-dos, .com, 16bits, je ne parle même pas de la manière dont tu veux construire ton projet, j'ai bien peur que ça te mène nulle part.
Enfin, je me dis juste que tu pourrais investir ce temps dans quelque chose qui te sera plus utile et profitable.
Après c'est toi qui vois, évidemment.

[Kitsune64]

Effectivement la tendance suit l'évolution matérielle ce sera certainement toujours le cas, cependant je vois DOS comme un système très portable et toujours utilisé d'une certaine façon...Enfin pas nativement (bien que?) ce que je veux dire par la c'est que je connais peu de machine informatisée qui sont incapable d'émuler un environnement DOS ou proche de DOS comme Dosbox par exemple à l'heure actuelle. Donc Je me dis que si je développe sur ce système ça passera sans soucis sur beaucoup de machines. Et puis j'ai quand même une affection du à la nostalgie pour le système DOS, MS-DOS en particulier. Je ne compte pas faire "d'étincelles" par exemple en développer une scène de jeu AAA a moi tout seul car je sais que c'est un système qui a ses limitation techniques et j'en tient compte dans que je pense et dis.

J'ai pu installer par exemple FreeDOS en natif sur cet ordinateur portable que j'utilise de 2010 et j'ai du son émulé sous DOS! Woaw ^^.
En natif malheureusement les drivers pour la carte réseau que j'ai n'existe pas.

Mais je ne crois pas que DOS est mort même si la communauté Linuxienne et Windows l'écrase sans aucun doute à l'heure actuelle.

[Christophe]

Je rejoint la vision de kaitlyn

je connais peu de machine informatisée qui sont incapable d'émuler un environnement DOS ou proche de DOS comme Dosbox par exemple à l'heure actuelle.

Dosbox est dispo sur Windows, Linux et Mac OS, donc sur quasi tous les ordis, et il fait très bien le job.

Mais je ne crois pas que DOS est mort

Ca fait des années que je ne vois même plus de vieux systèmes obsolètes pilotés sous DOS.

Le format .com ne permet de gérer que 64K. MS-DOS n'est plus portable, les CPU 64 bits ne peuvent pas gérer d'applis 16 bits (limitation interne) sauf à fonctionner en mode 32 bits, donc sur un OS 32 bits. Windows 10 était le dernier système fourni en 32 bits (la tendance est la même sous Linux, et Mac OS ne permet plus l'execution d'applis 32 bits depuis quelques années).

En cas de besoin, il reste l'émulation, fournie par Dosbox (ou autre produit, Dosbox fonctionnant très bien étant le plus connu).

A titre de recherche, je te conseillerais de plutôt étudier le fonctionnement d'un compilateur, puis ensuite de l'assembleur. tu devras aussi comprendre le format .exe. et le fonctionnement du x86 qui est chiant. Tu as de quoi faire. Ce que tu as déjà vu appris te servira dans ce cadre. Il ne sert à rien de réinventer quelque chose qui n'est déjà plus utilisé et qui n'a aucune chance de l'être de nouveau, mise à part pour l'apprentissage, mais sans utilité derrière.

La solution de debug fonctionne si tu es capable de donner les instructions avec les adresses pour les données à la place des noms de variable. Si tu es capable de ça, créer directement le binaire n'est pas une grosse étape supplémentaire.

[Kitsune64]

Je rejoint la vision de kaitlyn

Dosbox est dispo sur Windows, Linux et Mac OS, donc sur quasi tous les ordis, et il fait très bien le job.

Ceci rejoint ce que je voulais dire ici concernant la portabilité de DOS. Il est clair que MS-DOS en soi est moins portable...Cependant à l'heure actuelle, il existe des alternatives qui émulent complètement les machine pouvant accueillir un système comme MS-DOS (je fais allusion ici à PCem et 86Box par exemple) de façon fidèle à un environnement de l'époque. Mais oui c'est plus lent et plus gourmand à faire tourner que Dosbox.

Cependant mon idée est de faire du développement en ciblant ms-dos et si le produit fini est compatible avec Dosbox c'est bien ainsi; c'est un point positif en plus; un atout. Je ne me vois pas directement développer mes application en ciblant Dosbox plutôt qu'MS-DOS. Je fais ça par hobby / curiosité et recherche surtout ici.

Je veux bien croire que les parcs informatisés d'aujourd'hui n'utilise plus de systèmes DOS, c'est bien un système obsolète je le reconnais. Mais je fais ça avant tout pour mon plaisir, par curiosité et pas pour satisfaire une entreprise ici.

De plus, ce que j'apprendrai sous DOS je pense que certaines notions seront acquises et potentiellement utilisable si j'ai un autre projet en tête.

En somme je vois MS-DOS comme un bac sable on construit ce qu'on veut dedans en prenant conscience de ses limites.

J'ai pas spécialement envie d'apprendre pour le moment le langage assembleur ciblant un système Windows ou un système Linux 64 bits, même si j'ai conscience que c'est plus populaire à l'heure actuelle. C'est un choix personnel ce que je fais.

J'ai choisis de générer un COM ici car c'est un format effectivement plus limité oui, mais je pense aussi surtout plus simple à comprendre dans un premier temps comparé à un fichier EXE.

[Christophe]

J'entends tes remarques.

Pour de la programmation moderne, tu n'as pas besoin d'apprendre l'assembleur ni le format d'un fichier .exe en faisant du C.

J'ai une autre piste pour toi, tu génère une .exe au format compatible MS-DOS avec le compilateur de ton choix (tu peux voir peut-être le portage de gcc avec cygwin), et tu le converti ensuite en .com avec exe2bin, fourni avec MS-DOS.

[Kitsune64]

Je suis au courant de ta première phrase. Encore une fois c'est un choix de choisir ces langages

Pour cross-compiliation je suis vaguement au courant; je n'ai pas beaucoup pratiqué cette technique.

mais l'optique est que recherchais des outils dans le domaine public pour la compilation. Ce n'est pas le cas de beaucoup.
Ce n'est pas facile à trouver d'ailleurs je ne connais pas d'assembleur qui est vraiment dans le domaine public.

[Christophe]

e ne connais pas d'assembleur qui est vraiment dans le domaine public.

Tu as NASM.

[Kitsune64]

Je l'utilise sous DOS mais Nasm n'est pas dans le domaine public. C'est tout simple, je ne connais pas d'assembleur ciblant un processeur de la famille x86 dans le domaine public.