Discussion :

[stephane543]

Salut tous le monde,

j'aimerais comprendre pourquoi un fichier binaire .exe(par exemple un jeux) sous windows ne peut pas être executé directement sous linux(sans le fameux logiciel wine ou machine virtuelle comme qemu).
J'ai lu que sous linux les formats de fichier n'était pas pareil(exe pour windows et elf sous linux,entre autres, si j'ai bien compris).
Mais est ce que les instructions en binaire pour un exe ou un elf sont les même ou est ce que une instruction d'un fichier binaire exe est différente d'une instruction d'une instruction binaire elf même si le format est différent?

merci

[RTFMRTFM]

Salut tous le monde,

j'aimerais comprendre pourquoi un fichier binaire .exe(par exemple un jeux) sous windows ne peut pas être executé directement sous linux(sans le fameux logiciel wine ou machine virtuelle comme qemu).J'ai lu que sous linux les formats de fichier n'était pas pareil(exe pour windows et elf sous linux,entre autres, si j'ai bien compris).

Sous Windows on parle du format PE (Portable Executable), et non de l'exe qui est juste l'abréviation du mot exécutable (et l'extension de fichier).

Mais est ce que les instructions en binaire pour un exe ou un elf sont les même ou est ce que une instruction d'un fichier binaire exe est différente d'une instruction d'une instruction binaire elf même si le format est différent?

merci

Le format est différent, on a donc deux loader différents.
Mais le jeu d'instructions dépend de l'architecture. Concrètement la différence la plus flagrante que tu pourra constater en regardant le code assembleur (entre les systèmes Unix et Windows) se situe au niveau des appels systèmes and co.

[Obsidian]

Bonjour,

j'aimerais comprendre pourquoi un fichier binaire .exe(par exemple un jeux) sous windows ne peut pas être executé directement sous linux(sans le fameux logiciel wine ou machine virtuelle comme qemu).

Tu as l'air d'avoir creusé un peu la question avant d'écrire, et c'est bien.

En fait, il faut cesser de prendre Windows comme point de référence. Ce sont deux systèmes différents. Si Linux ne peut exécuter directement un programme Windows, c'est pour les mêmes raisons que Windows ne peut exécuter directement un programme Linux. En plus, sous Windows, à part Cygwin, il n'existe pas de solution élégante pour y remédier.

J'ai lu que sous linux les formats de fichier n'était pas pareil(exe pour windows et elf sous linux,entre autres, si j'ai bien compris).
Mais est ce que les instructions en binaire pour un exe ou un elf sont les même ou est ce que une instruction d'un fichier binaire exe est différente d'une instruction d'une instruction binaire elf même si le format est différent?

Il y a plusieurs choses distinctes :

• Un exécutable compilé embarque en principe du langage machine. Ça veut dire que les instructions utilisées sont ceux du micro-processeur. Si tu changes de machine, tu es obligé de recompiler ton exécutable à partir du code source et d'en produire un autre spécifique à la machine que tu utilises. Cela dit, ça ne se voit pas beaucoup car :
  
  - Des machines différentes peuvent utiliser le même micro-processeur ;
  - Aujourd'hui, qu'on utilise Windows ou Linux, on le fait la plupart du temps sur la même machine (un PC).
  
  
  
• Le format de fichier est différent. Chaque système organise ses exécutables comme il l'entend. Si on lui en montre un autre, il faut être capable de faire la traduction ... si c'est possible ! En effet, si chaque système proposait rigoureusement les mêmes fonctionnalités, conçues de la même façon, ce ne serait pas des systèmes différents ;
  
  
• Dans le même esprit : ton programme va s'appuyer sur des fonctionnalités d'un système. Lorsque tu fais « CALL adresse » en assembleur pour appeler une fonction, c'est la même instruction qui sert à invoquer toutes les fonctions. Seule l'adresse change. D'un système à l'autre, tu n'es pas sûr que les fonctions soient portées. Si elles le sont, il faut quand même reparcourir tout l'exécutable pour faire la traduction ;
  
  
• Chaque système a des règles et une manière de fonctionner qui lui sont propres. Ton programme est bâti sur ces concepts. Par conséquent, ce n'est pas parce qu'une fonctionnalité équivalente existe sur plusieurs systèmes qu'elle va être exploitée partout de la même façon.
  
  
  Les signaux UNIX par exemple. Ils n'existent pas dans cette forme sous Windows. Tu peux arriver au même résultat en utilisant d'autres outils, mais cela demande de réécrire un bout de programme, pour Windows spécifiquement.

À ce stade, on ne se demande même plus pourquoi on ne peut pas directement utiliser un même exécutable partout. On en arrive plutôt à se demander comment certains programmes tels que wine, que tu cites, parviennent quand même à le faire. Il y a plusieurs tendances :

Les émulateurs : c'est ce qui se passe avec les consoles de jeux ou les vieux ordinateurs huit bits. on fait un programme qui simule le fonctionnement d'un micro-processeur ainsi que le comportement des ports d'entrée-sortie matériels. Après, il suffit de reprendre les ROMs originales et de les réinstaller dans cet environnement. Puisqu'on part de zéro, et que chaque étape permet à la suivante de fonctionner, on reconstitue le fonctionnement d'un ordinateur entier. Seulement, c'est un ordinateur, émulé par un programme, qui tourne sur ... un ordinateur. C'est donc très lent. Ça se voit moins aujourd'hui car le moindre PC moderne a un moteur de fusée.

Les machines virtuelles : si le programme étranger est censé fonctionner sur la même machine (avec un autre OS), alors le code en langage machine est le même et le problème est purement logiciel. Il est alors possible de « partitionner » les ressources de sa machine (notament en mémoire) pour que les ressources d'un même sous-ensemble ne voient qu'elles et rien d'autres. Il est alors possible de démarrer un système depuis zéro, qui s'adaptera à son environnement sans en déborder.

Les produits tels que WINE (Wine is NOT an emulator), eux, compartimentent un programme de façon à rattrapper tous ses appels illégaux pendant l'exécution et, de là, appeler en leur nom leurs homologues sous Linux s'ils existent avant de rendre la main au programme. Ça peut être compliqué à faire, et donc long à l'exécution.

L'avantage est que, de cette façon, le programme interagit quand même avec le système même si c'est à son insu : par exemple, les fenêtres sont ouvertes sous X-Window comme des fenêtres ordinaires, la mémoire est réservée par le noyau Linux, etc.

L'inconvénient, c'est que traduire tous les appels Windows et reproduire tous leurs comportement, ça revient à écrire Windows, tout simplement. C'est pourquoi les fonctions reproduites sont celles du noyau, et les appels vraiment fondamentaux, et que les bibliothèques originales sont utilisées pour tout ce qui va au dessus, même les gens derrière le projet écrivent chaque jour un peu plus de code pour le rendre aussi autonome que possible.

[stephane543]

merci beaucoup pour vos réponses qui m'ont beaucoup éclairé(et désolé pour le retard de la mienne)