Se DOS è single-tasking, come è stato possibile il multitasking nella vecchia versione di Windows?

Ho letto che DOS è un sistema operativo a singolo tasking.

Ma se le vecchie versioni di Windows (incluso anche Windows 95?) Erano solo wrapper di DOS, come poteva Windows funzionare come sistema operativo multitasking?

Windows 95

Windows 95 era molto più di "solo un wrapper" per MS-DOS . Citando Raymond Chen:

MS-DOS ha servito due scopi in Windows 95.

• È servito come boot loader.
• Ha funzionato come il livello del driver di dispositivo legacy a 16 bit.

Windows 95 ha effettivamente agganciato / sovrascritto quasi tutto l'MS-DOS, mantenendolo come un livello di compatibilità mentre fa tutto il lavoro pesante stesso. Ha inoltre implementato il multitasking preventivo per i programmi a 32 bit.

Pre-Windows 95

Windows 3.xe precedenti erano per lo più a 16 bit (ad eccezione di Win32s, un livello di compatibilità un pò che collega 16 e 32, ma lo ignoreremo qui), dipendevano maggiormente da DOS e utilizzavano solo il multitasking cooperativo - questo è quello in cui non forzano lo spegnimento di un programma in esecuzione; aspettano che il programma in esecuzione dia il controllo (in pratica, dì "Ho finito" dicendo al sistema operativo di eseguire il programma successivo che è in attesa).

Il multitasking era cooperativo, proprio come nelle vecchie versioni di MacOS (anche se a differenza del Multitasking DOS 4.x, che sfoggiava il multitasking preventivo). Un'attività doveva arrendersi al sistema operativo al fine di pianificare un'attività diversa. I rendimenti sono stati integrati in alcune chiamate API, in particolare l'elaborazione dei messaggi. Finché un'attività ha elaborato i messaggi in modo tempestivo, tutto è stato ottimo. Se un'attività ha interrotto l'elaborazione dei messaggi ed era impegnata nell'esecuzione di alcuni cicli di elaborazione, il multitasking non esisteva più.

Architettura di Windows 3.x.

Quanto a quanto presto i programmi di Windows avrebbero prodotto il controllo:

Windows 3.1 utilizza il multitasking cooperativo, il che significa che ogni applicazione in corso di esecuzione è incaricata di controllare periodicamente una coda di messaggi per scoprire se qualsiasi altra applicazione richiede l'uso della CPU e, in tal caso, per cedere il controllo a tale applicazione . Tuttavia, molte applicazioni di Windows 3.1 controllano la coda dei messaggi solo di rado, o per niente, e monopolizzano il controllo della CPU per tutto il tempo necessario. Un sistema multitasking preventivo come Windows 95 toglierà il controllo della CPU da un'applicazione in esecuzione e la distribuirà a quelli che hanno una priorità più elevata in base alle esigenze del sistema.

fonte

Tutto ciò che DOS vedrebbe è questa singola applicazione (Windows o altro) in esecuzione, che passerebbe il controllo senza uscire. In teoria, il multitasking preventivo può eventualmente essere implementato su DOS in ogni caso con l'uso di un orologio in tempo reale e interruzioni hardware per dare il controllo forzato allo scheduler. Come commenta Tonny , questo è stato effettivamente fatto da alcuni sistemi operativi in ​​esecuzione su DOS.

386 modalità avanzata?

Nota: ci sono stati alcuni commenti su 386 modalità avanzata di Windows 3.x a 32 bit e che supporta il multitasking preventivo.

Questo è un caso interessante. Per riassumere il post sul blog collegato , la modalità avanzata 386 era fondamentalmente un hypervisor a 32 bit, che eseguiva macchine virtuali. All'interno di una di quelle macchine virtuali era in esecuzione la modalità standard di Windows 3.x, che fa tutte le cose sopra elencate.

MS-DOS funzionerebbe anche all'interno di quelle macchine virtuali, e apparentemente erano preventivamente multitasking - quindi sembra che l'hypervisor in modalità avanzata 386 condividerà fasce orarie della CPU tra le macchine virtuali (una delle quali ha funzionato 3.x normale e altre che eseguono MS -DOS), e ogni VM farà la propria cosa - 3.x coopererà multitasking, mentre MS-DOS verrebbe assegnato a un singolo compito.

MS-DOS

Lo stesso DOS era single-tasking su carta, ma aveva il supporto per i programmi TSR , che sarebbero rimasti in background fino a quando non fossero stati innescati da un interrupt di processo. Lungi dall'essere un vero multitasking, ma neanche completamente a singolo compito.

Tutto questo parlare di bit-ness? Ho chiesto informazioni sul multitasking!

Bene, a rigore il bit-ness e il multitasking non dipendono l'uno dall'altro. Dovrebbe essere possibile implementare qualsiasi modalità multitasking in qualsiasi bit-ness. Tuttavia, il passaggio dai processori a 16 bit ai processori a 32 bit ha anche introdotto altre funzionalità hardware che avrebbero potuto rendere più semplice l'implementazione del multitasking preventivo.

Inoltre, poiché i programmi a 32 bit erano nuovi, era più facile farli funzionare quando sono stati forzatamente disattivati, il che potrebbe aver rotto alcuni programmi legacy a 16 bit.

Certo, questa è tutta speculazione. Se vuoi davvero sapere perché MS non ha implementato il multitasking preventivo in Windows 3.x (nonostante la 386 modalità avanzata), dovrai chiedere a qualcuno che ha lavorato lì.

Inoltre, volevo correggere il tuo presupposto che Windows 95 fosse jsut un wrapper per DOS;)

Eseguiva continuamente un singolo programma, quello chiamato Windows. Quello ha distribuito il tempo della CPU (e altre risorse) tra diversi programmi.

Considera questa analogia:

Hai un ufficio che può avere solo una persona alla volta (quella persona si chiama mister o missus DOS). Quella persona lavora su una cosa alla volta. Ad esempio, telefona a una sola persona e inizia a chattare 24/7 con lui / lei.

Ora sostituisci quella persona con il signor segretario. (finestre). Telefonerà a qualcuno e ne parlerà continuamente (ancora una singola attività). Poi dopo un po 'l'altra persona dirà "Per ora ho parlato abbastanza. Vai a parlare con qualcun altro e richiamami tra un po'".

Il signor segretario chiamerà l'altra persona. Chatta con quello fino a quando quella persona non dice la stessa cosa. Quindi chiamerà la persona successiva fino a quando non sarà alla fine dell'elenco delle persone con cui parlare. In quel momento ricomincerà in alto.

• In termini tecnici questo si chiama multitasking cooperativo. Richiede all'altra persona di dire che ha avuto abbastanza tempo della CPU. Se uno non lo fa, allora tutto cade a pezzi.
• I sistemi moderni sono molto più intelligenti. Compreso il multitasking preventivo. Pensa alla segretaria che imposta una sveglia e interrompe l'altra persona dopo 5 minuti. "Bella Jane. Ma adesso devo parlare con Joe. Ti richiamo tra poco. - Fai clic."

Se aggiungi più processori diventa ancora più complicato. :)

In un moderno sistema operativo, il sistema operativo controlla tutte le risorse hardware e le applicazioni in esecuzione vengono conservate in sandbox. Un'applicazione non è autorizzata ad accedere alla memoria che il sistema operativo non ha allocato a tale applicazione e non può accedere direttamente ai dispositivi hardware nel computer. Se è richiesto l'accesso all'hardware, l'applicazione deve comunicare tramite i driver di dispositivo.

Il sistema operativo può applicare questo controllo, poiché forza la CPU ad entrare in modalità protetta .

DOS, d'altra parte, non entra mai in modalità protetta, ma rimane in modalità reale *. Nella modalità reale, le applicazioni in esecuzione possono eseguire tutto ciò che vogliono, ad esempio accedere direttamente all'hardware. Ma un'applicazione in esecuzione in modalità reale può anche dire alla CPU di entrare in modalità protetta.

E quest'ultima parte consente ad applicazioni come Windows 95 di avviare un ambiente multi-thread anche se sono state sostanzialmente lanciate da DOS.

DOS (Disk Operating System) non era molto più di un sistema di gestione dei file. Ha fornito un file system, meccanismi per la navigazione nel file system, alcuni strumenti e la possibilità di avviare applicazioni. Ha inoltre consentito la permanenza di alcune applicazioni, ad esempio driver del mouse ed emulatori EMM. Ma non ha tentato di controllare l'hardware del computer come fa un sistema operativo moderno.

* Quando il DOS fu creato per la prima volta negli anni '70, la modalità protetta non esisteva nella CPU. Fu solo quando il processore 80286 a metà degli anni '80 che la modalità protetta divenne parte della CPU.

Prima di Windows 3.x, che era la prima versione delle applicazioni DOS multitasking, c'erano programmi come DesqView che potevano fare altrettanto. Se ad esempio uno eseguiva tre sessioni DOS contemporaneamente, DesqView creerebbe quattro macchine virtuali. Le tre sessioni DOS penserebbero ciascuna di "possedere" l'intera macchina, tranne per il fatto che nessuna di esse avrebbe effettivamente eseguito l'I / O dei file. Invece, la versione di DOS in esecuzione in ciascuna sessione verrebbe modificata in modo da inoltrare qualsiasi richiesta di I / O di file a una sessione speciale, dedicata a tale scopo. Poiché l'hardware in modalità testo del PC visualizzerebbe continuamente i contenuti di un'area di memoria come caratteri; DesqView potrebbe consentire a ciascuna sessione di avere il proprio schermo virtuale mappando l'intervallo 0xB8000-0xB9FFF di ciascuna sessione sulla propria area di RAM, e periodicamente copiando l'area dell'applicazione corrente nel buffer dello schermo fisico. Il supporto grafico era molto più difficile, perché 256K di RAM sul tabellone erano controllati usando 64K di spazio degli indirizzi, alcuni registri I / O e alcuni hardware "interessanti" che richiedevano che le cose fossero lette e scritte in determinate sequenze specifiche. In modalità testo, quando un'applicazione scriveva qualcosa nel buffer di testo, DesqView poteva impostare un flag che indicava che doveva essere copiato sul display al successivo tick del timer; solo la prima scrittura nel buffer di testo in un determinato intervallo di tempo richiederebbe l'intervento di DesqView; tutti gli altri verrebbero consolidati al prossimo tick del timer. perché 256K di RAM sul tabellone erano controllati usando 64K di spazio degli indirizzi, alcuni registri I / O e un hardware "interessante" che richiedeva che le cose fossero lette e scritte in determinate sequenze specifiche. In modalità testo, quando un'applicazione scriveva qualcosa nel buffer di testo, DesqView poteva impostare un flag che indicava che doveva essere copiato sul display al successivo tick del timer; solo la prima scrittura nel buffer di testo in un determinato intervallo di tempo richiederebbe l'intervento di DesqView; tutti gli altri verrebbero consolidati al prossimo tick del timer. perché 256K di RAM sul tabellone erano controllati usando 64K di spazio degli indirizzi, alcuni registri I / O e un hardware "interessante" che richiedeva che le cose fossero lette e scritte in determinate sequenze specifiche. In modalità testo, quando un'applicazione scriveva qualcosa nel buffer di testo, DesqView poteva impostare un flag che indicava che doveva essere copiato sul display al successivo tick del timer; solo la prima scrittura nel buffer di testo in un determinato intervallo di tempo richiederebbe l'intervento di DesqView; tutti gli altri verrebbero consolidati al prossimo tick del timer. DesqView potrebbe impostare un flag che indica che dovrebbe essere copiato sul display al successivo tick del timer; solo la prima scrittura nel buffer di testo in un determinato intervallo di tempo richiederebbe l'intervento di DesqView; tutti gli altri verrebbero consolidati al prossimo tick del timer. DesqView potrebbe impostare un flag che indica che dovrebbe essere copiato sul display al successivo tick del timer; solo la prima scrittura nel buffer di testo in un determinato intervallo di tempo richiederebbe l'intervento di DesqView; tutti gli altri verrebbero consolidati al prossimo tick del timer.

Al contrario, la virtualizzazione della modalità grafica richiederebbe che DeskView esegua il trap di ogni singola scrittura per visualizzare i registri di memoria o I / O. Dato che ciò rallenterebbe le scritture di memoria di un fattore di circa 100 e che i programmi di grafica dovevano scrivere molti più dati rispetto ai programmi di testo, la virtualizzazione in tempo reale della maggior parte dei software grafici non era pratica. Invece, la grafica è stata gestita avendo qualsiasi applicazione non in primo piano che ha cercato di mettere in pausa la grafica fino a quando non è diventata l'applicazione in primo piano, e quindi dandogli il pieno controllo sullo schermo. Quando il controllo è passato a un'altra applicazione, DesqView prova a fare una copia dello stato di tutti i registri grafici e quindi passa. Al ritorno all'applicazione grafica, DesqView ripristina lo stato salvato.

In un certo senso, le applicazioni DOS non grafiche multi-tasking erano più facili delle applicazioni Windows multi-tasking perché c'erano pochissime risorse condivise e le applicazioni non dovevano interagire tra loro. In Windows, al contrario, è necessario occuparsi di cose come gli appunti o la possibilità che le finestre di un programma possano spostarsi in modo tale da oscurare quelle di un altro. Windows 95 è stata la prima versione di Windows in grado di superare tali limiti includendo elementi come un sistema a finestre che potrebbe contenere la mancanza di un'area dello schermo mentre il codice stava provando a disegnare su di esso (con l'effetto che il disegno sarebbe stato mascherato ).

Il multitasking non è altro che un'illusione di eseguire applicazioni contemporaneamente. Viene percepito come esecuzione simultanea da parte tua, ma in realtà i processi A, B e C condividono il tempo della CPU in questo ordine: A, B, C, A, B, C, A, B ... si accendono e via molto rapidamente. In realtà non esistono due processi contemporaneamente.

Quindi, è perfettamente possibile creare il multitasking MS-DOS facendogli mettere in pausa un processo, eseguire il successivo per un breve periodo di tempo, mettere in pausa quello, tornare al primo e così via.

Il multitasking è solo una funzione intelligente sviluppata quando le CPU hanno iniziato a essere abbastanza veloci da continuare a ruotare attraverso questi processi e farlo sembrare simultaneo all'utente finale.

Per quelli che ricordano, i giochi erano ancora in esecuzione su DOS4GW perché Windows era troppo lento.

Anche se può concentrarsi solo su un compito, ciò che farebbe è un semplice passo per passare rapidamente dall'uno all'altro. In questo modo sembrava che fosse multitasking, ma in verità si stava solo concentrando su 1, poi su un altro, quindi su un altro, ecc.

Una cosa che non ho visto menzionato qui è piuttosto interessante:

Windows 3.0 non era un sistema multitasking preventivo ma cooperativo come tutte le versioni di MacOS fino a OS X: un'app doveva tornare da una chiamata prima che qualsiasi altra app potesse intraprendere un'azione.

Come mi ha ricordato un commentatore, tuttavia, le app DOS erano multitasking. Questo perché non sono stati scritti in multi-task "Cooperativamente" (questo deve sempre essere integrato nei sistemi che lo utilizzano).

All'epoca c'erano programmi chiamati TSR (Terminate-Stay Resident) che prendevano il posto dei driver di dispositivo odierni. Questi driver verrebbero eseguiti in modo indipendente, generalmente sul proprio thread inserendosi in uno dei gestori di eventi del sistema operativo. In genere Windows non li conosceva, funzionavano a un livello inferiore.

Queste non erano in realtà app di Windows, ma erano come tutte le attività di threading si svolgevano prima di Windows 3.1 come driver della stampante, driver COM, ecc.

Sebbene Windows 3.1 fosse multi-tasking, DOS non lo era, ma Windows 3.1 ha semplicemente eliminato Dos e ha preso il comando all'avvio (All'epoca spesso si avviava Windows da un prompt di DOS).

Buona domanda. In MS-DOS, il kernel era monolitico, il che significa che gestiva solo un'attività alla volta, rispetto al nuovo kernel moderno implementato in Windows 9x e nella versione corrente. Puoi saperne di più qui .