I sistemi informatici (senza sistema operativo installato) utilizzano file (eseguibili)? [duplicare]

Dato che non stai parlando di avvio, la tua risposta è in realtà che il concetto di "eseguibile" o anche "file" è piuttosto irrilevante.

Il concetto di file è un concetto di OS. Senza un sistema operativo, tutto ciò che hai è un hard disk, con alcuni bit su di esso. È il sistema operativo che dà struttura a quelle informazioni che rende significativo pensare ai dati come un file.

Per un computer "spoglio", senza considerare l'avvio, l'idea di "memorizzare programmi utente" è priva di significato oltre alla definizione noiosissima di "memorizza i file inserendo gli 1 e gli 0 su un disco rigido". A questo livello, questi 1 e 0 sono indistinguibili da quelli di testo, o immagini, o qualsiasi altra cosa perché non esiste una struttura "definita".

Le persone si stanno concentrando sull'avvio perché è qui che il tuo concetto di "file eseguibile" diventa significativo per la prima volta. Quando un BIOS si avvia (dalla ROM), una delle sue ultime attività è l'identificazione di un supporto da cui avviare (cioè un disco rigido) e "eseguire" qualcosa da esso. Solitamente viene implementato come "la bios comanda all'hard disk di produrre gli 1 e gli 0 da una specifica posizione numerata sull'hard disk. Questi 1 e 0 verranno quindi archiviati in memoria e il puntatore delle istruzioni della prima CPU verrà puntato su quelli 1 e 0 ".

Questo è il punto in cui ci avviciniamo di più alla risposta alla tua domanda. Questo blocco di 1 e 0 è formattato in un modo definito dalla CPU come un insieme di istruzioni. Non posso definirlo un file, ma è sicuramente un blocco continuo di valori definiti dalla CPU caricati da un hard disk.

Ora questa particolare serie di istruzioni diventa proprietaria del computer. Comanda tutto da qui in avanti. Se desidero, ora posso andare a chiedere all'hard disk un altro blocco di 1 e 0, archiviarli in memoria e "eseguirli". Ciò suggerisce che questo blocco di 1 e 0 noto come "codice macchina" sarebbe una risposta alla tua domanda "come sono memorizzati i programmi utente". Tuttavia, è una risposta incompleta. Potrei anche scrivere il mio blocco per andare a leggere dall'hard disk, quindi invertire ogni bit letto, prima di saltare a quei dati come una serie di istruzioni. In questo caso, ora gli 1 e gli 0 non sono "codice macchina", ma piuttosto una sorta di codice macchina codificato. Ciò indica che non esiste un modo "definito" per archiviare i programmi utente su un computer nudo tranne per il primo programma, che è speciale.

Ora alla fine eseguiremo alcuni programmi che introducono il concetto di un file system sull'hard disk. Ora, per la prima volta, abbiamo un concetto di file, quindi possiamo parlare di "file eseguibili". Tuttavia, poiché siamo così avanti nel processo, non c'è un modo in cui vengono memorizzati. Come mostrato in precedenza, potremmo arbitrariamente scegliere di invertire ogni bit.

Quindi il motivo per cui la tua domanda riguarda termini che non vanno veramente insieme è che il concetto di "file eseguibile" è in contrasto con l'idea di un "computer nudo". Le due parole semplicemente non vanno insieme. Tuttavia, nei primi momenti di avvio, c'è una sezione a dell'hard disk, che non è un file ma si avvicina molto al fatto di essere chiamato un file, che è in un formato eseguibile definito dalla CPU.

Per avere un sistema operativo attivo e funzionante, ci sono varie cose che vengono eseguite, in genere chiamate "loader" e "bootstrapper".

Il loro scopo collettivo è esattamente come implicano i loro nomi: far funzionare il sistema operativo, un passo alla volta.

Alcuni di questi codici eseguibili sono memorizzati nella memoria di sola lettura (ROM), o in alcuni tipi di memoria riprogrammabile (come la Flash ROM), o in una determinata posizione predeterminata sul disco di archiviazione (situato su un cosiddetto "boot" settore ", che è una posizione predeterminata su una" partizione del disco ") da cui è possibile avviare la macchina.

Il tuo sospetto che almeno alcuni di questi codici eseguibili debbano esistere al di fuori del concetto che chiamiamo "file" o "file system" è corretto. Non tutti sono; ma almeno alcuni di essi devono essere.

Il firmware hardware del computer e il sistema operativo stesso sono in genere in grado di accedere a queste aree di archiviazione "non file" per eseguire aggiornamenti di manutenzione non frequenti su questo codice eseguibile.

Lo scopo di consentire questi aggiornamenti dal software è una scelta ingegneristica guidata dal mercato dei consumatori - è più economico mantenere i computer se è possibile per i clienti eseguire gli aggiornamenti, piuttosto che richiedere che le macchine vengano rispedite a una fabbrica o centro di manutenzione per fare lo stesso.

Il codice eseguibile è diverso dal codice trovato in "file eseguibili"? Forse sì forse no. Ci sono certamente alcune differenze.

Una macchina a 64 bit può spendere il 99,99% del suo tempo eseguendo un codice macchina a 64 bit una volta avviato; ma durante i primi secondi potrebbe dover eseguire un codice macchina a 32 bit.

Allo stesso modo, un SO completamente caricato verrà eseguito in modalità privilegiata e il resto del codice verrà eseguito in modalità utente. Ma durante il bootstrap la maggior parte del codice può essere eseguita in modalità privilegiata - o meglio, in alcune modalità "semplicemente non protetta", perché il meccanismo della CPU per la gestione degli errori del software potrebbe non essere stato completamente inizializzato.

Codice che deve essere eseguito senza il sistema operativo, ovviamente non è possibile effettuare chiamate al sistema operativo. Possono ancora effettuare salti e chiamate di subroutine ad altro codice, purché si trovino nello stesso pezzo di codice caricato nella RAM in un colpo solo.

Questo fa apparire la "limitazione delle dimensioni" del codice bootstrapper. Lo stadio precedente deve sapere esattamente quanto è grande la dimensione del codice della fase successiva. Quella quantità di codice / dati eseguibili verrebbe introdotta nella RAM prima che possa essere eseguita qualsiasi di esse. In assenza di un SO (e anche di qualsiasi meccanismo di gestione della memoria), il bootstrapper non può effettuare chiamate di subroutine situate al di fuori di ciò che è stato portato nella RAM, a meno che il bootstrapper non sappia come caricare il codice aggiuntivo.

Il BIOS potrebbe dover fornire un modo per facilitare (semplificare) il caricamento di dati aggiuntivi dal disco di archiviazione. Prestazioni o sicurezza non sono la preoccupazione: l'unica preoccupazione è la semplicità per il chiamante (che è il bootstrapper). Altrimenti, sarebbe un compito molto noioso, e mangerebbe lo spazio prezioso che il codice del bootstrapper deve contenere.

Quali formati sono usati per tale codice di bootstrap?

Questi codici devono seguire alcune convenzioni per funzionare correttamente. Se queste convenzioni si qualificano come "un formato" è un gioco di parole.

Ad esempio, deve essere specificato lo scostamento iniziale della prima istruzione macchina nel codice bootstrap. Altrimenti, in che altro modo inizi ad eseguirlo?

Alcuni codici di bootstrap sono necessari per portare un checksum, o anche una firma digitale (cioè firmati digitalmente), per evitare di provare a eseguire un bootstrapper i cui dati sono corrotti, o falsificati o manomessi da intenti malevoli.

Queste convenzioni devono essere concordate dai produttori di macchine, dai fornitori di sistemi operativi e / o dai manutentori e così via.

Nell'era della pietra del computer, una delle modalità comuni di avvio era leggere un programma eseguibile in memoria completamente sotto controllo hardware e quindi inizia a eseguirlo.

Ad esempio, il PDP-10 potrebbe comandare la lettura del lettore di nastri di carta un blocco di dati, prendere i dati presentati e riempirli in memoria, e quindi iniziare a eseguirlo quando il blocco è stato completato. Questo era abituato a leggere un programma di istruzioni di 16 che è stato sufficiente per leggere più dati da il nastro e posizionarlo in posizioni controllate della memoria, e alla fine per avviare il programma più grande che potrebbe eseguire la console tty, leggere il disco rigido e carica il sistema operativo.

I file sono un'astrazione di basso livello fornita dai sistema operativo attraverso alcuni file system layer. Un'altra importante astrazione fornita dai sistemi operativi è processi (esecuzione di istanze di programmi). Il sito OSdev contiene interessanti informazioni pratiche. Il computer bar metal sottostante (ad esempio il tuo laptop o desktop x86) non conosce i file .... Sta leggendo e scrivendo settori (spesso blocchi di 512 byte o di 4096 byte) su dischi (e il sistema operativo genera l'astrazione del file sopra quella) . Il tuo solito sistema operativo (Linux o Windows) utilizza le astrazioni di file per archiviare i programmi. Ma il computer bar metal sta solo eseguendo le istruzioni codice macchina (e alcune di esse vengono lette dal disco dal sistema operativo). Al livello più basso , vicino all'hardware, i programmi non esistono realmente (solo codice macchina)! Eseguibili (quindi programmi) e processi sono anche un'astrazione (& convention) fornita e gestita dal sistema operativo. Su Linux, la maggior parte dei binari eseguibili si trova in ELF .

Ma potevi immaginare un sistema operativo senza file . Dovrai scrivere un tale sistema da zero, eseguendo il bare metal (e ovviamente dovrai definire una nozione di programma, preoccuparti di come quella cosa si avvia, eseguire programmi e usa il disco). Potrebbe avere un modello di persistenza ortogonale (come Phantom , EROS , ecc ...)

Negli anni '80 & Negli anni '90 alcune macchine Lisp non avevano file. Hanno mantenuto l'intero stato sul disco.

In pratica i computer stanno diventando sempre più complessi. Puoi consultare UEFI e Grub boot loader con una forma limitata di file. e alcuni firmware (come Open Firmware ) forniscono anche una forma limitata di file.

Un altro modo divertente di guardare a questo è immaginare che gli alieni possano avere computer che non usano file (ma qualcos'altro). I file sono un'invenzione (in qualche modo legata alla tecnologia e ai problemi sociali del settore IT negli anni '60)

E ovviamente alcuni piccoli microcontrollori non hanno file system. La mia lavatrice ha probabilmente un microcontrollore a 8 bit, ma nessun file system.

Immagino che i file diventino meno rilevanti di prima (i database sono sempre più importanti). Si noti che un semplice filesystem simile a Unix potrebbe non essere il modo migliore per organizzare i dati su un disco multi terabyte. Probabilmente vuoi archiviare più metadati su di esso rispetto a offerte di filesystem nativi (e potresti usare qualche database per questo).

Before an OS is installed on a bare computer system, does the computer use files?

No. All'avvio del codice viene copiato da una EPROM in memoria in una posizione nota e il processore esegue tali istruzioni. Tutto ciò che fa è caricare l'istruzione di esecuzione all'indirizzo di memoria "attuale", incrementarlo e ripetere per sempre. La CPU non è a conoscenza del fatto che un controller del disco rigido o qualsiasi altra cosa sia addirittura connessa, per non fare qualcosa di utile con esso, richiede istruzioni su come farlo e quelle istruzioni sono di solito il livello più basso di un sistema operativo.

does the computer system have the concept of executable files or something similar for storing programs?

Con niente per mettere i file non c'è nessun file system e nessun formato di file. Inizialmente tutto viene caricato da una EPROM in RAM (memoria principale) e quindi eseguito istruzioni per istruzione. Per quanto riguarda la CPU, sono solo una serie di byte.

Il BIOS è un esempio di codice contenuto nella EPROM - è il codice per un (molto semplice) sistema operativo che fa ciò di cui ha bisogno (come sveglia i controller del disco e altre periferiche) e cerca un altro pezzo di codice da eseguire. Lo stesso meccanismo che avvia il sistema e ne consente il funzionamento sufficiente per caricare / installare il sistema operativo scelto è quello che avvia tutto in moto all'avvio del sistema.

Se ritenevi che la tua scheda madre fosse inclinata e avesse le giuste informazioni sull'hardware esatto, puoi scrivere la tua EPROM ed eseguire il codice da quella. Ovviamente a un certo punto avresti bisogno di riutilizzare le funzioni e man mano che aumenta il bisogno ti ritroverai a scrivere il tuo sistema operativo e tutti i mal di testa che ne derivano ...