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)

[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

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 : )

[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"?

[Piano]

Ok, merci j'ai de la lecture

Je reviendrai sûrement une fois la lecture faite.

Merci à vous 2.

[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

[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.

[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

[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.

[Melem]

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?

[pascal.barbier]

Oui la liste est bien dedans mais quel fatras !

Mon bouquin IBM est beaucoup plus pratique et détaillé.

[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 ?

@edit :: On peut le trouver où le bouquin IBM ? Un titre ? :-)

[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).

[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.