Je suis pas sur, mais je pense que ca peut venir du type de disque utilisé (par exemple, windows est en fat ou ntfs, linux est en ext3).
Cela ne rentre pas en ligne de compte. Le but du système d'exploitation est justement de cacher ce fait à l'utilisateur et/ou aux exécutables par le biais des drivers et des appels systèmes. Lorsque par exemple on ouvre un fichier en C, on fait un fopen() sans savoir quel est le type de système de fichier utilisé. (on remarquera aussi que le même code C, à ce niveau, fonctionnera à la fois sous Windows et sous Linux, mais c'est parce que des normes existent concernant le langage).
Par ailleurs, j'utilise tous les jours un driver ext3 sous windows pour accéder à mes partitions Linux, et des drivers FAT et NTFS sous Linux pour accéder à mes partitions Linux.
Ca veux dire que les gars qui ont fait Unreal Tournament ont dû programmer le jeu DEUX FOIS pour qu'il tourne aussi sous linux ? Bah ils ont du courage chez eux !
Ça n'a rien à voir. Si le code est portable, il suffit de le COMPILER deux fois. Une fois avec un compilateur Linux, et une fois avec un compilateur Windows. Mieux : un compilateur comme gcc fonctionne sous énormément d'architecture et d'OS possible. Encore mieux : gcc permet même de générer des exécutables pour une cible alors qu'il fonctionne sur une autre (cross-compiling). Mais là, ça demande une petite gymnastique de configuration.
Mais c'est assez utopique dans le cas d'un jeu. En règle général, on a des parties critiques spécifiques à l'un ou l'autre des OS (essentiellement, pour des raisons de performances qui obligent à s'affranchir de toute couche d'abstraction apportée par l'OS, et donc à descendre à du très bas niveau, à la limite, de l'assembleur), mais la plus grande partie est commune. Ceci dit, écrire un code portable ne s'improvise pas.
J'ai lu sur une doc ruby que Python, Ruby et Perl suivaient le même principe : avec ces trois languages, on programme donc des programmes qui se compilent à chaque execution, ne ? c'est cela qu'il faut ?
C'est effectivement le principe. Je réponds pour Perl, j'avoue n'avoir que peu abordé Python, et pas du tout Ruby. Mais j'ai crû comprendre que la philosophie est la même.
Mais je dois dire que ça m'étonne... est-ce que ça veux dire que selon le système d'exploitation, le programme est compilé différement ? Auquel cas on peut utiliser le même script des deux côtés ?
Autre questions sur le fonctionnement... par exemple, pour utiliser Python, il faut l'installer sous Windows. Mais c'est peut-être parce que Python se compile à l'éxecution : une fois qu'un programme est compilé, que deviens-t-il ? de l'ASM ?
Que ce soit pour les langages compilés à l'exécution, comme pour les compilateurs natifs, le principe couramment utilisé (mais on peut imaginer autre chose) est à peu près le même :
- preprocessing.
- vérification syntaxique.
- etc..
- génération d'un pseudo code.
C'est à partir de là que tout change. Par exemple, dans le cas de Java, c'est la JVM qui se charge d'exécuter le bytecode Java, et c'est entre autre ce qui fait dire (mais à tort), que Java est portable¹. En fait, il faut bien disposer d'une JVM adaptée à son système pour exécuter les classes compilées.
Dans le cas d'une compilation native, le compilateur ajoute une étape supplémentaire qui est de transcrire le pseudo-code obtenu en langage machine adapté à la cible choisie (X86, ppc, etc... au format ELF, PE...).
Dans le cas de langages de scripts, je suppose (je ne me suis pas renseigné à ce sujet), que cela fonctionne à la façon de Java, donc avec un interpréteur de pseudo-code.
Yatil donc des languages qui ne fonctionnent pas sous Linux ou Windows ?
La possibilité d'utiliser d'un langage sur une architecture particulière est simplement conditionnée à la disposition d'un interpréteur ou d'un compilateur pour cette cible.
Un exemple ? Hahem, par exemple, je ne connais pas de compilateur VB pour Unix. Je laisse le soin à quelqu'un d'autres d'ouvrir une discussion sur les causes de cette absence.
¹: La «portabilité» de Java vient pour une grande part de l'énorme API qui est fournie de base. De la même manière, Perl bénéficie d'une quantité faramineuse de packages sur CPAN.
IRC
Newbie Connect
Liens
Partenaires
Réglement
Goodies
L'incubateur
L'équipe
Hall Of Fame
