Un kernel de système d’exploitation est-il un interpètre pour tous les autres programmes?

Donc, à ma connaissance, il existe deux types de programmes, ceux qui sont interprétés et ceux qui sont compilés. Les programmes interprétés sont exécutés par un interpréteur qui est une application native pour la plate-forme, et les programmes compilés sont eux-mêmes des applications natives (ou logiciels système) pour la plate-forme sur laquelle ils se trouvent.

Mais ma question est la suivante: y a-t-il autre chose que le kernel qui soit directement géré par le processeur? Un exécutable Windows est un “exécutable Windows”, pas un exécutable x86 ou amd64. Est-ce que cela signifie que tout autre processus qui n’est pas le kernel est littéralement interprété par le kernel de la même manière qu’un navigateur interprète Javascript? Ou le kernel place-t-il ces processus sur le “bare metal” sur lequel repose le kernel?

S’ils utilisent le “bare metal”, comment, disons, Windows sait-il qu’un programme est un programme Windows et non un programme Linux, car ils sont tous deux compilés pour les processeurs amd64? Si c’est à cause du “format” de l’exécutable, comment cet exécutable est-il capable de s’exécuter sur le “bare metal”, puisque pour moi, le fait qu’il soit formaté pour s’exécuter sur un OS particulier nécessiterait une certaine interprétation pour qu’il fonctionne.

Cette question est-elle trop compliquée pour Stack Overflow?

Ils fonctionnent sur le “bare metal”, mais ils contiennent des éléments spécifiques au système d’exploitation. Un fichier exécutable fournira généralement certaines instructions au kernel (qui sont, sans doute, “interprétées”) quant à la manière dont le programme devrait être chargé en mémoire, et le code du fichier fournira des moyens lui permettant de “s’accrocher” au fonctionnement en cours. système, par exemple par l’API d’un système d’exploitation ou via des pilotes de périphériques. Une fois qu’un tel programme non interprété est chargé en mémoire, il s’exécute sur le bare metal mais continue à communiquer avec le système d’exploitation, qui s’exécute également sur le bare metal.

À l’époque des systèmes d’exploitation monoprocessus, il était courant que les exécutables «saisissent» essentiellement le contrôle de l’ordinateur tout entier et communiquent directement avec le matériel. Des ordinateurs comme Apple] [et le Commodore 64 fonctionnent comme ça. Dans un système d’exploitation multitâche moderne comme Windows ou Linux, les applications et le système d’exploitation partagent l’utilisation du processeur via un système multitâche complexe, et les applications accèdent au matériel via un ensemble d’abstractions intégrées à l’API du système d’exploitation et à ses pilotes. Suivez un cours sur la conception du système d’exploitation si vous êtes intéressé à apprendre beaucoup de détails.

En rebondissant sur la réponse de Junaid, la façon dont le kernel bloque un programme de faire quelque chose de “drôle” est en contrôlant l’allocation et l’utilisation de la mémoire. Le kernel exige que la mémoire soit demandée et accessible via son API, et protège ainsi l’ordinateur contre les access “non autorisés”. À l’époque des systèmes d’exploitation monoprocessus, les applications avaient beaucoup plus de liberté pour accéder directement à la mémoire et à d’autres choses, sans impliquer le système d’exploitation. Une application s’exécutant sur un ancien Apple] [peut lire ou écrire sur n’importe quelle adresse de la RAM qu’il souhaite sur l’ordinateur entier.

Une des raisons pour lesquelles une application compilée ne sera pas simplement “exécutée” sur un autre système d’exploitation est que ces “hooks” sont différents pour les différents systèmes d’exploitation. Par exemple, une application qui sait comment demander l’allocation de mémoire vive à partir de Windows peut ne pas savoir comment la demander à partir de Linux ou de Mac OS. Comme Disk Crasher l’a mentionné, ces instructions d’access de bas niveau sont insérées par le compilateur.

Je pense que vous confondez les choses. Un programme compilé est au format lisible par machine. Lorsque vous exécutez le programme, le kernel alloue de la mémoire, cpu, etc. et s’assure que le programme n’interfère pas avec les autres programmes. Si le programme nécessite un access à des ressources matérielles ou à un disque dur, le kernel le gérera afin que le kernel se trouve toujours entre le matériel et les logiciels exécutés dans l’espace utilisateur.

Si le programme est interprété, alors un interpréteur approprié pour cette langue convertira le code en machine lisible à la volée et le kernel fournira toujours les mêmes fonctionnalités, comme l’access au matériel, et s’assurera que les programmes ne font rien de drôle, comme accéder à d’autres programme mémoire etc.

La seule chose qui fonctionne sur “bare metal” est le code du langage d’assemblage , qui est extrait du programmeur par de nombreuses couches du système d’exploitation et du compilateur. De manière générale, les applications sont compilées dans une architecture de système d’exploitation et de processeur. Ils ne fonctionneront pas sur d’autres systèmes d’exploitation, du moins pas sans une structure compatible (par exemple, Mono sous Linux).

À l’époque, beaucoup de code était écrit sur du bare metal en utilisant des assembleurs de macros , mais cela est pratiquement inconnu sur les PC d’aujourd’hui. (Et il y avait même un temps avant les assembleurs de macros.)