Che aspetto ha un sistema operativo senza shell?

Una shell come bash o command.com (fino a Windows ME) o CMD.EXE (nelle versioni successive) fornisce un'interfaccia che (tra le altre cose) accetta comandi dall'utente. Che aspetto ha un sistema operativo prima dell'esecuzione di una shell? Come venivano utilizzati i sistemi prima dello sviluppo della prima shell (ad esempio UNIX nei primi anni '70)? Se un computer non può nemmeno accettare comandi (non esiste una riga di comando), come può un utente interagire con esso? Qual è questa interfaccia di base? Posso eseguire questa interfaccia in un emulatore di terminale o non c'è modo di andare dietro una shell?

Che aspetto ha un sistema operativo prima dell'esecuzione di una shell?

Dipende dal sistema operativo e da come lo si configura. Linux può essere configurato per scrivere il testo di avvio su un dispositivo console, che sia una console in modalità testo, una console framebuffer o una porta seriale. Può anche essere configurato per essere perfettamente silenzioso. Alcuni sistemi operativi / sistemi operativi possono scrivere informazioni diagnostiche su una memoria non volatile a cui è possibile accedere impostando il sistema in modalità sviluppatore, debug o diagnostica. Molti sistemi operativi supportano l'invio di informazioni di avvio e diagnostiche a una qualche forma di UART, che in qualche modo potrebbe essere disponibile sull'unità anche se nascosta dall'utente (google "Aggiungi porta seriale a DD-WRT" per esempi di dove i produttori nascondono le porte seriali e come puoi raggiungerli).

Un sistema operativo non deve avere affatto uno schermo esterno: è solo un altro dispositivo per il sistema operativo.

Come venivano utilizzati i sistemi prima dello sviluppo della prima shell (ad esempio UNIX nei primi anni '70)?

Essenzialmente (e tralasciando molto, ma questo dovrebbe farti venire l'idea) - Hai caricato il tuo programma, premendo gli interruttori su un pannello o usando un lettore di nastri (questi dispositivi avrebbero scritto in memoria direttamente senza l'intervento della CPU) e poi avrebbero iniziato la CPU con un altro interruttore. La CPU eseguiva questo programma, generava il suo output e si fermava. Si tratta dell'elaborazione batch anziché dell'elaborazione interattiva. Se volevi eseguire un programma diverso, dovevi farlo.

Se un computer non può nemmeno accettare comandi (non esiste una riga di comando), come può un utente interagire con esso?

Non sono esperto in questo settore, ma vecchi e vecchi computer come Altair, IMSAI e PDP-8 e simili avevano interruttori sul pannello frontale che controllavano direttamente la CPU e potevano leggere e scrivere direttamente la memoria senza l'intervento della CPU.

Qual è questa interfaccia di base?

Credo che la maggior parte se non tutte le moderne CPU hanno una "porta JTAG" che consente lo stesso tipo di operazioni dirette. Tieni presente che per molto tempo ci si aspetta che la maggior parte dei computer disponga di ROM o firmware che prendono il controllo del sistema quando viene acceso prima di trasferirlo a un sistema operativo. Qui possono esistere utility pre-boot o esiste un meccanismo minimo per caricare tali utility. Alcuni bootloader come U-Boot sono accessibili tramite la porta seriale. I bootloader non funzionano "dietro" il sistema operativo, caricano il sistema operativo, il controllo manuale su di esso e quindi non sono più in esecuzione.

Posso eseguire questa interfaccia in un emulatore di terminale o non c'è modo di andare dietro una shell?

No, hai bisogno di un'interfaccia JTAG. Si sta tuffando nel regno dell'elettronica e ammetto che non ne so molto, tranne per il fatto che il mio GuruPlug ne ha uno e posso programmare direttamente il chip flash sulla scheda del GuruPlug con esso - il che significa che se qualcosa uccide il bootloader sul GuruPlug, ho un modo "indipendente dalla CPU" di riprogrammarlo.

Un sistema operativo non deve fornire una shell poiché il termine è comunemente usato oggi (che significa un'applicazione che accetterà i comandi in modo interattivo dall'utente), ma un tale sistema operativo non "assomiglierà" a nulla utente. Come menziona Oliver Salzburg, probabilmente mostrerebbe solo uno schermo vuoto (se ha il supporto per l'output del display), anche se non c'è motivo per cui dovrebbe farlo. Prendiamo ad esempio l'output diagnostico del kernel Linux durante il processo di inizializzazione del boot e del kernel.

La shell, che sia una shell grafica, un interprete della riga di comando o qualcos'altro, utilizza le funzionalità fornite dal sistema operativo per eseguire operazioni come leggere comandi, avviare processi, reindirizzare I / O e così via.

Tuttavia, non c'è motivo per cui l'applicazione che utilizza tali servizi debba essere una shell .

Ai vecchi tempi, i sistemi operativi erano semplicemente una raccolta di quelle "routine utili" che ogni applicazione avrebbe dovuto riscrivere da zero, e che i computer erano essenzialmente dispositivi di elaborazione batch. Cose come file, disk e printer I / O furono probabilmente tra le prime ad essere raccolte in quello che ora è noto come sistema operativo, seguito da una programmazione dei processi (vale la pena notare che Apollo Guidance Computer dei primi anni '60 era un computer multitasking). Le applicazioni potrebbero quindi effettuare chiamate al sistema operativo invece di utilizzare le proprie routine per eseguire tali operazioni, riducendo la complessità della programmazione e probabilmente contribuendo a ridurre le dimensioni del codice o i tempi di esecuzione (poiché tali strutture di sistema potrebbero essere pesantemente ottimizzate e sottoposte a debug una volta dopo di che tutti ne trarrebbero vantaggio) . Man mano che i computer diventavano sempre più comuni, i sistemi operativi aggiungevano funzionalità che erano in gran parte centrate sull'utente, come un modo per l'utente di interagire con il computer e fornire comandi in modo interattivo; le conchiglie grafiche sono semplicemente un'estensione di quella linea di ragionamento.

Inoltre, non molto tempo fa (pensate fino alla fine degli anni '80), era ancora abbastanza comune scrivere applicazioni da eseguire sull'hardware nudo del personal computer, senza l'assistenza di alcun sistema operativo ordinario. Ciò è stato particolarmente utile per i giochi, in quanto ha evitato la memoria e l'elaborazione dell'overhead del sistema operativo, ma sono sicuro che ci fossero anche altri esempi. In quei casi, in una certa misura, l'applicazione era il suo sistema operativo e, di conseguenza, l'interfaccia utente fornita da quell'applicazione era la shell.

I primi computer non avevano un sistema operativo nel senso in cui usiamo la parola oggi. Hanno esposto le funzioni implementate nell'hardware direttamente a qualsiasi programma in esecuzione su di esso. C'era un solo programma in esecuzione contemporaneamente. Il programma stesso doveva controllare tutte le attività, nulla è stato fatto "in background" da un sistema operativo.

Ma c'era ancora un punto di ingresso per l'utente di avviare un programma. Se allunghi la parola, potresti chiamarla "shell". Ma fondamentalmente, era solo l'hardware in attesa che l'utente inserisse il primo bit del programma da eseguire. Sia sotto forma di pulsanti premuti, interruttori sfarfallati, fili collegati su un centralino, schede perforate, pellicola perforata o nastro magnetico. Forse potrebbero anche scegliere tra diverse opzioni di programma caricate in precedenza. Ma anche selezionare da un elenco visualizzato come luci incandescenti premendo un pulsante accanto ad esso può già essere considerato una "shell".

Quindi se la tua definizione di "shell" è "un'interfaccia che accetta comandi da un utente", allora non c'era tempo prima, almeno per i dispositivi che chiameresti vagamente un computer.

Potresti voler dare un'occhiata alla bella pagina di Wikipedia sulla storia dell'informatica , anche se non si concentra molto sulla prospettiva di input / output.

Probabilmente sarà uno schermo vuoto.

La scocca è probabilmente il nome della shell , perché è un guscio attorno al kernel (il kernel è il sistema operativo). Quindi, in un certo senso, è l'interfaccia utente per il sistema operativo, qualunque sia l'interfaccia.

Se un sistema operativo avesse una sola funzione, che sarebbe quella di spegnere il computer, e tu costruiresti un programma che accetta qualsiasi input da tastiera e quindi invoca quella funzione, quindi quella è la shell. Non è necessario disporre di una complessa interfaccia a riga di comando per creare qualcosa che si interfaccia con l'utente.

Da un punto di vista storico, immagino che esistessero le schede perforate ( https://en.wikipedia.org/wiki/Punched_card ). Per interagire con un sistema informatico. Ma suppongo che questo sia molto indietro per la tua domanda.

Il primo sistema operativo che ho usato (1981) dopo il college era PRIMOS su un minicomputer Prime. Si trattava di un sistema operativo a tempo condiviso e supportava un numero di utenti, ognuno dei quali utilizzava un terminale collegato al computer tramite un cavo RS232. È stato necessario accedere al terminale fornendo un nome utente e una password. La tua sessione terminale è stata una sorta di guscio. Puoi modificare i file, compilare, eseguire tutte quelle cose che facciamo al giorno d'oggi. Tutti i terminali avevano accesso allo stesso sistema di archiviazione. In gran parte questi terminali non erano altro che macchine da scrivere - nessun editor WYSISWYG, anche emacs era un sogno.

Il sistema operativo era strutturato così come sono adesso e poteva essere immaginato come uno strato di bucce di cipolla. Il livello più interno aveva funzionalità di livello molto basso - come il controllo hardware, l'accesso alla memoria. Andando verso l'esterno, il file system verrebbe aggiunto e quindi i livelli utente. Nel tuo programma sarai in grado di interagire con alcuni livelli, ma non con quelli più interni (quindi non sarai in grado di pasticciare con la condivisione del tempo o l'hardware reale - luci e così via). Un computer senza shell sarebbe come uno di questi strati interni, potrebbe essere in grado di accedere a un disco rigido e un lettore di nastri (davvero!), Ma non sarebbe a conoscenza di file o utenti.

Per avviare un computer in anticipo è necessario caricare un set di istruzioni di base (ciò potrebbe comportare l'attivazione / disattivazione di interruttori fisici in una sequenza impostata sul computer). Questa sequenza avvierebbe un secondo piccolo programma, che potrebbe consentire al lettore di nastri di funzionare. Quindi caricheresti un sistema più complesso attraverso il lettore di nastri, il che potrebbe portare l'unità disco online. Potresti immaginare un sistema operativo senza shell come uno di questi caricatori iniziali.

Oggi i computer hanno sequenze simili, quindi quando si avvia la macchina, carica il suo BIOS, che avvia i dischi, le schede di rete, la scheda video e così via, quindi il BIOS cerca un programma specifico sul disco rigido e lo esegue (su Windows almeno). Unix fa qualcosa di simile imposta progressivamente il kernel iniziando con moduli molto basilari e costruendo su di essi fino a quando non arriva al prompt di login

Il sistema operativo come definizione è piuttosto ambiguo. È un kernel stesso? È il kernel e anche gli strumenti di accompagnamento? Linux è il kernel ma GNU / Linux è il sistema operativo basato sul kernel Linux e sugli strumenti di progetto GNU. Shell è parte integrante di tale sistema operativo.

Tuttavia, una volta che Linux è attivo e ha terminato l '"avvio", devi dirgli quale programma eseguire. Da allora in poi tutto è nelle mani di quel particolare programma. Di default è initchi sa cosa fare dopo e potrebbe eventualmente portarti alla bella schermata di accesso alla GUI. Ma non deve essere così. È possibile avviare in questo modo

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

Quindi il programma /bin/fancystamperà "Hello world!". Non abbiamo bisogno di shell per questo. Se desideri avviare qualche altro programma, genera semplicemente un nuovo processo da man 2 forke man 2 execve, o leggi dal dispositivo terminale e accetta l'input dell'utente. Ancora nessuna necessità di shell.

A mio avviso la shell del sistema operativo è un programma in grado di leggere l'input dell'utente e quindi avviare un altro programma. Se ci pensate, è abbastanza ovvio il motivo per cui si vorrebbe scrivere un programma del genere.

Anche se non hai bisogno di leggere l'input dell'utente in modo interattivo, è molto più conveniente scrivere un semplice script di shell per la tua attività. In quel caso è solo un interprete dei comandi della shell memorizzati. Puoi anche scrivere il tuo programma come interprete di un'altra lingua.

I sistemi operativi senza shell della riga di comando o interfacce grafiche hanno molti altri tipi di "facce".

I sistemi integrati svolgono semplicemente il loro lavoro senza alcuna interfaccia utente, come il sistema di gestione del motore nella tua auto (a cui puoi accedere in qualche modo tramite l'interfaccia OBD2 e un terminale adatto). O può avere tastiere digitali, manopole o altro (pensate: forno a microonde, ascensore o il frontalino di un moderno sistema audio). Ovviamente, indipendentemente dal fatto che li consideri una forma di guscio, è soggettivo.

Ecco una ricetta di alto livello su come, come hobbista, puoi creare un computer utile senza una shell su di esso:

• Costruisci una scheda per un microcontrollore o ottieni una scheda generica.
• Collegalo per guidare alcuni dispositivi utili, come, per esempio, un sensore di umidità e una valvola dell'acqua. Il microcontrollore ha pin periferici per questo scopo: UART, GPIO e così via.
• Scrivi il firmware per monitorare il sensore e innaffia il terreno.
• Carica il firmware tramite gli strumenti di sviluppo (quindi, non è richiesta alcuna shell sul computer host per caricare ed eseguire qualsiasi cosa e il firmware è archiviato nella memoria flash sul chip). La programmazione può comportare l'inserimento del microcontrollore in una speciale scheda di programmazione oppure potrebbe esserci un modo per farlo mentre è seduto nella scheda reale. La scheda si interfaccia al tuo PC (oggigiorno tramite USB, ad esempio) e utilizzi alcuni strumenti: come un IDE o strumenti a riga di comando sull'host.
• Distribuisci la cosa: ora è essenzialmente una scatola nera elettronica che in qualche modo monitora l'umidità del suolo e accende l'acqua, senza altri input o output.

I computer per uso generale molto precoci senza shell avevano alcuni mezzi di input, come la lettura di schede perforate. Ma ovviamente, le carte perforate dovevano essere distinte: una carta perforata dà al computer un comando speciale o è un pezzo di un programma Fortran? Quindi è stato necessario sviluppare "linguaggi di controllo del lavoro", che sono di fatto linee di comando.

Prima delle schede perforate e dei linguaggi di controllo del lavoro, i programmatori dovevano attivare / disattivare gli interruttori per inserire il codice binario nella macchina. Potresti aver sentito storie di vecchi che dovevano "attivare" la sequenza di istruzioni per avviare un bootstrap. Questo è ancora fatto oggi, in un certo senso: esistono ancora dispositivi che hanno ponticelli o DIP switch e ci sono alcuni vantaggi rispetto a quelli delle impostazioni del firmware.

Il primo computer su cui sono rimasto bloccato è stato un Siemens 305 nel 1977, stavo imparando FORTRAN IV. Aveva una macchina da scrivere per eseguire comandi e stampare messaggi diagnostici su carta, un lettore di schede perforate, un lettore / scrittore di schede e una stampante. Da non dimenticare il disco fisso rimovibile da 40 MB, circa 16 pollici. Quindi aveva già una shell e l'interfaccia era la macchina da scrivere.

Ricordo di aver eseguito un debugger e un editor di testo (DDT ed emacs) come l'equivalente di una shell di comando negli anni '70. Quindi se esegui emacs in modalità console con qualsiasi altro programma eseguito tramite eshell su un debugger che esegue il programma, avrai un'esperienza ravvicinata.

Nota che emacs ha un ambiente lisp completo, quindi oltre alla buona modifica della cronologia dei comandi e a più terminali virtuali, hai una funzione macro e di scripting molto potente integrata.