Cum a fost posibilă multi-tasking în versiunile mai vechi ale Windows?

Având în vedere că DOS era un sistem de operare cu o singură operațiune ș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? Astăzi, postul SuperUser Q & A examinează răspunsurile la această întrebare.

Întrebarea de astăzi &Sesiunea de răspuns 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.

Cititorul de întrebări

SuperUser LeNoob dorește să știe cum versiunile mai vechi ale Windows au fost capabile să ruleze ca sisteme multi-tasking? :

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

Întrebare bună!Cum au reușit să funcționeze versiunile mai vechi de Windows ca sisteme multi-tasking?

Raspunsul

Contribuitorii SuperUser Bob si Pete au raspunsul pentru noi.În primul rând, Bob:

Windows 95 a fost mult mai mult decât "doar o învelitoare" pentru MS-DOS.Citind Raymond Chen:

• MS-DOS a servit două scopuri în Windows 95: 1.) A servit ca încărcător de boot.& Amp;2.) A acționat ca strat de driver pentru dispozitivele tradiționale de 16 biți.

Ferestre 95 de fapt, cârligate / overrode aproape toate MS-DOS, păstrându-l ca un strat de compatibilitate în timp ce face toate ridicarea grele în sine. De asemenea, a implementat multi-tasking preemptiv pentru programele pe 32 de biți.

Pre-Windows 95

Windows 3.x și mai în vârstă au fost în 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 șiutilizați numai cooperarea multi-tasking - aceasta este cea în care nu forțează un program de rulare să se stingă;ei așteaptă ca programul să ruleze pentru a obține 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 Multi-tasking DOS 4.x, care a sportiv de pre-emptive multi-tasking).O sarcină trebuia să cedeze sistemului de operare 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 grozav. Dacă o activitate a încetat să mai proceseze mesaje și a fost ocupată cu executarea unei anumite buclă de procesare, multi-tasking nu mai era.

Windows 3.x Arhitectura

În ceea ce privește modul în care programele Windows devreme ar 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ă existăo altă aplicație solicită utilizarea procesorului și, dacă da, pentru a obține controlul acestei aplicații. Cu toate acestea, multe aplicații Windows 3.1 ar verifica coada de mesaje doar rar sau deloc și vor monopoliza controlul CPU-ului 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.

Sursa

Toate programele 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 implementat oricum cu ajutorul unui ceas în timp real, iar hardware-ul se întrerupe pentru a da forță 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-ului.

386 Modul îmbunătățit?

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

Acesta este un caz interesant. Pentru a rezuma postarea legată de blog, 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 rula, de asemenea, în interiorul acelor mașini virtuale și, aparent, au fost pre-emptive multi-tasked - așa că se pare că hypervisorul modei 386 î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 tasked.

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ți? Am întrebat despre multi-tasking!

Ei bine, strict vorbind, bit-ness și multi-tasking nu depind 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 și alte funcționalități hardware care ar fi putut face mai ușoară implementarea pre-emptive multi-tasking.

De asemenea, deoarece programele pe 32 de biți erau noi, a fost mai ușor să le dăm la lucru când au fost dezactivate forțat - ceea ce ar fi putut sparge unele programe vechi pe 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 preemptive în Windows 3.x( în ciuda modului 386 îmbunătățit), va trebui să întrebați pe cineva care a lucrat acolo.

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

Urmat de răspunsul de la Pete:

Într-un sistem de operare modern, sistemul de operare controlează toate resursele hardware, iar aplicațiile care rulează sunt păstrate în nisipuri. 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ă hardware direct. 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.

* Când DOS a fost creat prima dată î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ă navigați pe firul original și citiți discuția plină de viață cu privire la acest subiect folosind link-ul de mai jos!

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