12Sep
Considerando che il DOS era un sistema operativo a singolo compito 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.
Today's Question &La sessione di risposta ci viene fornita per gentile concessione di SuperUser, una suddivisione di Stack Exchange, un raggruppamento di Q & A basato su community. Screenshot
Windows 95 per gentile concessione di Wikipedia.
La domanda
SuperUser reader 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 a singolo compito. Ma se le versioni precedenti di Windows( incluso anche Windows 95?) Erano solo wrapper per DOS, come potevano funzionare come sistema operativo multitasking?
Buona domanda! In che modo le versioni precedenti di Windows sono riuscite a funzionare come sistemi multi-tasking?
La risposta
SuperUser contributori Bob e Pete hanno la risposta per noi. Innanzitutto, 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 boot loader.& Amp;2.) Ha funzionato come livello driver di dispositivo legacy a 16 bit.
Windows 95 ha effettivamente agganciato / scavalcato 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 eusato solo il multi-tasking cooperativo - cioè quello in cui non forzano l'uscita di un programma in esecuzione;aspettano che il programma in esecuzione dia il controllo( in pratica, dica "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( anche se 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 costruiti 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 Windows 3.x
Per quanto precoce i programmi Windows potrebbero fornire controllo:
- Windows 3.1 utilizza il multi-tasking cooperativo: ciò significa che ogni applicazione in corso di esecuzione viene istruita a controllare periodicamente una coda di messaggi per scoprire seun'altra applicazione richiede l'utilizzo della CPU e, in tal caso, offre il controllo di tale applicazione. Tuttavia, molte applicazioni di Windows 3.1 controllerebbero la coda dei messaggi solo di rado, o per nulla, 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.
Source
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.Modalità avanzata
386?
Nota: alcuni commenti sulla 386 modalità avanzata di Windows 3.x sono a 32 bit e supportano il 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à 386 condiviso condividerà le fette di tempo della CPU tra le macchine virtuali( una delle quali ha funzionato normalmente 3.xe altri che eseguivano MS-DOS), e ogni VM farà la sua cosa - 3.x coopererebbe in modo multi-task, mentre MS-DOS sarebbe a singolo compito.
MS-DOS
DOS stesso 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 introdotto anche altre funzionalità hardware che avrebbero potuto rendere più semplice l'implementazione multi-tasking preventiva.
Inoltre, poiché i programmi a 32 bit erano nuovi, era più facile farli funzionare quando venivano forzatamente disattivati, il che avrebbe potuto danneggiare alcuni programmi legacy a 16 bit.
Naturalmente, 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 tramite i driver di periferica.
Il sistema operativo può imporre questo controllo, perché costringe la CPU a 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 indicare 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 è stato creato per la prima volta negli anni '70, la modalità protetta non esisteva nella CPU.Non è stato fino al processore 80286 a metà degli anni '80 che la modalità protetta divenne parte della CPU.
Assicurati di navigare sul thread originale e di leggere la vivace discussione su questo argomento usando il link qui sotto!
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.