Wie sieht ein Betriebssystem ohne Shell aus?

Eine Shell wie bash oder command.com (bis Windows ME) oder CMD.EXE (in späteren Versionen) bietet eine Schnittstelle, die (unter anderem) Befehle vom Benutzer akzeptiert. Wie sieht ein Betriebssystem aus, bevor eine Shell ausgeführt wird? Wie wurden Systeme verwendet, bevor die erste Shell entwickelt wurde (z. B. UNIX in den frühen 1970er Jahren)? Wenn ein Computer nicht einmal Befehle annehmen kann (es gibt keine Befehlszeile), wie kann ein Benutzer damit interagieren? Was ist das einfachste Interface? Kann ich diese Schnittstelle in einem Terminalemulator ausführen oder gibt es keine Möglichkeit, hinter eine Shell zu gelangen?

Wie sieht ein Betriebssystem aus, bevor eine Shell ausgeführt wird?

Hängt vom Betriebssystem ab und davon, wie Sie es konfigurieren. Linux kann so konfiguriert werden, dass Starttext auf ein Konsolengerät geschrieben wird, unabhängig davon, ob es sich um eine Konsole im Textmodus, eine Framebuffer-Konsole oder eine serielle Schnittstelle handelt. Es kann auch so konfiguriert werden, dass es vollkommen leise ist. Einige Betriebssysteme / Systeme schreiben möglicherweise Diagnoseinformationen in einen nichtflüchtigen Speicher, auf den zugegriffen werden kann, indem das System in den Entwickler-, Debug- oder Diagnosemodus versetzt wird. Viele Betriebssysteme unterstützen die Ausgabe von Boot- und Diagnoseinformationen an UARTs, die auf dem Gerät möglicherweise auch dann verfügbar sind, wenn sie für den Benutzer nicht sichtbar sind (google "Seriellen Anschluss zu DD-WRT hinzufügen", um Beispiele dafür zu finden, wo Hersteller serielle Anschlüsse verbergen und wie Sie können zu ihnen kommen).

Ein Betriebssystem muss überhaupt kein externes Display haben - es ist nur ein weiteres Gerät für das Betriebssystem.

Wie wurden Systeme verwendet, bevor die erste Shell entwickelt wurde (z. B. UNIX in den frühen 1970er Jahren)?

Im Wesentlichen (und viel weglassen, aber das sollte Sie auf die Idee bringen) - Sie haben Ihr Programm geladen, entweder durch Umlegen von Schaltern auf einem Bedienfeld oder mithilfe eines Papier-Band-Lesegeräts (diese Geräte würden direkt ohne Eingreifen der CPU in den Speicher schreiben) und dann starten die CPU mit einem anderen Schalter. Die CPU würde dieses Programm ausführen, seine Ausgabe erzeugen und anhalten. Dies ist eine Stapelverarbeitung im Gegensatz zu einer interaktiven Verarbeitung. Wenn Sie ein anderes Programm ausführen wollten, mussten Sie dies erneut ausführen.

Wenn ein Computer nicht einmal Befehle annehmen kann (es gibt keine Befehlszeile), wie kann ein Benutzer damit interagieren?

Ich bin kein Experte auf diesem Gebiet, aber alte, alte Computer wie der Altair, IMSAI und PDP-8 und solche hatten Schalter auf der Vorderseite, die die CPU direkt steuerten und Speicher ohne Eingreifen der CPU direkt lesen und schreiben konnten.

Was ist das einfachste Interface?

Ich glaube, die meisten, wenn nicht alle modernen CPUs haben einen "JTAG-Port", der die gleiche Art von direkten Operationen ermöglicht. Denken Sie daran, dass von den meisten Computern seit langem erwartet wurde, dass sie über ROM oder Firmware verfügen, die die Kontrolle über das System übernehmen, wenn es eingeschaltet wird, bevor es an ein Betriebssystem übergeben wird. Hier können Pre-Boot-Dienstprogramme vorhanden sein, oder es gibt einen minimalen Mechanismus zum Laden solcher Dienstprogramme. Auf einige Bootloader wie U-Boot kann über die serielle Schnittstelle zugegriffen werden. Bootloader laufen nicht "hinter" dem Betriebssystem, sie laden das Betriebssystem, steuern es von Hand und laufen dann nicht mehr.

Kann ich diese Schnittstelle in einem Terminalemulator ausführen oder gibt es keine Möglichkeit, hinter eine Shell zu gelangen?

Nein, Sie benötigen eine JTAG-Schnittstelle. Das taucht in den Bereich der Elektronik ein und ich gebe zu, dass ich nicht sehr viel darüber weiß, außer dass mein GuruPlug mit einem ausgeliefert wird und ich den Flash-Chip auf dem GuruPlug-Board damit direkt programmieren kann - das heißt, wenn etwas den Bootloader auf dem tötet GuruPlug, ich habe eine "CPU-unabhängige" Möglichkeit, es zurückzuspielen.

Ein Betriebssystem muss keine Shell bereitstellen, wie der Begriff heutzutage gebräuchlich ist (dh eine Anwendung, die interaktiv Befehle vom Benutzer entgegennimmt), aber ein solches Betriebssystem sieht für den Benutzer nicht wirklich "aus" Benutzer. Wie Oliver Salzburg erwähnt, wird wahrscheinlich nur ein leerer Bildschirm angezeigt (wenn es überhaupt Unterstützung für die Ausgabe von Anzeigen gibt), obwohl es keinen Grund dafür gibt. Nehmen Sie zum Beispiel die Diagnoseausgabe des Linux-Kernels während des Boot- und Kernel-Initialisierungsprozesses.

Die Shell, sei es eine grafische Shell, ein Befehlszeileninterpreter oder etwas anderes, verwendet die vom Betriebssystem bereitgestellten Funktionen, um beispielsweise Lesebefehle auszuführen, Prozesse zu starten, E / A-Umleitungen durchzuführen usw.

Allerdings gibt es keinen Grund , warum die Anwendung , die diese Einrichtungen verwendet hat um eine Schale .

Früher waren Betriebssysteme lediglich eine Sammlung jener "nützlichen Routinen", die jede Anwendung sonst von Grund auf neu schreiben müsste, und Computer waren im Wesentlichen Stapelverarbeitungsgeräte. Dinge wie Datei-, Datenträger- und Drucker-E / A gehörten wahrscheinlich zu den ersten, die in einem so genannten Betriebssystem zusammengefasst wurden, gefolgt von der Prozessplanung (es ist erwähnenswert, dass der Apollo Guidance Computer aus den frühen 1960er-Jahren ein Multitasking-Computer war). Anwendungen können dann Aufrufe an das Betriebssystem senden, anstatt ihre eigenen Routinen zu verwenden, was die Programmierkomplexität verringert und wahrscheinlich zur Reduzierung der Codegröße oder der Ausführungszeit beiträgt (da diese Systemfunktionen einmal stark optimiert und debuggt werden könnten, wovon alle profitieren würden). . Mit zunehmender Verbreitung von Computern fügten Betriebssysteme Funktionen hinzu, die weitgehend benutzerzentriert waren, z. Grafik-Shells sind lediglich eine Erweiterung dieser Argumentationslinie.

Vor nicht allzu langer Zeit (bis in die späten 1980er Jahre) war es noch recht verbreitet, Anwendungen zu schreiben, die auf der Hardware eines PCs ohne die Unterstützung eines normalen Betriebssystems ausgeführt werden konnten. Dies war besonders nützlich für Spiele, da der Arbeitsspeicher und der Verarbeitungsaufwand des Betriebssystems vermieden wurden, aber ich bin mir sicher, dass es auch andere Beispiele gab. In diesen Fällen war die Anwendung bis zu einem gewissen Grad ein eigenes Betriebssystem, und folglich war die von dieser Anwendung bereitgestellte Benutzerschnittstelle die Shell.

Frühe Computer hatten kein Betriebssystem in dem Sinne, wie wir es heute verwenden. Sie haben Funktionen, die in der Hardware implementiert sind, direkt einem darauf laufenden Programm zugänglich gemacht. Es wurde immer nur ein Programm gleichzeitig ausgeführt. Das Programm selbst musste alle Aufgaben steuern, nichts wurde 'im Hintergrund' von einem Betriebssystem erledigt.

Dennoch gab es einen Einstiegspunkt für den Benutzer, um ein Programm zu starten. Wenn Sie das Wort strecken, können Sie dies als "Shell" bezeichnen. Im Grunde war es jedoch nur die Hardware, die darauf wartete, dass der Benutzer das erste Bit des auszuführenden Programms eingab. Sei es in Form von gedrückten Tasten, durchgedrückten Schaltern, angeschlossenen Drähten an einer Schalttafel, Lochkarten, Lochfolie oder Magnetband. Vielleicht könnten sie sogar aus mehreren zuvor geladenen Programmoptionen auswählen. Aber auch das Auswählen aus einer Liste, die durch Drücken einer Taste als leuchtendes Licht angezeigt wird, kann bereits als "Shell" betrachtet werden.

Wenn Ihre Definition von "Shell" also "eine Schnittstelle, die Befehle von einem Benutzer akzeptiert" ist, dann war keine Zeit davor, zumindest für Geräte, die Sie vage als Computer bezeichnen würden.

Vielleicht möchten Sie sich die ziemlich gute Wikipedia-Seite über die Geschichte des Computing ansehen , obwohl sie sich nicht sehr auf die Ein- / Ausgabeperspektive konzentriert.

Es wird wahrscheinlich ein leerer Bildschirm sein.

Die Shell wird wahrscheinlich als Shell bezeichnet, da es sich um eine Shell um den Kernel handelt (der Kernel ist das Betriebssystem). In gewissem Sinne ist es also die Benutzeroberfläche für das Betriebssystem, unabhängig von der Schnittstelle.

Wenn ein Betriebssystem nur eine einzige Funktion hatte, die den Computer herunterzufahren wäre, und man würde ein Programm erstellen , die beliebige Eingabetastatur akzeptiert und ruft dann die Funktion, dann , dass die Schale. Es ist keine komplexe Befehlszeilenschnittstelle erforderlich, um eine Schnittstelle zum Benutzer zu erstellen.

Aus historischer Sicht würde ich vermuten, dass es Lochkarten gab ( https://en.wikipedia.org/wiki/Punched_card ). Um mit einem Computersystem zu interagieren. Aber ich denke, das ist zu weit zurück für Ihre Frage.

Das erste Betriebssystem, das ich (1981) nach dem College verwendete, war PRIMOS auf einem Prime-Minicomputer. Hierbei handelte es sich um ein Time-Sharing-Betriebssystem, das eine Reihe von Benutzern unterstützte, die jeweils ein Terminal verwendeten, das über ein RS232-Kabel mit dem Computer verbunden war. Sie mussten sich mit einem Benutzernamen und einem Passwort am Terminal anmelden. Ihre Terminalsitzung war eine Art Hülle. Sie können Dateien bearbeiten, kompilieren und all die Dinge ausführen, die wir heutzutage tun. Alle Terminals hatten Zugriff auf das gleiche Ablagesystem. Diese Terminals waren größtenteils nur Schreibmaschinen - keine WYSISWYG-Redakteure, selbst Emacs waren ein Traum.

Das Betriebssystem war so aufgebaut, wie es jetzt ist, und man konnte es sich als eine Schicht Zwiebelschalen vorstellen. Die innerste Schicht hatte eine sehr niedrige Funktionalitätsebene - wie Hardware-Steuerung, Speicherzugriff. Wenn Sie nach außen gehen, wird das Dateisystem hinzugefügt und anschließend die Benutzerebene. In Ihrem Programm könnten Sie mit einigen Ebenen interagieren, aber nicht mit den innersten (sodass Sie sich nicht mit der Zeitteilung oder der tatsächlichen Hardware herumschlagen könnten - Lichter usw.). Ein Computer ohne Shell wäre wie eine dieser inneren Schichten, er könnte (wirklich!) Auf eine Festplatte und ein Bandlaufwerk zugreifen, aber er würde nichts über Dateien oder Benutzer wissen.

Um einen frühen Computer zu starten, mussten Sie einen grundlegenden Befehlssatz laden (dies kann das Umschalten physischer Switches in einer festgelegten Reihenfolge auf dem Computer umfassen). Diese Sequenz würde ein zweites kleines Programm initiieren, das es dem Bandleser ermöglichen könnte, zu arbeiten. Dann würden Sie ein komplexeres System über den Bandleser laden, wodurch das Laufwerk möglicherweise in Betrieb genommen wird. Sie können sich ein Betriebssystem ohne Shell als einen dieser Initial Loader vorstellen.

Heutzutage haben Computer ähnliche Sequenzen. Wenn Sie den Computer starten, lädt er sein BIOS, das die Festplatten, Netzwerkkarten, Grafikkarten usw. startet. Dann sucht das BIOS nach einem bestimmten Programm auf der Festplatte und führt dieses aus (unter Windows) mindestens). Unix macht etwas Ähnliches. Es richtet den Kernel schrittweise ein, indem es mit sehr einfachen Modulen beginnt und darauf aufbaut, bis es zur Anmeldeaufforderung kommt

Betriebssystem als Definition ist eher mehrdeutig. Ist es ein Kernel selbst? Ist es der Kernel und auch die dazugehörigen Tools? Linux ist der Kernel, aber GNU / Linux ist das Betriebssystem, das auf Linux-Kernel- und GNU-Projektwerkzeugen basiert. Shell ist ein wesentlicher Bestandteil eines solchen Betriebssystems.

Sobald Linux hochgefahren und mit dem "Booten" fertig ist, müssen Sie ihm mitteilen, welches Programm ausgeführt werden soll. Von da an ist alles in der Hand dieses bestimmten Programms. Standardmäßig initweiß es, was als nächstes zu tun ist, und kann Sie schließlich zum Anmeldebildschirm der grafischen Benutzeroberfläche bringen. Das muss aber nicht so sein. Sie können so booten

kernel /boot/vmlinuz-2.6.30 root=/dev/sda1 ro init=/bin/fancy

Dann /bin/fancydruckt das Programm "Hallo Welt!". Wir brauchen keine Muschel dafür. Wenn Sie ein anderes Programm starten möchten, rufen Sie einfach einen neuen Prozess mit man 2 forkund auf man 2 execveoder lesen Sie vom Endgerät und akzeptieren Sie die Eingaben des Benutzers. Muschel noch nicht nötig.

Aus meiner Sicht ist die Betriebssystem-Shell ein Programm, das die Benutzereingaben lesen und dann ein anderes Programm starten kann. Wenn Sie daran denken, ist es ziemlich offensichtlich, warum man ein solches Programm schreiben möchte.

Auch wenn Sie die Benutzereingaben nicht interaktiv lesen müssen, ist es viel bequemer, ein einfaches Shell-Skript für Ihre Aufgabe zu schreiben. In diesem Fall handelt es sich nur um einen Interpreter für gespeicherte Shell-Befehle. Sie können Ihr Programm auch in einem Interpreter einer anderen Sprache schreiben.

Betriebssysteme ohne Kommandozeilen-Shells oder grafische Oberflächen haben viele andere Arten von "Gesichtern".

Eingebettete Systeme erledigen ihre Arbeit einfach ohne Benutzerschnittstelle, wie das Motormanagementsystem in Ihrem Auto (das Sie in gewisser Weise über die OBD2-Schnittstelle und ein geeignetes Terminal erreichen können). Oder haben digitale Tastaturen, Knöpfe oder was auch immer (denken Sie: Mikrowelle, Aufzug oder die Frontplatte eines modernen Soundsystems). Es ist natürlich subjektiv, ob Sie diese als eine Form der Hülle betrachten.

Hier ist ein Rezept, wie Sie als Bastler einen nützlichen Computer ohne Shell erstellen können:

• Bauen Sie eine Leiterplatte für einen Mikrocontroller oder erwerben Sie eine generische Leiterplatte.
• Schließen Sie es an, um einige nützliche Geräte anzutreiben, z. B. einen Feuchtigkeitssensor und ein Wasserventil. Der Mikrocontroller verfügt zu diesem Zweck über Peripherie-Pins: UARTs, GPIOs usw.
• Schreiben Sie die Firmware, um den Sensor zu überwachen und den Boden zu wässern.
• Laden Sie die Firmware über die Entwicklungstools hoch (es ist also keine Shell auf dem Host-Computer erforderlich, um etwas zu laden und auszuführen, und die Firmware wird im Flash-Speicher auf dem Chip gespeichert). Bei der Programmierung wird der Mikrocontroller möglicherweise an eine spezielle Programmierplatine angeschlossen, oder es gibt eine Möglichkeit, dies zu tun, während er auf Ihrer eigentlichen Platine sitzt. Das Board ist mit Ihrem PC verbunden (z. B. heutzutage über USB) und Sie verwenden einige Tools: z. B. eine IDE oder Befehlszeilentools auf dem Host.
• Setzen Sie das Ding ein: Es ist jetzt im Wesentlichen eine elektronische Blackbox, die die Bodenfeuchtigkeit auf irgendeine Weise überwacht und Wasser anmacht, ohne andere Ein- oder Ausgänge.

Sehr frühe Universalcomputer ohne Gehäuse hatten einige Eingabemöglichkeiten, wie das Lesen von Lochkarten. Aber natürlich mussten Lochkarten unterschieden werden: Gibt eine Lochkarte dem Computer einen besonderen Befehl, oder ist sie Teil eines Fortran-Programms? Es mussten also "Job-Control-Sprachen" entwickelt werden, die de facto Befehlszeilen sind.

Bevor Lochkarten und Jobsteuerungssprachen verwendet wurden, mussten Programmierer die Schalter umschalten, um Binärcode in die Maschine einzuspeisen. Möglicherweise haben Sie Geschichten von Oldtimern gehört, die die Anweisungssequenz "einschalten" mussten, um einen Bootstrap einzuleiten. Dies geschieht auch heute noch in gewisser Weise: Es gibt immer noch Geräte mit Jumpern oder DIP-Schaltern, und diese bieten gegenüber den Einstellungen in der Firmware einige Vorteile.

Der erste Computer, auf dem ich feststeckte, war ein Siemens 305. Ich lernte FORTRAN IV. Es hatte eine Schreibmaschine, um Befehle auszuführen und Diagnosemeldungen auf Papier zu drucken, einen Lochkartenleser, einen Lochstreifenleser / -schreiber und einen Drucker. Nicht zu vergessen die herausnehmbare 40 MB Festplatte, 16 Zoll oder so. Es hatte also schon eine Shell und die Schnittstelle war die Schreibmaschine.

Ich erinnere mich, dass ich in den 1970er Jahren einen Debugger und einen Texteditor (DDT und Emacs) als Entsprechung einer Befehlsshell ausgeführt habe. Wenn Sie also Emacs im Konsolenmodus mit einem anderen Programm ausführen, das über eshell zu einem Debugger ausgeführt wird, der das Programm ausführt, haben Sie eine enge Erfahrung.

Beachten Sie, dass emacs über eine vollständige Lisp-Umgebung verfügt. Zusätzlich zur guten Bearbeitung des Befehlsverlaufs und zu mehreren virtuellen Terminals verfügen Sie über eine sehr leistungsfähige integrierte Makro- und Skriptfunktion.