NewbieContest

Salutations !

Je voudrais juste poser quelques questions...
Déjà, qu'est-ce qui fait qu'un système d'exploitation supporte un programme, et un autre non ? Le language de programmation, la façon dont c'est compilé ? Où pourais-je trouver des détails sur le sujet ?

Si il s'agit du language de  programmation, quels sont les languages compatibles sur Linux et Windows à la fois ?

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

Sinon je deplace le topic dans la categorie plus approprié : informatique.

Enjoy

The lsd

hello Snake046

Un programme qui va s'exécuter sur un system (unix/windows ou autre) ne s'executera jamais sur un autre system, car il va avoir été compiler pour être utilisé spécifiquement sur celui-ci. Windows ne gère pas l'environnement (accès disque, gestion des peripherique, de la mémoire) comme peu le faire un system unix et inversement, voilà pourquoi un programme compilé pour windows ne s'exécutera jamais sous linux.

Pour exécuter un programme sur l'un ou l'autre system il faut un langage qui ne nécessite pas de compilation donc un langage interprété, (comme perl par exemple, ou plus simple le java..)

en espérant avoir répondu à ta question =)

Le souci principal est surtout que Windows et Linux n'utilisent pas du tout le même format d'exécutable (PE et ELF).

Hmmm...
Perl est compilé. Bon, à la volée par l'interpréteur, mais compilé tout de même. :)
Java est lui aussi compilé, mais pas en langage machine. C'est pourquoi il nécessite une couche d'abstraction supplémentaire (la JVM).

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 !

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 ?

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 ?
Yatil donc des languages qui ne fonctionnent pas sous Linux ou Windows ?

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.


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

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.

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.

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.

Cette discussion devient de plus en plus intéressante :P
Ca mérite presque de la transformer en FAQ "programmes et systèmes d'exploitation", vous ne trouvez pas ?

(sous réserve que lordOric explique quelques termes techniques qui ne sont pas forcément à la portée des newbies ;))

Heuuu...  Nan. :)  C'est extrêmement simpliste et ça se rapporte au contexte de la question.

Et puis, je ne garantis pas que je ne dis pas de conneries quelque part (d'autant que quand je me lâche comme ça, c'est que j' ai bu :) ).

J'ai pas dit que c'était simpliste, mais que c'était intéressant :)