Cherche documentation sur le format COM

Version imprimable

30/12/2007, 13h58
Piano

Cherche documentation sur le format COM

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
30/12/2007, 15h23
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
30/12/2007, 17h25
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 :roll: 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.
30/12/2007, 18h09
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.
30/12/2007, 18h19
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é 8O
30/12/2007, 18h29
pascal.barbier

Citation:

Envoyé par pianopariss

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.

Citation:

Envoyé par pianopariss

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)
30/12/2007, 18h35
Piano

1) Oui, je sais bien mais comment Windows fait pour reconnaître les fonctions comme rename(), delete(), etc., lui il n'utilise pas de retro-ingeneering... ?

2) Oui, j'utilise Parallels pour poster en ce moment :roll:

Mais ça m'intéresserait de faire un petit (ne ce serait-ce que pour reconnaitre une ou deux fonctions) décompilateur de .COM (oui je sais j'ai du boulot...)

Merci : )
30/12/2007, 18h44
Médinoc

À ma connaissance, les appels systèmes sous DOS se font par une interruption.
Windows redirige cette interruption pour traiter à sa façon ces appels système.

Plus d'infos sur ces deux articles:
What was the role of MS-DOS in Windows 95?
Why does a corrupted binary sometimes result in "Program too big to fit in memory"?
30/12/2007, 19h05
Piano

Ok, merci j'ai de la lecture ;)

Je reviendrai sûrement une fois la lecture faite.

Merci à vous 2.
30/12/2007, 19h36
Piano

Zou, lecture faites, mais je me pose une question:
Le COM utilise les interruptions pour dire à Windows quelle fonction appeler, ok mais comment faire pour savoir quelle interruption est appelée et y a t-il une "liste des interruptions" qui décrit leur action pour Windows sous x86 ?

Je suis peut être pas clair mais je ne comprends pas tout dans l'histoire :aie:
30/12/2007, 20h00
Médinoc

Windows utilise la même liste que DOS, puisqu'il se fait passer pour DOS.
Cetre list existe, mais je n'ai aucune idée de où la retrouver.
30/12/2007, 20h09
Piano

Ah, mais ça ça m'intéresse beaucoup !
Elle est libre ?
Bon, je me mets à sa recherche :?

Mais y'a t-il moyen de savoir quelle interruption est appelée sans charger le COM en mémoire (juste en le lisant dans un buffer) ?

Merci
30/12/2007, 22h18
pascal.barbier

La grande majorité des appels système du DOS passent par la fameuse (autrefois) interruption 21.
La liste des fonctions de cette interruption est décrite dans de nombreux sites. J'ai un manuel complet sur le sujet à la maison mais j'ai du mal à le passer dans un post ;-)
Cherche int 21 sur Google.
31/12/2007, 08h47
Melem

Citation:

Envoyé par Médinoc

Cetre list existe, mais je n'ai aucune idée de où la retrouver.

C'est du RBIL que vous parlez ou j'ai pas bien suivi?
31/12/2007, 09h38
pascal.barbier

Oui la liste est bien dedans mais quel fatras !

Mon bouquin IBM est beaucoup plus pratique et détaillé.
31/12/2007, 13h14
Piano

Merci à vous deux.

Mais il y a toujours quelque chose que je ne comprends pas:
Quel est le lien entre les interruptions et le fichier PE (ici .COM).
Comment peut-on savoir quelle interruption est appelée quand on "lit" le fichier .COM ? :aie:

@edit :: On peut le trouver où le bouquin IBM ? Un titre ? :-)
01/01/2008, 22h00
pascal.barbier

Non malheureusement, le bouquin (en fait un classeur) n'a pas été commercialisé. Il s'agissait d'un document interne.

Pour retrouver les interruptions appelées dans un COM, il faut desassembler le code (debug le fait facilement, commande u) on retrouve alors les instructions int 21 (cd 21 en héxa) qui correspondent aux appels système.

Certains rares appels système utilisent un autre numéro d'interruption (24 pour l'accès physique aux disques, 20 pour quitter le programme si je me souvient bien).
08/01/2008, 09h40
themadmax

Liste des interuptions DOS 21 : http://www.ctyme.com/intr/int-21.htm
Mais cherche aussi du coté de court assembleur il me semble qu'il parle souvant en introduction du mode réel.