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.
Version imprimable
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.
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ï
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.
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).
ç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.
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 !
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.
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.Citation:
ç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.
Un OS n'est pas une VM !! :aie:Citation:
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).
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.Citation:
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 !
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ï
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.
Je m'excuse d'avoir voulu jouer au grand savant.
Je constate que ce qu'il me faut c'est des cours de système d'exploitation, programmation système, je m'y mets de suite.
S'il vous plait, j'aimerai aussi savoir, si quelqu'un a déja pu écrire un programme C tout simple (qui dit bonjour, calcul une puissance ...) qui fonctionne sans le SE (bootable peut-être). Si oui, j'aimerai être guidé.
Ben, regardes du côté de RTEMS, MarteOs ou FreeRTOS. Ce sont des exécutifs temps réel de petite taille qui te déchargerons déjà de la partie gestion du boot, des affichages etc...
Enfin si tu veux te colletiner la gestion de l'affichage à la main (même d'un hello world), je crains qu'il ne te faille faire des bouts d'assembleur quand même.
Une systeme d'exploitation est une programme.
Oui c'est possible si tu est un gros crack en assembleur x86.
Le sujet a été abordé dans le forum assembleur.
De préférence avoir une disquette il faut que tu programmes un boot strap et un "boot loader" qui se charge en mémoire.
La disquette doit être formatté selon tes propres routines assembleur..
1-le mode protégé c'est uniquement pour les CPU compatibles avec Intel ( donc AMD et feu Cyrix).
Avec d'autres types de CPU ( Motorola, IBM..processeurs RISK ) cela n'existe pas ils sont par essence multitaches
Mais comme c'est Intel qui domine le marché mondialement dans ce domaine..
2-quand un ordinateur "compatible PC" démarre après la mise sous tension, sans OS normalement à moins de preuve du contraire ,le CPU tourne en mode réel.
C'est l'OS qui le fait basculer en mode protégé
Re il faut que tu te fasses une disquette de boot avec tes propres routines et que tu charges ce que l'on appelle un "shell" ou interpréteur de commandes en mémoire bref faire un mini-os
Sinon cela doit être possible de faire un seul programme chargé en mémoire il faut que tu gères par toi-même les allocations mémoires , l'affichage vidéo,les entrées-sorties clavier.
C'est possible avec les interruptions assembleur genre int10.
Tu peux même faire un programme en vraies couleurs ( haute résolution ) avec le mode VESA.
Concernant le mode protégé c'est pour gérer le multitache mais il faut déjà avoir fait ton propre mini-os.
Un conseil primordial tout de même : exerces-toi sur une vieille machine plutot qu'une machine dernier cri et toute neuve parce que tu risques de détériorer le BIOS si tu fais de mauvaises manips en assembleur
Ok Millie :D
Ceci dit peut-être que les machines les plus récentes passent directement en mode protégé je ne sais pas il faut vérifier.