12Sep

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

click fraud protection

Med tanke på 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 med 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 enkeltoppgave OS.Men hvis eldre versjoner av Windows( også inkludert Windows 95?) Var bare wrappers for DOS, hvordan kunne de kjøre som et 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:

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

Windows 95 faktisk hekta / overrode omtrent alle MS-DOS, holde det som et kompatibilitetslag mens du gjør all den tunge løftingen selv. Det implementerte også forutgående multitasking for 32-biters programmer.

Pre-Windows 95

Windows 3.x og eldre var for det meste 16-biters( med unntak av Win32s, en slags kompatibilitetslag som brer 16 og 32, men vi vil ignorere det her), var mer avhengige av DOS, ogbrukes bare samarbeidende multi-tasking - det er den der de ikke tvinge et løpende program for å slå ut;de venter på det kjørende 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, særlig meldingsbehandling. Så lenge en oppgave behandlet meldinger i tide, var alt bra. Hvis en oppgave slutte å behandle meldinger og var opptatt av å utføre en prosesseringsløkke, var ikke multi-tasking lenger.

Windows 3.x Arkitektur

Som for hvor tidlig Windows-programmer vil gi kontroll:

  • Windows 3.1 bruker samarbeidende multi-tasking - noe som betyr at hvert program som er i ferd med å kjøre, blir instruert til å periodisk sjekke en meldingskø for å finne ut om noenEn annen applikasjon ber om bruk av CPU og, i så fall, for å gi kontroll over 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 pre-emptive 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

Alle 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 Utvidet modus?

Merk: Det har vært noen kommentarer om 386 forbedret modus for Windows 3.x som er 32-bit, og støtter forutgående multitasking.

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

MS-DOS ville også løpe inne i de virtuelle maskinene, og tilsynelatende var de fortrinnsvis multi-tasked - så det ser ut som at 386-forbedret modus hypervisor vil dele CPU-tidssnitt mellom virtuelle maskiner( hvorav den ene kjørte normal 3.xog andre som kjørte MS-DOS), og hver VM vil gjøre sine egne ting - 3.x ville samarbeide multi-oppgave, mens MS-DOS ville være enkeltoppgave.

MS-DOS

DOS selv var enkeltoppgave 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 en hvilken som helst bit-ness. Men flyttingen fra 16-bits prosessorer til 32-biters prosessorer introduserte også annen maskinvarefunksjonalitet som kunne ha gjort forhåndsoptisk multi-tasking enklere å implementere.

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 gamle 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 applikasjoner 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 maskinvaretilgang er nødvendig, må applikasjonen kommunisere via enhetsdrivere.

OS kan håndheve denne kontrollen, fordi den 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.

* Når DOS ble opprettet først på 1970-tallet, eksisterte ikke beskyttet modus i CPU.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.