Cum a fost posibilă utilizarea mai multor sarcini în versiunile mai vechi ale Windows?

Având în vedere că DOS era un sistem de operare unicat și legăturile pe care le avea cu versiunile anterioare de Windows, cum au reușit mai multe versiuni de Windows să realizeze multi-tasking? Postul de astăzi SuperUser Q & A se uită la răspunsurile la această întrebare.

Sesiunea de întrebări și răspunsuri din ziua de astăzi vine de la amabilitatea SuperUser - o subdiviziune a Stack Exchange, o grupare bazată pe comunitate a site-urilor web Q & A.

Windows 95 screenshot de la Wikipedia.

Intrebarea

Cititorul de SuperUser LeNoob dorește să știe cum versiunile mai vechi ale Windows au putut să funcționeze ca sisteme multi-tasking ?:

Am citit că DOS este un sistem de operare unicat. Dar dacă versiunile mai vechi de Windows (inclusiv Windows 95?) Erau doar împachetări pentru DOS, cum ar putea funcționa ca un sistem multi-tasking?

Buna intrebare! Cum au reușit să ruleze versiunile mai vechi ale Windows ca sisteme multi-tasking?

Răspunsul

Utilizatorii SuperUser Bob și Pete au răspunsul pentru noi. În primul rând, Bob:

Windows 95 a fost mult mai mult decât "doar un pachet" pentru MS-DOS. Citat Raymond Chen:

• MS-DOS a servit două scopuri în Windows 95: 1.) A servit ca încărcător de boot. & 2.) A acționat ca strat de șofer de dispozitiv de 16 biți.

Windows 95 de fapt a atras / overrode aproape toate MS-DOS, păstrând-o ca pe un strat de compatibilitate în timp ce face toate ridicările grele în sine. De asemenea, a implementat multi-tasking preemptive pentru programele pe 32 de biți.

Pre-Windows 95

Windows 3.x și mai în vârstă au fost în cea mai mare parte pe 16 biți (cu excepția Win32s, un fel de strat de compatibilitate care leagă 16 și 32, dar vom ignora acest lucru aici), erau mai dependenți de DOS și foloseau doar multi-tasking cooperativ - aceasta este cea în care nu forțează un program de rulare pentru a ieși; ei așteaptă programul care rulează să producă controlul (practic, spuneți "Am terminat", spunând sistemului de operare să ruleze următorul program care așteaptă).

• Multi-tasking a fost cooperativ, la fel ca în versiunile vechi ale MacOS (deși spre deosebire de DOS 4.x multi-tasking, care a sporit pre-emptive multi-tasking). O sarcină trebuia să se predea OS-ului pentru a programa o sarcină diferită. Randamentele au fost integrate în anumite apeluri API, în special în procesarea mesajelor. Atâta timp cât o sarcină a procesat mesajele în timp util, totul a fost minunat. Dacă o sarcină a încetat să proceseze mesaje și a fost ocupată cu executarea unei anumite buclă de procesare, multi-tasking nu mai era.

Windows 3.x Architecture

În ceea ce privește modul în care programele Windows devreme ar putea controla randamentul:

• Windows 3.1 folosește multi-tasking cooperativ - ceea ce înseamnă că fiecare aplicație care este în curs de rulare este instruită să verifice periodic o coadă de mesaje pentru a afla dacă orice altă aplicație cere utilizarea CPU și, dacă da, acea aplicație. Cu toate acestea, multe aplicații Windows 3.1 ar verifica coada de mesaje doar rar sau deloc și să monopolizeze controlul asupra procesorului pentru o perioadă cât mai mare de timp. Un sistem multi-tasking preemptiv, cum ar fi Windows 95, va lua controlul procesorului departe de o aplicație în desfășurare și îl va distribui celor care au o prioritate mai mare pe baza nevoilor sistemului.

Sursă

Toate aplicațiile DOS ar vedea că această aplicație unică (Windows sau alta) rulează, ceea ce ar trece controlul fără a ieși. Teoretic, multi-tasking-ul preemptiv poate fi pus în aplicare, oricum, cu ajutorul unui ceas în timp real, iar hardware-ul întrerupe forțarea controlului programatorului. După cum comentă Tonny, acest lucru a fost de fapt făcut de unele sisteme de operare care rulează pe partea de sus a DOS.

386 Modul îmbunătățit?

Notă: au existat unele comentarii cu privire la modul îmbunătățit 386 de Windows 3.x fiind de 32 de biți și suportul multi-tasking preemptive.

Acesta este un caz interesant. Pentru a rezuma postarea de blog legate, modul 386 îmbunătățit a fost în esență un hypervisor pe 32 de biți, care a rulat mașini virtuale. În interiorul uneia dintre aceste mașini virtuale a funcționat modul standard Windows 3.x, care face toate lucrurile enumerate mai sus.

MS-DOS ar fi, de asemenea, rulați în interiorul acelor mașini virtuale și, aparent, acestea au fost pre-emptive multi-tasked - așa că se pare că hypervisorul 386 mode îmbunătățit va împărți felii de timp CPU între mașinile virtuale (dintre care unul a rulat normal 3.x și alții care au rulat MS-DOS), și fiecare VM va face propriul lucru - 3.x ar cooperativ multi-task, în timp ce MS-DOS ar fi un singur sarcină.

MS-DOS

DOS în sine a fost un singur tasking pe hârtie, dar a avut suport pentru programele TSR care ar rămâne în fundal, până la declanșarea unei întreruperi hardware. Departe de adevărat multi-tasking, dar nu complet singur-sarcina fie.

Toate vorbele despre biții? Am întrebat despre multi-tasking!

Ei bine, strict vorbind, bit-ness și multi-tasking nu sunt dependente unul de celălalt. Ar trebui să fie posibilă implementarea oricărui mod multi-tasking în orice bit-ness. Cu toate acestea, trecerea de la procesoare pe 16 biți la procesoare pe 32 de biți a introdus, de asemenea, alte funcționalități hardware care ar fi putut simplifica implementarea preambulului multi-tasking.

De asemenea, deoarece programele pe 32 de biți erau noi, a fost mai ușor să le dăm la lucru atunci când au fost oprite forțat - ceea ce ar fi putut rupe unele programe vechi de 16 biți.

Desigur, toate acestea sunt speculații. Dacă doriți cu adevărat să știți de ce MS nu a implementat multi-tasking pre-emptive în Windows 3.x (în ciuda modei 386 îmbunătățite), va trebui să întrebați pe cineva care a lucrat acolo.

De asemenea, am vrut să vă corectez ipoteza că Windows 95 era doar un pachet pentru DOS.

Urmat de răspunsul lui Pete:

Într-un sistem de operare modern, sistemul de operare controlează toate resursele hardware, iar aplicațiile care rulează sunt păstrate în sandbox-uri. O aplicație nu are permisiunea de a accesa memoria pe care OS-ul nu a alocat aplicația respectivă și nu poate accesa direct dispozitivele hardware din computer. Dacă este necesar accesul hardware, aplicația trebuie să comunice prin intermediul driverelor de dispozitive.

Sistemul de operare poate impune acest control, deoarece forțează procesorul să intre în modul protejat.

DOS, pe de altă parte, nu intră niciodată în modul protejat, dar rămâne în modul real (*Vezi mai jos). În modul real, aplicațiile care rulează pot efectua orice vrea, adică accesează direct hardware-ul. Dar o aplicație care rulează în modul real poate de asemenea să spună procesorului să intre în modul protejat.

Și această ultimă parte permite aplicațiilor ca Windows 95 să pornească un mediu multi-threaded chiar dacă au fost lansate de la DOS.

DOS (Sistemul de operare disc) a fost, din câte știu, mult mai mult decât un sistem de gestionare a fișierelor. Acesta a oferit un sistem de fișiere, mecanisme de navigare a sistemului de fișiere, câteva instrumente și posibilitatea de a lansa aplicații. De asemenea, a permis ca unele aplicații să rămână rezidente, adică drivere pentru șoareci și emulatori EMM. Dar nu a încercat să controleze hardware-ul în computer așa cum procedează un sistem modern de operare.

*Atunci când DOS a fost creat pentru prima oară în anii 1970, modul protejat nu exista în procesor. Nu a fost până când procesorul 80286, la mijlocul anilor 1980, modul protejat a devenit parte a procesorului.

Asigurați-vă că ați navigat peste firul original și citiți discuția plină de viață cu privire la acest subiect utilizând link-ul de mai jos!

Aveți ceva de adăugat la explicație? Sunați în comentariile. Doriți să citiți mai multe răspunsuri de la alți utilizatori de tehnologie Stack Exchange? Check out discuția completă aici.