Discussion :

[Piano]

Bonjour,

Je cherche de la documentation sur le format .COM (msdos) de Microsoft, apparement je n'ai pas trouvé grand chose sur Wotsit.com ni sur Google, quelqu'un aurait-il une documentation avec un minimum de détails ?

On m'a dit d'aller voir du côté des .EXE car c'était simplement un code "simple" mis en mémoire et exécuté mais je ne vois pas dans quelle partie de la doc. sur les .EXE ont parle du "code" en lui-même.
Je cherche à comprendre comment fonctionne un fichier .COM (comment Windows reconnait les "fonctions" à appeler, les paramètres, etc).

Merci

[pascal.barbier]

Le format des fichiers .COM et celui des fichiers .EXE reposent sur le principe d'une "image binaire". Ceci signifie que le fichier contient, entre autres, l'image de ce que sera le programme une fois chargé en mémoire. Le contenu du fichier est donc essentiellement constitué du code du programme en langage machine.
Le fichier .EXE (comme les DLL) est enregistré selon un format standard appelé PE (Portable Exexcutable).
Le format est décrit à l'adresse suivante :
Format EXE

Le fichier .COM, lui, est simplement l'image du programme telle qu'elle sera copiée en mémoire (à l'adresse 0100h d'un segment de 64Ko). Ce format ne permet pas les fixups de relocation contrairement au format PE.

Attention, la majorité des fichier.COM de windows sont en fait des EXE (facile à découvrir : les deux premiers octets sont une signature 4D/5A propre au format PE).

Joyeuses fêtes

[Piano]

Tout d'abord merci pour la réponse

Enfait, j'ai déjà étudié le format PE 16 et 32bits, j'ai découvert pleins de choses comme mieux comprendre les sections (.data, .reloc, ...) etc.
Mais je n'arrive pas à comprendre:
* Dans un fichier PE (de type exe) on peut trouver le nom des fonctions appelées depuis la table d'import, etc. Mais ça ne se passe pas comme ça sur un .COM, car toutes les fonctions sont connues ?
Si par exemple, je chercherais à faire un simulateur (qui se contente de "getter" le nom des fonctions appelés dans un .COM) comment devrais-je m'y prendre puisque je ne vois nul part les spécifications propre au COM.
Enfait déjà quand j'ai étudié le PE 32bits, je n'arrivais pas à aller plus loin que d'avoir des infos sur celui-ci, par exemple: la taille du header, des ressources, etc. mais je n'arrivais pas à toucher la partie principale: LE .CODE.
Je ne comprends pas comment Windows arrive à savoir quelle fonction appeler après laquelle et comment moi, en l'occurrence pourrais-je le savoir.
Enfait je fais un peu de la compote des différences entre les PE (16/32), les EXE, et les COM.
Alors, un .app sous Mac est aussi un PE ?
Pourquoi n'arrive-t-on pas à exécuter un .app compilé pour la même machine (x86) sous Windows et inversement ?

Ca fait beaucoup de questions

Joyeuses fêtes, et bonne année.

[pascal.barbier]

1) Dans un .COM toutes les fonctions sont transformées en appel à une adresse relative (CALL xxxxh). Les noms des fonctions ont donc disparu.
2) Dans le .EXE, les fonctions internes au module (c'est à dire appelées uniquement depuis l'EXE) sont transformées de la même façon. Les fonctions dont les noms resteront sont celles qui sont exportées (appelables depuis l'exterieur) ou importées (appelées depuis le programme mais logées dans une DLL externe). Ces noms sont placés dans la table d'imports. L'outil depends.exe (du sdk, également dans visual studio) permet de lire cette table d'import.
3) Un programme compilé pour Windows utilise beaucoup de fonctions de l'API Windows (voir la liste des imports avec depends). Ces fonctions ne sont pas disponibles sur un Mac dont l'OS (MacOS) contient d'autres fonctions appelées "appels système". C'est une des raisons de l'incompatibilité entre les deux plateformes.

[Piano]

Ok, je comprends bien, merci

1) Mais comment savoir à quoi "correspond" l'adresse pointé ?
(surtout pour le .com, puisque les "fonctions" appelées (comme rename, delete, etc) sont externes alors que dans un PE, les fonctions externes "gardent leur nom" dans la table)
C'est là que je bloque, et j'ai encore relu une autre doc de Intel sur le 8086 et de Microsoft sur le PE, mais je ne trouve pas de réponse à mes questions.

2) Donc, si je comprends bien, il n'y a aucun moyen pour retrouver dans un .exe le nom d'une fonction interne à part s'il est compilé en debug ?
Ok, et mais alors, il est impossible d'analyser un PE sans le charger entièrement en mémoire ?

3) Oui, ok pour l'incompatibilité entre OSX et Win (etc) mais autrement, n'y a t-il rien d'autre comme "incompatibilité" dans le fichier compilé

[pascal.barbier]

Mais comment savoir à quoi correspond l'adresse pointé ? (surtout pour le .com, puisque les fonctions appelées sont externes alors que dans un PE, les fonctions externes "gardent leur nom" dans la table)

Pour trouver ces information il faut faire de la "rétro-ingénierie". On charge le PE, on le désassemble (il y a de très bons logiciels pour cela) et ensuite on essaye de comprendre ce que l'auteur a écrit.

Oui, ok pour l'incompatibilité entre OSX et Win (etc) mais autrement, n'y a t-il rien d'autre comme "incompatibilité" dans le fichier compilé

Si d'autres incompatibilités existent également. Pour exécuter un programme Windows sur un Mac, il faut utiliser un émulateur (VMWare, Boot camp)