Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Pourquoi la compilation entre unix et windows est différente ?
Bonjour .
une question un peut newbie , mais quand meme je vous demande .
Lorsqu'on code une source C par example et en la compile sous Unix .
Elle marche normale , mais si en la déplace vers Windows elle marche pas .
Malgré que les synthaxe de codage pour le language sont les memes .
Il ne faut pas oublier que les librairies que tu utilises ne sont pas toutes ... "portables"
Donc, dans la stricte utilisation des librairies portables tu ne rencontrera aucun problème (stdio, stdlib... pour ne citer que ces basiques).
Saches qu'il y a également des fonctions dans ces librairies qui ne sont pas portables
Porter un logiciel ce n'est, en gros, pas copier coller la source et la compiler
@vincent magnin
Merci de l'interet que vous portez vers mon poste ,
Mais est ce que vous pouvez mieu m'eclairez ?
La portabilitée est importante.
Les appels systèmes et les normes sont différentes.
La portabilitée , c'est quoi ?
En informatique, la portabilité d'un programme est caractérisée par sa capacité à fonctionner plus ou moins facilement dans différents environnements d'exécution tels que Windows, Unix ou encore Mac
bon je voie que sur ton poste pas eu la bonne reponse, je vais t'expliquer
cela viens du fait des adressages memoire de base de l'acces au disque entre autre.
sous linux le dump de lecture du disque dur se fait pas a la meme adresse que le dump du systeme windows
( j'ai plus les adresse en tete mais je peux te les retrouvé si tu veux )
en plus sous linux, tu utilise un autre systeme de codage de donné physique sur le disque ( ext et NTFS sont totalement different )
en plus les gestions des instruction sont propre au systeme de par sa conception.
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 )
certe les Instructions machines assembleur sont theorique les meme hors si tu code en Assembleur sous linux et windows su y vera 2 norme de codage différent .
les compilateur linux utilise la NORME AT tandisque que windows utilise une autre norme ( je sais plus sont nom )
tu va me dire en ASM un :
mov AX,2 est similiaire a un MOV 2,%AX sous linux
oui l'adressages est le meme ton registre du CPU est le meme
mais le codage diffère
d'ou l'interpretation du code par le compilateur different de linux a windows
voila j'espere t'avoir eclaircie un peu le probleme
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)
Ah bon ? Windows ne gère pas la mémoire en la découpant en pages ?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 )
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.
heu je veux pas jouer au chieur :
- le kernel linux utilise la norme comme ta dis et j'ai dis : AT & T (windows non )
- j'ai jamais dis que l'adressage INTEL etais different sous chaque systeme (relie le post que j'ai fais )
- l'api que tu parle , n'adresse pas a la meme adresse les Disques dur sous linux , mais au meme IRQ 15
- 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 segmentationreference linux :
introduction de la gestion dynamique de mémoire et partage
le noyau linux 2.4 , book oreilly ISBN : 2-84177-141-5
et le gestion par page a ete introduit sous vista.
on se calme !
pas de combats ici !
Avant de rejouer au redresseur de torts, avec tous les participants ayant contribué, je te prierai de savoir de quoi tu causes......Envoyé par dotmessy
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.
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.
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
tutoriel Ogre:
http://gusgus.developpez.com/Ogre/
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)
Répondre avec citation
Partager