Du point de vue du code compilé, quelle est la différence entre un programme compilé pour un os contre un autre (Linux vs windows par exemple). Le programme ne s'exécute-t-il pas directement sur le processeur? Ou est-ce parce que le programme doit référencer des bibliothèques spécifiques au système d'exploitation?
Les programmes compilés ordinaires "s'exécutent directement" sur le CPU, mais un programme ne s'exécute pas dans le vide:
De nombreux programmes reposent sur des bibliothèques ( DLLsou .sobibliothèques) externes chargées dynamiquement . La façon de les relier est au compilateur / éditeur de liens, et chaque système d'exploitation a des normes différentes. Cependant, il existe également des programmes "statiquement liés" qui fournissent tout leur propre code.
Un système d'exploitation moderne ne donne pas un contrôle complet de l'ordinateur à un programme en cours d'exécution. Les programmes reposent sur des «appels système» pour les E / S, l'accès au matériel et des choses comme les signaux et l'entrée en veille. Les services et l'interface disponibles sont définis par l'OS. Le système d'exploitation contrôle également les parties du système (mémoire, registres, interruptions) que le programme est autorisé à utiliser.
Un programme GUI doit également fonctionner à travers l'environnement utilisateur graphique afin de se dessiner sur l'écran. Mais vous y avez probablement déjà pensé.
Pour ces raisons, les applications indépendantes du système d'exploitation doivent s'appuyer sur une "machine virtuelle" quelconque, comme celle fournie par le runtime java. Fondamentalement, une machine virtuelle fournit une interface standard aux ressources du système d'exploitation (E / S, signaux, etc.). Bien sûr, java ou python interprètent également "bytecode" au lieu de traiter les bizarreries du jeu d'instructions d'Intel; mais c'est une autre histoire.
Différents systèmes d'exploitation ont également des fonctionnalités différentes. Windows a des ports d'achèvement d'E / S, Linux n'en a pas. FreeBSD a kqueue, Linux non. Linux a des futex, pas Windows. Ils ont également différentes façons de faire la même chose - quels paramètres passez-vous pour ouvrir un fichier? Dans quel ordre vont-ils? Comment invoquez-vous spécifiquement la fonction "ouvrir un fichier" du système d'exploitation?
la source
En général, les programmes ne sont pas compatibles en raison des différences dans leur interface binaire d'application (ABI) .
NON ! C'est le travail du système d'exploitation, d' empêcher les applications de s'exécuter "directement" sur le CPU. En règle générale, au niveau le plus bas (c'est-à-dire celui sur lequel l'API du système d'exploitation est construit), une application s'interface avec le noyau du système d' exploitation .
Oui . De nombreuses bibliothèques de système d'exploitation sont écrites pour faciliter l'interfaçage avec le système d'exploitation lui-même, mais il y en a autant qui sont écrites pour être multiplateforme. Celles-ci masquent l'interface du système d'exploitation de bas niveau au développeur et supposent que la version compilée pour ce système d'exploitation sera disponible au moment de l'exécution (voir ci-dessous).
Bien que les bibliothèques puissent être écrites de manière multiplateforme, lorsqu'elles sont compilées, elles ne peuvent pas être exécutées multiplateforme. Ils doivent encore être recompilés pour le système d'exploitation cible spécifique, encore une fois pour utiliser les composants sous-jacents particuliers du système d'exploitation (noyau).
Enfin, les fichiers exécutables eux-mêmes contiennent souvent des en-têtes de chargement binaires très spécifiques, etc. (par exemple le format de fichier exécutable PE [.exe, .dll, etc ...] pour Windows ou ELF pour Linux [none, .o, .so , etc...]). Ceux-ci peuvent également inclure du code pour charger les fichiers binaires spécifiques au système d'exploitation compilés pour une bibliothèque de logiciels particulière.
Enfin, du point de vue d'un programmeur: convention d'appel . Le code compilé transmet les variables aux fonctions d'une manière donnée (c'est-à-dire via des registres ou sur la pile) dans un ordre très particulier. Même alors, il faut également convenir de qui est responsable du "nettoyage" des appels de fonction (l'appelant ou l'appelé?). Bien qu'il existe plusieurs conventions d'appel x86 standard et largement utilisées , certaines peuvent ne pas être prises en charge par certains systèmes d'exploitation (cela fait partie de l'ABI).
la source