Discussion :

[Ulrik18]

Bonjour.

J'aimerai simplement savoir, s'il serait possible d'exécuter un programme sur une machine neuve (aucun système d'exploitation installé dessus). Si Oui ? En quel langage doit-il etre écrit ?

Merci.

[Jedai]

Comment crois-tu que les systèmes d'exploitation fonctionnent ? Ce ne sont que des programmes après tout !
Néanmoins il faut bien comprendre que si tu n'as pas d'OS, tu dois te passer d'un tas de services bien pratique, il faut discuter directement avec le matériel pour faire quoi que ce soit et cela pose énormément de problème dans un monde (PC) où d'innombrables variations sont disponibles. Rien que pour gérer la mémoire tu dois le faire à la main, l'affichage, etc...
En d'autres termes c'est un monde bien différent de la programmation sous un OS (même en mode kernel).

N'importe quel langage peut le faire en théorie, bien que certains ne soient pas équipés de base des outils pour communiquer avec la machine à un niveau si rudimentaire ou que leur compilateurs ne sache pas compiler pour un mode non-protégé.

--
Jedaï

[Ulrik18]

Merci de ta réponse Jedaï.
Mais, si par exemple, le langage C sois capable de le faire, y'a t-il un type de compilateur particulier pour ça ?
Parce qu'en général un compilateur C produit un code compréhensible par le SE sous lequel il est installé(raison pour laquelle un programme compilé sous windows ne marche pas sous linux et vis versa). Lorsqu'il n'y a donc plus de SE, comment la machine fera t-elle pour comprendre le code produit par le compilateur ?

[Garulfo]

Merci de ta réponse Jedaï.
Mais, si par exemple, le langage C sois capable de le faire, y'a t-il un type de compilateur particulier pour ça ?
Parce qu'en général un compilateur C produit un code compréhensible par le SE sous lequel il est installé(raison pour laquelle un programme compilé sous windows ne marche pas sous linux et vis versa). Lorsqu'il n'y a donc plus de SE, comment la machine fera t-elle pour comprendre le code produit par le compilateur ?

Non. Un compilateur produit un code compréhensible par la machine. L'OS offre des facilités c'est à dire des morceaux de code « déjà prêt » si tu veux. Ils peuvent être chargés statiquement lors de la compilation ou dynamiquement lors de l'exécution (les DLL sous Windows par exemple). C'est une image assez simple, mais ce qui compte c'est qu'au final tout n'est qu'une suite d'instruction pour le processeur et pourrait donc théoriquement se passer de l'OS.

[Ulrik18]

Non. Un compilateur produit un code compréhensible par la machine.

De Quelle machine s'agit-il? la machine physique (processeur)? Moi je pense que non !
Un compilateur produit un code compréhensible par l'OS (machine virtuelle).

Ils peuvent être chargés statiquement lors de la compilation ou dynamiquement lors de l'exécution (les DLL sous Windows par exemple).

ça c'est l'étape d'édition de liens. si on récupère le fichier produit par la compilation avant d'attaquer cette phase (fichier objet), on se rend compte qu'il est dépendant de l'OS, à partir de lui, impossible de faire l'édition de liens sur un autre OS.

... mais ce qui compte c'est qu'au final tout n'est qu'une suite d'instruction pour le processeur et pourrait donc théoriquement se passer de l'OS.

Je ne pense pas qu'on puisse comme ça se passer de l'OS, parce que c'est lui qui traduit pour le processeur.
Quand par exemple tu manipules les adresses mémoires à l'aide des pointeurs en C. Un pointeur qui pointe sur une zone mémoire non allouée (par l'os) n'empêche en rien la compilation, mais à l'exécution, accéder (en écriture le plus souvent) à cette zone mémoire au moyen de ce pointeur provoque un bug qui stop le programme!!! C'est le control de l'OS(qui ne traduit rien au processeur qui ne l'arrange pas). le processeur aurait tout bêtement effectuer l'opération.
C'est aussi l'os qui alloue la mémoire statique, comme dynamique, s'il refuse le programme n'a rien à dire !

Au final, je pense donc que le compilateur produit un code compréhensible par le SE, et ensuite le SE traduit pour la machine physique.
Je me demande donc comment on fait pour que sans SE la machine comprenne notre programme.

Merci !

[Jedai]

Peut-être que tu devrais commencer par écouter la sagesse des anciens (désolé Garulfo ) plutôt que de la refuser si elle ne correspond pas à ta compréhension erroné du sujet...

Le code objet produit par un compilateur est parfaitement exécutable directement sur le processeur, il n'est pas vraiment spécifique à l'OS à part en cela qu'il se repose sur des services fournis par l'OS. Mais toutes les instructions sont exécutées directement par le processeur.

ça c'est l'étape d'édition de liens. si on récupère le fichier produit par la compilation avant d'attaquer cette phase (fichier objet), on se rend compte qu'il est dépendant de l'OS, à partir de lui, impossible de faire l'édition de liens sur un autre OS.

Ce n'est vrai que parce qu'il utilise des librairies spécifique à l'OS, rien à voir avec une quelconque nature intrinsèque du code objet qui différerait d'un OS à l'autre.

De Quelle machine s'agit-il? la machine physique (processeur)? Moi je pense que non !
Un compilateur produit un code compréhensible par l'OS (machine virtuelle).

Un OS n'est pas une VM !!

Quand par exemple tu manipules les adresses mémoires à l'aide des pointeurs en C. Un pointeur qui pointe sur une zone mémoire non allouée (par l'os) n'empêche en rien la compilation, mais à l'exécution, accéder (en écriture le plus souvent) à cette zone mémoire au moyen de ce pointeur provoque un bug qui stop le programme!!! C'est le control de l'OS(qui ne traduit rien au processeur qui ne l'arrange pas). le processeur aurait tout bêtement effectuer l'opération.
C'est aussi l'os qui alloue la mémoire statique, comme dynamique, s'il refuse le programme n'a rien à dire !

Ta compréhension de la gestion de mémoire semble très floue. Un programme n'a pas besoin de consulter l'OS chaque fois qu'il consulte une adresse bien que celle ci ne corresponde pas à une adresse physique réelle en mémoire, c'est le CPU lui-même qui se charge de la traduction (heureusement vu la fréquence d'une telle opération). L'OS se charge effectivement d'allouer de la mémoire, mais cela signifie simplement qu'il modifie les tables de traduction du CPU, pas qu'il s'interpose complètement entre le programme et le CPU. De plus les opérations d'allocation ou désallocation de la mémoire n'ont rien de magique du point de vue du code objet, il s'agit simplement d'appel de fonctions de librairies fournies par l'OS qui elles-même discutent avec le Kernel par l'intermédiaire d'appel système.


Plutôt que de continuer cette discussion, je te conseille de lire quelques cours système ou de lire le Tanenbaum qui devrait t'éclairer sur le fonctionnement réel des ordinateurs.

--
Jedaï

[millie]

Quand par exemple tu manipules les adresses mémoires à l'aide des pointeurs en C. Un pointeur qui pointe sur une zone mémoire non allouée (par l'os) n'empêche en rien la compilation, mais à l'exécution, accéder (en écriture le plus souvent) à cette zone mémoire au moyen de ce pointeur provoque un bug qui stop le programme!!! C'est le control de l'OS(qui ne traduit rien au processeur qui ne l'arrange pas). le processeur aurait tout bêtement effectuer l'opération.
C'est aussi l'os qui alloue la mémoire statique, comme dynamique, s'il refuse le programme n'a rien à dire !

Quand tu exécutes un programme, il s'exécute dans un mode protégé.
Ce mode n'est pas lié à une notion dans l'OS, c'est des composants électroniques comme la MMU qui le permettent. Elle gère les tentatives d'accès à la mémoire hors plage avec une interruption. Sous UNIX, cette interruption est traduit en signal SIGSEGV. On peut d'ailleurs très bien intercepter toutes les signaux SIGSEGV et continuer le programme sous UNIX. Si tu fais ton propre OS, à toi de gérer l'interruption en faisant ce que tu veux.

[iammisc]

Une systeme d'exploitation est une programme.

[souviron34]

Une systeme d'exploitation est une programme.

j'aime les remarques constructives