in che modo DOS ha eseguito più processi contemporaneamente?

Question

DOS viene sempre fornito come esempio di sistema operativo singolo tasking. Tuttavia, quando un comando viene emesso tramite la riga di comando, il controllo passa dalla shell al comando e poi torna alla shell quando il comando viene completato. Quindi ci sono due processi in esecuzione simultaneamente. C'è qualcosa di sbagliato nella mia comprensione?

Answer 1

No, non erano in esecuzione contemporaneamente.

COMMAND.COM aveva una porzione residente che era in memoria per tutto il tempo e una porzione transitoria che poteva essere sballottata a volontà.

Quando si esegue un programma, in genere viene caricato al posto della parte transitoria e quindi eseguito. Quando il programma è terminato, lo ha fatto chiamando il codice nella parte residente che ricarica quindi la parte transitoria se necessario e continua.

Il fatto che parte del codice rimanga residente in alcun modo significa che era "in esecuzione". In modo simile, vaste tratte di MS-DOS (il kernel) rimasero continuamente in memoria ma non erano "in esecuzione", a meno che non fossero chiamate esplicitamente da un programma non-kernel.

Ora ci erano cose si potrebbe dire di eseguire contemporaneamente, DOS aveva un sacco di TSR (Terminate and Stay residente) programmi che avrebbe eseguito, gancio in un interrupt o DOS, in qualche modo, quindi uscire ma lasciando un po 'di memoria assegnato (dove era il suo codice).

Quindi, in risposta a determinati eventi, il codice verrà eseguito. Forse uno dei più famosi era Borland Sidekick che era un gestore di informazioni personali che si apriva all'istante con un keypress.

Answer 2

Mentre l'altro processo è in esecuzione, il processore della riga di comando non è in esecuzione: è sospeso. L'unica funzione "multitasking" disponibile in DOS era "Terminate and Stay Resident".

Answer 3

Non importa se si esegue DOS o Windows o Linux o BSD o qualsiasi altra cosa su quel processore è lo stesso. In quel lasso di tempo tu per gli scopi di questa discussione hai una singola unità di esecuzione, un singolo core che esegue le istruzioni, per lo più in ordine. Non fa differenza se quelle istruzioni indossano il nome DOS o Linux o Windows. Solo istruzioni

Proprio come ora, quando un programma Windows decide di terminarlo, tenta di farlo bene con un po 'di sapore della chiamata di uscita. Quando termina un programma Linux, cerca di farlo bene con un po 'di sapore della chiamata di uscita al sistema. E quando un programma DOS termina, prova a farlo con un certo sapore di chiamata di uscita al sistema. In una shell, prompt dei comandi, ecc linux, windows, dos, quella shell, che è un programma stesso, carica e si dirama al programma che hai caricato e il tuo programma viene eseguito per un po 'e come detto prova a tornare al programma precedente in modo piacevole con un po 'di sapore di uscita. Proprio come quando la shell che stavi girando vuole tornare quando ha finito, prova a farlo in modo piacevole.

Come con linux o windows, è più facile rivederlo, non eseguire "allo stesso tempo" o "in parallelo" un flusso di istruzioni alla volta. (oggi abbiamo più unità di esecuzione e/o core che sono progettati per fare qualcosa in parallelo con qualcosa che li gestisce, quindi oggi puoi dire "in parallelo") Vuoi cambiare "tasks" o "threads" o " processi "era necessario un interrupt, che passava a un codice diverso, un gestore di interrupt, e quel gestore poteva tornare allo stesso programma che era stato interrotto o passare a un altro. Puoi mettere qualsiasi nome su di esso vuoi che sia come si fanno le cose sembrano come se fossero in esecuzione allo stesso tempo. dos, linux, windows, ecc, questo è in genere il modo in cui si passa da un "programma" o un bit di codice a un altro.linux e windows hanno i loro kernel e il loro sistema operativo che è stato chiamato durante gli interrupt, e dos ha anche quello (dos HAS che, dos è ancora vivo si tocca una macchina dos ogni pochi giorni molto probabilmente (pompa di benzina, bancomat, ecc), dos è ancora utilizzato nello sviluppo e nel test di schede madri/computer x86, nulla può competere con esso come una piattaforma x86 incorporata, nulla ha la libertà che dos deve fare quello che vuoi, questo è il motivo per cui gli aggiornamenti del BIOS sono ancora distribuito come un programma dos). Gli handler di interrupt darebbero intervalli di tempo ai vari handler e gestori di bios. task/process/thread switching non era progettato o pianificato come un sistema operativo come linux o windows, ma era lì, per ogni versione di dos c'erano le regole che hai seguito e puoi cambiare attività (tsrs è un termine popolare). Basta parlare con un floppy, un hard disk, ecc. C'era il codice coinvolto nell'intero processo, non era sepolto nell'hardware, molte cose accadevano in parallelo. non diverso da un driver del controller del disco rigido in qualcosa di più complicato come linux o windows. Almeno uno, forse alcuni, i cloni dos non-microsoft potrebbero eseguire il multitasking.

La risposta breve, quando si ha una funzione bob() che chiama una funzione ted().

int bob (int something) 
{ 
...some code 
...more code 
    ted(); 
...some code 
...more code 
} 

bob() ancora in esecuzione? Stanno correndo in parallelo? No, il codice bob() è ancora lì, da qualche parte, in attesa del codice ted() per terminare ciò che stava facendo e ritornare. Finché ted() non si arresta, verrà restituito e bob() può continuare a essere eseguito. bob è sospeso mentre Ted esegue. Non molto diverso con una shell o una riga di comando in un sistema operativo più complicato. C'è qualche funzione da qualche parte che ha caricato il programma in memoria e lo ha chiamato, potrebbe essere un fork o clone di una riga di comando che stavi eseguendo in modo che quella riga di comando possa continuare "in parallelo" o il clone possa continuare in parallelo. ma il concetto è lo stesso.

La differenza da un programma C banale come quello sopra è che il codice sopra può essere pensato per essere risolto in fase di compilazione dove caricare ed eseguire un programma è sicuramente runtime, in pratica codice auto modificante, il programma modifica la memoria poi salta ad esso. Quando restituisce quel codice, pulisce, si srotola e si chiude da solo o attende un altro comando a seconda del progetto. DOS era semplicemente molto semplice, un sacco di chiamate di sistema, unite a un sacco di chiamate BIOS e una linea di comando molto semplice che poteva caricare programmi e fare un piccolo numero di altri comandi. Non aveva alcuna regola che non si potesse aggirare (Windows è un programma dos), se il programma che avevi lanciato non voleva tornare (potresti almeno lanciare Linux da DOS attraverso un programma DOS intermedio) beh, questo tipo di problemi la tua domanda su cosa succede quando il programma si completa, beh, non è tornato linux, ha preso il controllo del sistema.