Un shell comme le bash ou command.com (jusqu'à Windows ME) ou CMD.EXE (dans les versions ultérieures) fournit une interface qui (entre autres) accepte des commandes de l'utilisateur. À quoi ressemble un système d'exploitation avant l'exécution d'un shell? Comment les systèmes étaient-ils utilisés avant le développement du premier shell (par exemple, UNIX au début des années 1970)? Si un ordinateur ne peut même pas accepter de commandes (il n'y a pas de ligne de commande), comment un utilisateur peut-il interagir avec lui? Quelle est cette interface la plus basique? Puis-je exécuter cette interface dans un émulateur de terminal ou n'y a-t-il aucun moyen de contourner un shell?
Réponses
Trop de publicités?
À quoi ressemble un système d'exploitation avant qu'un shell ne soit lancé?
Cela dépend de l'OS et de sa configuration. Linux peut être configuré pour écrire du texte de démarrage sur un périphérique de console, qu'il s'agisse d'une console en mode texte, d'une console framebuffer ou d'un port série. Il peut également être configuré pour être parfaitement silencieux. Certains systèmes d'exploitation peuvent écrire des informations de diagnostic dans une mémoire non volatile accessible en mettant le système en mode développeur, débogage, ou diagnostic. De nombreux systèmes d'exploitation prennent en charge la sortie d'informations de démarrage et de diagnostic vers une forme de UART, qui peut être disponible d'une manière ou d'une autre sur l'unité, même si elle est cachée à l'utilisateur (googler "Ajouter un port série à DD-WRT" pour des exemples où les fabricants cachent des ports série et comment y accéder).
Un OS n'a pas besoin d'avoir d'affichage externe du tout - c'est juste un autre périphérique pour l'OS.
Comment les systèmes étaient-ils utilisés avant que le premier shell ne soit développé (par exemple UNIX au début des années 1970)?
Essentiellement (et en laissant de côté beaucoup de détails mais cela devrait vous donner une idée) - Vous chargiez votre programme, soit en basculant des commutateurs sur un panneau, soit en utilisant un lecteur de bande perforée (ces dispositifs écriraient directement en mémoire sans l'intervention du processeur) puis démarriez le processeur avec un autre commutateur. Le processeur exécutait ce programme, générait sa sortie, puis s'arrêtait. C'est un traitement par lots par opposition à un traitement interactif. Si vous vouliez exécuter un programme différent, vous deviez recommencer tout le processus.
Si un ordinateur ne peut même pas accepter de commandes (il n'y a pas de ligne de commande), comment un utilisateur peut-il interagir avec lui?
Je ne suis pas expert dans ce domaine mais de très vieux ordinateurs comme l'Altair, IMSAI et PDP-8, entre autres, avaient des commutateurs sur le panneau avant qui contrôlaient directement le CPU et pouvaient lire et écrire directement en mémoire sans l'intervention du CPU.
Quelle est cette interface la plus basique?
Je crois que la plupart, voire tous les processeurs modernes, possèdent un "port JTAG" qui permet le même type d'opérations directes. Gardez à l'esprit que pendant longtemps, on s'attendait à ce que la plupart des ordinateurs aient une ROM ou un micrologiciel qui prend le contrôle du système lorsqu'il est allumé avant de le remettre à un OS. Ici, des utilitaires pré-démarrage peuvent exister, ou un mécanisme minimal pour charger de tels utilitaires existe. Certains chargeurs de démarrage comme U-Boot peuvent être accessibles via le port série. Les chargeurs de démarrage ne s'exécutent pas "derrière" l'OS, ils chargent l'OS, lui remettent le contrôle, et ensuite ils ne fonctionnent plus.
Puis-je exécuter cette interface dans un émulateur de terminal ou n'y a-t-il aucun moyen de contourner un shell?
Non, vous avez besoin d'une interface JTAG. Cela relève du domaine de l'électronique et j'avoue que je n'en sais pas beaucoup à ce sujet, sauf que mon GuruPlug en est équipé et je peux directement programmer la puce flash sur la carte du GuruPlug avec - ce qui signifie que si quelque chose tue le chargeur de démarrage sur le GuruPlug, j'ai un moyen de le reprogrammer de manière "indépendante du processeur".
user
Points
28521
Un système d'exploitation n'a pas nécessairement à fournir un shell tel que le terme est communément utilisé aujourd'hui (ce qui signifie une application qui acceptera des commandes de l'utilisateur de manière interactive), mais un tel système d'exploitation ne "ressemblera vraiment" à rien pour l'utilisateur. Comme l'a mentionné Oliver Salzburg, il afficherait probablement juste un écran vide (s'il prend en charge la sortie d'affichage), même s'il n'y a aucune raison pour qu'il le fasse. Prenons par exemple la sortie diagnostique du noyau Linux pendant le processus de démarrage et d'initialisation du noyau.
Le shell, qu'il s'agisse d'un shell graphique, d'un interpréteur en ligne de commande ou autre chose, utilise les fonctionnalités fournies par le système d'exploitation pour effectuer des tâches telles que la lecture des commandes, le lancement de processus, la redirection d'E/S, etc.
Cependant, il n'y a aucune raison pour que l'application qui utilise ces fonctionnalités doive être un shell.
Autrefois, les systèmes d'exploitation se limitaient simplement à une collection de ces "routines utiles" que chaque application aurait autrement dû réécrire entièrement, et les ordinateurs étaient essentiellement des appareils de traitement par lots. Des choses comme les E/S de fichiers, de disques et d'imprimantes ont probablement été parmi les premières à être regroupées dans ce qui est maintenant connu sous le nom de système d'exploitation, suivi de la planification des processus (il convient de noter que l'ordinateur de guidage Apollo du début des années 1960 était un ordinateur multitâche). Les applications pouvaient alors appeler le système d'exploitation au lieu d'utiliser leurs propres routines pour faire de telles choses, ce qui réduisait la complexité de la programmation et probablement aidait à réduire la taille du code ou le temps d'exécution (car ces fonctionnalités système pouvaient être fortement optimisées et déboguées une fois pour que tout le monde en bénéficie). À mesure que les ordinateurs devenaient de plus en plus courants, les systèmes d'exploitation ajoutaient des fonctionnalités largement axées sur les utilisateurs, telles qu'une manière pour l'utilisateur d'interagir avec l'ordinateur et de donner des commandes de manière interactive; les shells graphiques sont simplement une extension de cette ligne de raisonnement.
Aussi, il n'y a pas si longtemps (pensez jusqu'aux années 1980), il était encore assez courant d'écrire des applications pour fonctionner sur le matériel informatique personnel brut, sans l'aide d'un système d'exploitation ordinaire. Cela était particulièrement utile pour les jeux, car il évitait les surcharges de mémoire et de traitement du système d'exploitation propre, mais je suis sûr qu'il y avait d'autres exemples également. Dans ces cas, dans une certaine mesure, l'application était son propre système d'exploitation et par conséquent, l'interface utilisateur fournie par cette application était le shell.
Chaos_99
Points
808
Les premiers ordinateurs n'avaient pas de système d'exploitation au sens où nous utilisons le mot aujourd'hui. Ils exposaient directement au programme en cours des fonctions implémentées dans le matériel. Il n'y avait qu'un seul programme fonctionnant sur eux à la fois. Le programme lui-même devait contrôler toutes les tâches, rien n'était fait 'en arrière-plan' par un système d'exploitation.
Mais il y avait quand même un point d'entrée pour l'utilisateur pour démarrer un programme. Si on étire le mot, on pourrait appeler cela une "coquille". Mais fondamentalement, c'était juste le matériel attendant que l'utilisateur saisisse le premier morceau du programme à exécuter. Que ce soit sous forme de boutons pressés, d'interrupteurs basculés, de fils connectés sur un tableau de commutation, de cartes perforées, de film perforé ou de bande magnétique. Peut-être pouvaient-ils même choisir parmi plusieurs options de programme chargées ultérieurement. Mais même la sélection dans une liste affichée comme des lumières brillantes en appuyant sur un bouton à côté peut déjà être considérée comme une 'coquille'.
Donc, si votre définition de 'coquille' est 'une interface qui accepte des commandes d'un utilisateur', alors il n'y avait pas de temps avant cela, du moins pour des appareils que vous qualifieriez vaguement d'ordinateur.
Vous voudrez peut-être consulter la très bonne page Wikipédia sur l'histoire du matériel informatique, bien qu'elle ne se concentre pas tant sur la perspective entrée/sortie.
diegogs
Points
624
Ce sera probablement un écran blanc.
Le shell est probablement nommé ainsi car c'est une coquille autour du noyau (le noyau étant le système d'exploitation). Donc, en un sens, c'est l'interface utilisateur pour le système d'exploitation, quelle que soit cette interface.
Si un système d'exploitation n'avait qu'une seule fonction, qui serait d'éteindre l'ordinateur, et que vous construiriez un programme qui accepte n'importe quelle entrée clavier, puis invoque cette fonction, alors cela est le shell. Il n'est pas nécessaire d'avoir une interface en ligne de commande complexe pour construire quelque chose qui interagit avec l'utilisateur.
Mark Mzyk
Points
76
D'un point de vue historique, je suppose qu'il y avait des cartes perforées (https://fr.wikipedia.org/wiki/Carte_perfor%C3%A9e). pour interagir avec un système informatique. Mais je suppose que cela remonte trop loin pour votre question.
- Réponses précédentes
- Plus de réponses
