Discussion :

[Celelibi]

dotmessy, je pensais avoir donné une réponse assez satisfaisante. Peut-être que ma réponse était incomplète, dans ce cas j'aimerais corriger certains "détails" de ton intervention.


Dans n'importe quel langage, l'accès au disque se fait via les API du système, ces appels à l'API se retrouvent dans le programme exécutable. C'est le boulot des lib et drivers de gérer l'accès au disque, le cache et toutes ces choses. Bien entendu les lib ont une API différentes d'un système à l'autre. (Il est bien entendu trivial de dire que l'implémentation est radicalement différente)

exemple linux :
une gestion de memoire est faite par parcelle --> un block --> une page
windows n'a pas la capacité de géré ton tas de memoire de la sorte d'ou les les problèmes lors de malloc ( unix et windows , si tu code en C tu connais ce pb )

Ah bon ? Windows ne gère pas la mémoire en la découpant en pages ?


Concernant l'assembleur, il existe principalement deux syntaxes, la syntaxe AT&T et la syntaxe Intel. Mais ce n'est rien d'autre qu'une syntaxe, il existe aussi bien sous Linux que sous Windows des assembleurs qui comprenne la syntaxe AT&T et la syntaxe Intel. Ça n'a rien à voir avec le système d'exploitation.
Et puis le codage des instructions est le même sous Linux et sous Windows puisque c'est le processeur qui défini quel code correspond à quel action (et donc à quelle instruction). Heureusement qu'il n'existe pas une documentation Intel par système (tu sais ze doc qui donne les opcode qui correspondent aux instructions assembleur).


Bref, dotmessy tu serais prié de vérifier ce que tu dis.

[dotmessy]

heu je veux pas jouer au chieur :

1. le kernel linux utilise la norme comme ta dis et j'ai dis : AT & T (windows non )
2. j'ai jamais dis que l'adressage INTEL etais different sous chaque systeme (relie le post que j'ai fais )
3. l'api que tu parle , n'adresse pas a la meme adresse les Disques dur sous linux , mais au meme IRQ 15
4. Windows est obliger de gerer les adressages par segmentation, par concequent les programmes le sont aussi . pour la mémoire : windows gere un tas de segment dedier a l'ensemble ( sauf sous vista , normalement) rapel toi des access memoirie denied ecrans bleu , ecrasement memoir Etc ..

linux == slab allocator , pagination ou padding, allocation segment --> block de segment --> page de segmentation
introduction de la gestion dynamique de mémoire et partage

reference linux :
le noyau linux 2.4 , book oreilly ISBN : 2-84177-141-5

et le gestion par page a ete introduit sous vista.

[Shugo78]

on se calme !
pas de combats ici !

[souviron34]

bon je voie que sur ton poste pas eu la bonne reponse, je vais t'expliquer

Avant de rejouer au redresseur de torts, avec tous les participants ayant contribué, je te prierai de savoir de quoi tu causes......

Ta réponse est partielle, technique, et n'expose pas le fond du problème.

Si elle était LA réponse, alors pourquoi un exécutable Linux ne tournerait pas sur un SUN , un HP, une SGI, un Vax, qui utilisent le même type d'assembleur et de pagination ??

Parmi d'autres, Celelibi et moi avons tenté d'exposer le problème FONDAMENTAL.

C'est un problème GENERAL. C'est dû à la CONSTRUCTION des machines, et pas uniquement à l'OS.

Le code binaire pour exécuter une certaine tâche est DIFFERENT suivant les processeurs (voir par exemple le secteur de boot. Pourquoi quand on installe bi-partition Windows NE PEUT PAS être sur la deuxième ? parce qu'il attend pour booter une série d'instructions à l'adresse de DEBUT DU DISQUE, pas de la partition).

Alors peut-être n'avons nous pas réussi à expliquer correctement, mais certainement mieux que toi, et en plus générique.


C'est EXACTEMENT la même chose que pour les cartes graphiques. Un jeu d'instructions pour une NVIDIA ne sera pas COMPRIS par une carte Matrox, par exemple.

[Celelibi]

Ok dotmessy on reprend calmement.

1. Le fait que l'on trouve de l'assembleur suivant la syntaxe AT&T dans le noyau Linux n'induit en rien que l'AT&T soit "l'assembleur de Linux".
Le compilateur gcc (utilisé dans 99% des cas pour compiler le noyau) permet même de mélanger les deux syntaxes.

2. Je n'ai parlé d'adressage à aucun moment. Peut-être que j'ai mal compris quand tu as dit "mais le codage diffère". Ce que j'ai compris c'est que les opcodes sont différentes sous windows et linux ce qui est évidemment faux.

3. Que l'API adresse une autre zone mémoire d'un système à l'autre, ce n'est pas important ici. Car la question n'est pas le portage de l'API mais de l'application qui utilise l'API.

4. La pagination de la mémoire sous Windows est bien antérieur à Vista. J'ai souvenir d'une doc sur windows 95 qui donnait notamment la taille des pages utilisés par windows. De plus, segmentation et pagination ne sont pas incompatibles, et sont même utilisés de concert aussi bien sous Windows que Linux.
Mais encore une fois, ceci n'a pas d'importance ici, car ces mécanismes sont invisibles pour le programmeur. Et même le programme binaire exécutable résultant de la compilation n'est pas conscient de ces mécanismes.


Pour finir je dirais que __snake__ est un néophyte et ne comprend sûrement rien à notre baratin actuel.

[gusgus]

Moi il y a un truc que je comprend pas.L'assembleur,c'est les instructions données au microprocesseur non?Alors que l'assembleur change d'un processeur a un autre OK,mais d'un OS a un autre

[millie]

Un fichier exécutable n'est pas uniquement un morceau de code machine. C'est beaucoup plus. Il y a des entêtes qui vont indiquer des informations (type d'exécutable (PE, ELF, DLL, SO)). Ceci étant totalement différent suivant l'OS.

Lors de l'exécution, le processus va certainement demander l'accès à des bibliothèques partagées, ou va peut être charger dynamiquement des bibliothèques. Et donc utiliser des fonctions différentes suivant l'OS. Par exemple, sous Windows, un exécutable va pouvoir utiliser Kernel32.dll, ce qui n'aurait aucun sens sous Unix (qui lui pourrait utiliser libc.so)

[Celelibi]

Petite précision pour gusgus : l'assembleur n'est qu'un langage, le processeur ne comprend que le langage machine.
Le langage machine est une suite d'opcodes, c'est à dire des codes qui correspondent à chaque instruction du langage assembleur.

Note pour millie, les fichiers .so sont en fait des ELF. Pour les .dll je ne sais pas, si ce sont des PE.

[millie]

Note pour millie, les fichiers .so sont en fait des ELF. Pour les .dll je ne sais pas, si ce sont des PE.

Le lien http://fr.wikipedia.org/wiki/Portabl...le_File_Format a l'air de me dire que les dll, exe sont au format PE tous les deux. Enfin, ce que je voulais dire, même si c'est le même format, ça ne s'exécute pas de la même manière

[Xtof68]

Pour les .dll je ne sais pas, si ce sont des PE.

Il me semble que c'en sont. Mais comme a dit Millie, bien que les .exe et les .dll soient des PE, leur mode d'éxécution n'est pas le même.

[kromartien]

Bonjour. Vous avez donné une grande quantité d'informations, je voudrai savoir si ce que je dis est correct.

Je crois qu'il est possible de dire que un OS c'est à la base un kernel (noyau). Ce noyau est appelé ainsi, car à juste titre, c'est le centre de l'OS, des processus qui fonctionnent sur l'ordinateur. Il coordonne, dans le cas d'un système multi-tâche possiblement multi-utilisateur, l'utilisation du temps machine pour chaque processus. Ainsi, le format binaire utilisé, comme vous l'aviez dit, contient essentiellement les informations nécessaires au contrôle d'exécution par l'ordonnanceur du noyau. C'est pour cela, qu'à noyau différent, exécutable différent. En réalité c'est surtout une question de noyau.

Le kernel Windows est multi-tâche, le kernel Linux permet une utilisation multi-tâche et multi-utilisateur. Mais la différence fondamentale est donc l'implémentation des exécutables au sein du noyau utilisé. Si elle concorde avec le format du code compilé, aucun problème. Sinon, le noyau enverra l'exécutable paître.

enfin c'est comme ça que je le comprends

[Celelibi]

Le noyau est certes l'élément centrale, mais il ne serait rien sans le reste du système d'exploitation. Linux ne serait rien sans GNU.

Un noyau seul ne rend pas un ordinateur utilisable. Le noyau gère la mémoire, les processus et les accès au matériel (généralement par le biais de drivers).

Je ne sais pas si c'est le noyau qui défini le ou les formats d'exécutables, mais dans tous les cas, ce n'est pas lui qui a besoin de connaitre les en-têtes.
Les en-têtes ELF ou PE définissent entre autre, quelle lib doit être chargée, et c'est des librairies du système qui vont s'occuper de charger ces lib en mémoire si ce n'est pas déjà fait.

[icer]

le format de l'exécution sur windows c'est .exe et sous unix ?

Sous unix les fichiers exécutables sont identifié par un attributs gérer par le systéme (voir le système de droits des fichiers linux). Sous windows ils porte l'extensions .exe. Tout simplement, Les deux systèmes gérent les exécutables différement.

Mais je trouve que sont linux la méthode est plus "logique". Mais là je m'écarte du sujet.

[jlliagre]

Je ne pense pas que sous Windows ce soit fondamentalement différent de sous Unix.

Si, c'est fondamentalement différent.

Sous Unix (et Linux) le noyau analyse le contenu d'un fichier pour déterminer de quel type d'exécutable il s'agit, et la présence ou non d'une extension n'est absolument pas prise en compte.
La présence du droit d'exécution est par contre un prérequis sous Unix.

Sous Windows, l'extension est à la base du système de reconnaissance du type d'un fichier. Voir par exemple les deux descriptions de bugs suivantes pour s'en convaincre:
http://support.microsoft.com/kb/163017
http://support.microsoft.com/kb/191005

L'extension n'est utilisée que pour présupposer du type de fichier, en renommer un en .exe n'en a jamais fait un exécutable.

Si, ça en fait un exécutable qui plante. La routine quoi ...

C'est le même système,

C'est deux systèmes très différents.

mais Linux utilise plutôt la notion de chemin pour l'emplacement des binaires

La notion de PATH existe aussi sous Windows.

, tandis que Windows va tenter par défaut d'exécuter un fichier qui porte une extension .exe

Cependant, au niveau du noyau et de la gestion des exécutables, le principe ne doit pas être totalement antinomique entre un exécutable windows et un exécutable Linux.

Ben si.

[jlliagre]

Oui, bien sur.

Si on ignore les différences, on arrive fatalement à la conclusion que les deux systèmes sont équivalents ...

[jlliagre]

On se vouvoie sur ce forum ?

Pour revenir à la question initiale:

Le processus de compilation sous Windows n'est pas fondamentalement différent de celui existant sous Unix.

Le format des fichiers générés est différent pour des raisons évidentes et déjà clairement expliquées dans cette discussion.

[azertyman]

Les executables, et la manière de les executer dépends des systèmes d'exploitation.

Pour un même programme en c (par exemple), il faut le compiler pour windows et le compiler pour GNU/Linux ; si tu veux le faire fonctionner sur les deux.

La seule alternative que tu as, serait d'utiliser une machine virtuelle, par exemple avec java. Une fois compilé, il s'execute à l'aide d'une machine virtuelle.
Tu crées ton programme, tu le compiles ; et tu peux l'executer sur tout systèmes ayant une machine virtuelle java d'installé.

[jlliagre]

Une machine virtuelle n'est pas forcément nécessaire. Une couche d'émulation de l'O/S et/ou des bibliothèques peut suffire si l'architecture matérielle est la même (x86).

On peux par exemple exécuter des binaires Linux sous BSD et sous Solaris 11.

On peut aussi exécuter certains binaires Windows sous Linux et Solaris à l'aide de Wine.