Hvordan var Multi-Tasking mulig i eldre versjoner av Windows?

Tatt i betraktning at DOS var et enkeltoppgave-OS og båndene det hadde med tidligere versjoner av Windows, hvordan klarte tidligere versjoner av Windows å utføre multi-tasking? Dagens SuperUser Q & A-innlegg ser på svarene på dette spørsmålet.

Dagens Spørsmål & Svar-sesjon kommer til oss med høflighet av SuperUser-en underavdeling av Stack Exchange, en fellesskapsdrevet gruppering av Q & A-nettsteder.

Windows 95 skjermbilde høflighet av Wikipedia.

Spørsmålet

SuperUser leser LeNoob vil vite hvor eldre versjoner av Windows kunne kjøre som multi-tasking systemer ?:

Jeg leste at DOS er et single-tasking OS. Men hvis eldre versjoner av Windows (også inkludert Windows 95?) Var bare wrappers for DOS, hvordan kunne de kjøre som en multi-tasking OS?

Godt spørsmål! Hvordan klarte eldre versjoner av Windows å kjøre som multi-tasking-systemer?

Svaret

SuperUser-bidragsytere Bob og Pete har svaret for oss. Først opp, Bob:

Windows 95 var langt mer enn "bare en wrapper" for MS-DOS. Sitat Raymond Chen:

• MS-DOS serverte to formål i Windows 95: 1.) Det fungerte som oppstartslaster. & 2.) Det fungerte som 16-biters eldre enhetsdriverlag.

Windows 95 faktisk hekta / overrode omtrent alle MS-DOS, holde det som et kompatibilitetslag samtidig som du gjør alt tungt løfte seg selv. Den implementerte også forhåndsoptisk multi-tasking for 32-biters programmer.

Pre-Windows 95

Windows 3.x og eldre var for det meste 16-biters (med unntak av Win32s, et slags kompatibilitetslag som brer 16 og 32, men vi vil ignorere det her), var mer avhengige av DOS, og brukte bare samarbeidende multi-tasking - det er den der de ikke tvinger et løpende program for å slå ut; de venter på det løpende programmet for å gi kontroll (i utgangspunktet si "Jeg er ferdig" ved å fortelle operativsystemet å kjøre det neste programmet som venter).

• Multi-tasking var samarbeidsvillig, akkurat som i gamle versjoner av MacOS (men i motsetning til Multi-tasking DOS 4.x, som hadde pre-emptive multi-tasking). En oppgave måtte gi til operativsystemet for å kunne planlegge en annen oppgave. Utbyttene ble bygd inn i enkelte API-anrop, spesielt meldingsbehandling. Så lenge en oppgave behandlet meldinger i tide, var alt bra. Hvis en oppgave slutte å behandle meldinger og var opptatt med å utføre en prosesseringsløkke, var ikke multi-tasking lenger.

Windows 3.x Arkitektur

Når det gjelder hvor tidlig Windows-programmer vil gi kontroll:

• Windows 3.1 bruker samarbeidende multi-tasking - noe som betyr at hver applikasjon som er i ferd med å kjøre, blir instruert til å periodisk sjekke en meldingskø for å finne ut om noe annet program ber om bruk av CPU og i så fall å gi kontroll til den applikasjonen. Imidlertid vil mange Windows 3.1-programmer sjekk meldingen køen sjeldent, eller slet ikke, og monopolisere kontrollen av CPUen i så mye tid som de krevde. Et forvalgs multi-tasking-system som Windows 95 vil ta CPU-kontroll vekk fra et løpende program og distribuere det til de som har høyere prioritet basert på systemets behov.

Kilde

Alt DOS ville se er dette enkeltprogrammet (Windows eller annet) som kjører, som ville passere kontrollen uten å avslutte. I teorien kan forutgående multitasking muligens implementeres på toppen av DOS uansett ved bruk av en sanntidsklokke og maskinvareavbrudd for å tvinge til å gi kontroll til planleggeren. Som Tonny kommenterte, ble dette faktisk gjort av noen operatører som kjører på toppen av DOS.

386 Forbedret modus?

Merk: Det har vært noen kommentarer på 386 forbedret modus for Windows 3.x som er 32-bit, og støtter forhåndsinnstilt multi-tasking.

Dette er et interessant tilfelle. For å oppsummere det koblede blogginnlegget, var 386 forbedret modus i utgangspunktet en 32-biters hypervisor, som kjørte virtuelle maskiner. Inne i en av de virtuelle maskinene kjørte Windows 3.x standard modus, som gjør alle de ting som er oppført ovenfor.

MS-DOS ville også kjøre i de virtuelle maskinene, og tilsynelatende var de forutsetninger flere oppgaver - så det ser ut som at 386-forbedret modus-hypervisor vil dele CPU-tidssnitt mellom de virtuelle maskinene (hvorav den ene kjørte normal 3.x og andre som kjørte MS-DOS), og hver VM vil gjøre sin egen ting - 3.x ville samarbeide multi-oppgave, mens MS-DOS ville være single-tasked.

MS-DOS

DOS selv var single-tasking på papir, men det hadde støtte for TSR-programmer som ville forbli i bakgrunnen til utløst av en maskinvareavbrudd. Langt fra sann multi-tasking, men ikke helt enkelt oppgavet.

Alt dette snakk om bit-ness? Jeg spurte om multi-tasking!

Vel, strengt tatt, er bit-ness og multi-tasking ikke avhengig av hverandre. Det bør være mulig å implementere en hvilken som helst multi-tasking-modus i hvilken som helst bit-ness. Men flyttingen fra 16-bits prosessorer til 32-bits prosessorer introduserte også annen maskinvarefunksjonalitet som kunne ha gjort forhåndsoptisk multi-tasking enklere å implementere.

Også siden 32-biters programmer var nye, var det lettere å få dem til å jobbe når de ble tvingt ut - noe som kanskje har brutt noen arv 16-biters programmer.

Selvfølgelig er dette all spekulasjon. Hvis du virkelig vil vite hvorfor MS ikke implementerte forhåndsoptisk multitasking i Windows 3.x (386 forbedret modus uansett), må du spørre noen som jobbet der.

Også, jeg ønsket å korrigere antagelsen om at Windows 95 bare var en wrapper for DOS.

Etterfulgt av svaret fra Pete:

I et moderne operativsystem styrer operativsystemet alle maskinvareressurser, og løpende programmer holdes i sandkasser. Et program er ikke tillatt å få tilgang til minne som operativsystemet ikke har tildelt det programmet, og det kan ikke direkte få tilgang til maskinvareenheter i datamaskinen. Hvis maskinvareadgang er nødvendig, må applikasjonen kommunisere via enhetsdrivere.

Operativsystemet kan håndheve denne kontrollen, fordi det tvinger CPU til å gå inn i beskyttet modus.

DOS, derimot, går aldri inn i beskyttet modus, men forblir i sann modus (*se nedenfor). I ekte modus kan de løpende applikasjonene utføre alt det vil, dvs. tilgang til maskinvare direkte. Men et program som kjører i ekte modus kan også fortelle CPUen å gå inn i beskyttet modus.

Og denne siste delen tillater programmer som Windows 95 å starte et multi-threaded miljø, selv om de i utgangspunktet ble lansert fra DOS.

DOS (Disk Operating System) var, så vidt jeg vet, ikke mye mer enn et filhåndteringssystem. Det ga et filsystem, mekanismer for å navigere filsystemet, noen få verktøy, og muligheten til å starte applikasjoner. Det tillot også at enkelte programmer kan forbli bosatt, dvs. musedrivere og EMM-emulatorer. Men det forsøkte ikke å kontrollere maskinvaren i datamaskinen slik en moderne operasjon gjør.

*Da DOS ble opprettet først på 1970-tallet, fant ikke beskyttet modus i CPU-en. Det var ikke før 80286-prosessoren i midten av 1980-tallet at beskyttet modus ble en del av CPU.

Pass på å bla gjennom til den opprinnelige tråden og les gjennom den livlige diskusjonen om dette emnet ved å bruke linken under!

Har du noe å legge til forklaringen? Lyder av i kommentarene. Vil du lese flere svar fra andre tech-savvy Stack Exchange-brukere? Sjekk ut hele diskusjonstråden her.