Come era possibile il multitasking nelle versioni precedenti di Windows?
Considerando che DOS era un sistema operativo single-tasking e i legami che aveva con le prime versioni di Windows, come le versioni precedenti di Windows riuscivano a realizzare il multi-tasking? Il post di Q & A di SuperUser di oggi esamina le risposte a questa domanda.
La sessione di domande e risposte di oggi ci viene fornita per gentile concessione di SuperUser, una suddivisione di Stack Exchange, un raggruppamento di siti Web di domande e risposte basato sulla comunità.
Schermata di Windows 95 per gentile concessione di Wikipedia.
La domanda
Lettore SuperUser LeNoob vuole sapere in che modo le versioni precedenti di Windows erano in grado di funzionare come sistemi multi-tasking ?:
Ho letto che DOS è un sistema operativo single-tasking. Ma se le versioni precedenti di Windows (incluso anche Windows 95?) Erano solo wrapper per DOS, come potevano funzionare come un sistema operativo multi-tasking?
Buona domanda! Come hanno fatto le versioni precedenti di Windows a funzionare come sistemi multi-tasking?
La risposta
Collaboratori SuperUser Bob e Pete hanno la risposta per noi. Per prima cosa, Bob:
Windows 95 era molto più che "solo un wrapper" per MS-DOS. Citando Raymond Chen:
- MS-DOS ha due scopi in Windows 95: 1.) Ha funzionato come caricatore di avvio. & 2.) Ha funzionato come livello driver di dispositivo legacy a 16 bit.
Windows 95 ha effettivamente agganciato / ignorato quasi tutto MS-DOS, mantenendolo come livello di compatibilità mentre si fa tutto il lavoro pesante stesso. Ha anche implementato il multi-tasking pre-emptive per i programmi a 32 bit.
Pre-Windows 95
Windows 3.xe precedenti erano principalmente a 16 bit (con l'eccezione di Win32s, una sorta di livello di compatibilità che collega 16 e 32, ma ignoreremo quello qui), erano più dipendenti dal DOS e usavano solo il multi-tasking cooperativo - questo è quello in cui non forzano l'uscita di un programma in esecuzione; aspettano che il programma in esecuzione produca il controllo (in pratica, dì "I am done" dicendo al sistema operativo di eseguire il prossimo programma che è in attesa).
- Il multi-tasking era cooperativo, proprio come nelle vecchie versioni di MacOS (sebbene diversamente dal Multi-tasking DOS 4.x, che sfoggiava il multi-tasking pre-emptive). Un'attività doveva cedere al sistema operativo per pianificare un compito diverso. 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 occupata a eseguire un ciclo di elaborazione, il multitasking non era più disponibile.
Architettura di Windows 3.x.
Per quanto riguarda i primi programmi Windows darebbe il controllo:
- Windows 3.1 utilizza il multi-tasking cooperativo: ciò significa che ogni applicazione in corso di esecuzione viene istruita per controllare periodicamente una coda di messaggi per scoprire se qualsiasi altra applicazione richiede l'utilizzo della CPU e, in tal caso, per fornire il controllo a quella domanda. Tuttavia, molte applicazioni di Windows 3.1 controllerebbero la coda dei messaggi solo di rado, o per niente, e monopolizzerebbero il controllo della CPU per il tempo necessario. Un sistema multi-tasking pre-emptive come Windows 95 toglierà il controllo della CPU da un'applicazione in esecuzione e la distribuirà a quelli che hanno una priorità più alta in base alle esigenze del sistema.
fonte
Tutti i DOS vedrebbero questa singola applicazione (Windows o altro) in esecuzione, che passerebbe il controllo in giro senza uscire. In teoria, il multi-tasking preventivo può eventualmente essere implementato su DOS in ogni caso con l'uso di un clock in tempo reale e di interrupt hardware per fornire forzatamente il controllo allo scheduler. Come commenta Tonny, questo in realtà è stato fatto da alcuni sistemi operativi in esecuzione su DOS.
386 modalità avanzata?
Nota: ci sono stati alcuni commenti sulla 386 modalità avanzata di Windows 3.x a 32 bit e sul supporto di multi-tasking pre-emptive.
Questo è un caso interessante. Per riassumere il post del blog collegato, 386 modalità avanzata era fondamentalmente un hypervisor a 32 bit, che eseguiva macchine virtuali. All'interno di una di quelle macchine virtuali è stata eseguita la modalità standard di Windows 3.x, che fa tutto quanto sopra elencato.
MS-DOS funzionava anche all'interno di quelle macchine virtuali, e apparentemente erano pre-imperniati in multi-tasking - quindi sembra che l'hypervisor della modalità avanzata 386 condividerà le fette di tempo della CPU tra le macchine virtuali (una delle quali eseguiva 3.x normale e altri che eseguivano MS-DOS), e ogni VM farà la propria cosa - 3.x coopererebbe in modo multi-task, mentre MS-DOS sarebbe single-tasked.
MS-DOS
Lo stesso DOS era single-tasking su carta, ma aveva il supporto per i programmi TSR che rimanevano in background fino a quando non veniva attivato da un interrupt hardware. Lontano dal vero multi-tasking, ma neanche completamente single-task.
Tutto questo parlare di bit-ness? Ho chiesto informazioni sul multi-tasking!
Bene, in senso stretto, la bit-ness e il multi-tasking non dipendono l'uno dall'altro. Dovrebbe essere possibile implementare qualsiasi modalità multi-tasking 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ù facile l'implementazione multi-tasking preventiva.
Inoltre, poiché i programmi a 32 bit erano nuovi, è stato più facile farli funzionare quando sono stati forzatamente disattivati, il che potrebbe aver inficiato alcuni programmi legacy a 16 bit.
Certo, questa è tutta speculazione. Se vuoi veramente sapere perché MS non ha implementato il multi-tasking pre-emptive in Windows 3.x (nonostante la modalità avanzata 386), dovrai chiedere a qualcuno che ha lavorato lì.
Inoltre, volevo correggere la tua ipotesi che Windows 95 fosse solo un wrapper per DOS.
Seguito dalla risposta di Pete:
In un moderno sistema operativo, il sistema operativo controlla tutte le risorse hardware e le applicazioni in esecuzione sono conservate in sandbox. Un'applicazione non è autorizzata ad accedere alla memoria che il sistema operativo non ha assegnato a tale applicazione e non può accedere direttamente ai dispositivi hardware nel computer. Se è richiesto l'accesso all'hardware, l'applicazione deve comunicare attraverso i driver di dispositivo.
Il sistema operativo può applicare questo controllo, perché costringe la CPU ad entrare in modalità protetta.
DOS, d'altra parte, non entra mai in modalità protetta, ma rimane in modalità reale (*vedi sotto). Nella modalità reale, le applicazioni in esecuzione possono eseguire qualsiasi cosa vogliano, ovvero 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 fondamentalmente lanciate da DOS.
DOS (Disk Operating System) era, per quanto ne so, non molto più di un sistema di gestione file. Forniva un file system, i meccanismi per navigare nel file system, alcuni strumenti e la possibilità di avviare le applicazioni. Ha anche permesso ad alcune applicazioni di rimanere residenti, ad esempio driver del mouse ed emulatori EMM. Ma non ha cercato di controllare l'hardware nel computer come fa un sistema operativo moderno.
*Quando il DOS fu creato negli anni '70, la modalità protetta non esisteva nella CPU. Fu solo con il processore 80286 a metà degli anni '80 che la modalità protetta divenne parte della CPU.
Assicurati di passare alla discussione originale e di leggere la vivace discussione su questo argomento usando il link sottostante!
Hai qualcosa da aggiungere alla spiegazione? Audio disattivato nei commenti. Vuoi leggere più risposte dagli altri utenti di Stack Exchange esperti di tecnologia? Controlla la discussione completa qui.
