Hvordan var multi-tasking mulig i gamle versioner af Windows?

I betragtning af at DOS var et single-tasking OS og de bånd, det havde med tidlige versioner af Windows, hvordan har tidligere versioner af Windows formået at udføre multi-tasking? Dagens SuperUser Q & A-indlæg ser på svarene på dette spørgsmål.

Dagens Spørgsmål & Svar session kommer til os med venlig hilsen af SuperUser-en underafdeling af Stack Exchange, en community-driven gruppe af Q & A-websteder.

Windows 95 screenshot høflighed af Wikipedia.

Spørgsmålet

SuperUser-læser LeNoob ønsker at vide, hvor ældre versioner af Windows kunne køre som multi-tasking-systemer ?:

Jeg læser, at DOS er et single-tasking OS. Men hvis ældre versioner af Windows (også herunder Windows 95?) Var bare wrappers til DOS, hvordan kunne de køre som et multi-tasking OS?

Godt spørgsmål! Hvordan lykkedes ældre versioner af Windows at køre som multi-tasking systemer?

Svaret

SuperUser bidragsydere Bob og Pete har svaret for os. Først op, Bob:

Windows 95 var langt mere end "bare en wrapper" til MS-DOS. Citerer Raymond Chen:

MS-DOS tjente to formål i Windows 95: 1.) Det fungerede som boot loader. & 2.) Det fungerede som et 16-bit ældre enhedsdriverlag.

Windows 95 faktisk hooked / overrode næsten alle MS-DOS, holde det som et kompatibilitet lag, mens du gør alt det tunge løft selv. Det implementerede også præ-emptive multi-tasking til 32-bit programmer.

Pre-Windows 95

Windows 3.x og ældre var for det meste 16-bit (med undtagelse af Win32s, en slags kompatibilitetslag, der broer 16 og 32, men vi vil ignorere det her), var mere afhængige af DOS og brugte kun kooperativ multi-tasking - det er det, hvor de ikke tvinge et løbende program til at slukke; de venter på det løbende program for at give kontrol (i grunden siger "Jeg er færdig" ved at fortælle OS at køre det næste program, der venter).

Multi-tasking var samarbejdsvillig, ligesom i gamle versioner af MacOS (selvom i modsætning til Multi-tasking DOS 4.x, som var præget af multi-tasking). En opgave måtte give til operativsystemet for at kunne planlægge en anden opgave. Udbyttet blev indbygget i visse API-opkald, især beskedbehandling. Så længe en opgave behandlede meddelelser rettidigt, var alt godt. Hvis en opgave stoppede behandling af meddelelser og var travlt med at udføre nogle behandlingssløjfer, var multi-tasking ikke mere.

Windows 3.x Arkitektur

Hvad angår hvor tidlige Windows-programmer der ville give kontrol:

Windows 3.1 bruger kooperativ multi-tasking - hvilket betyder, at hver applikation, der er i gang med at køre, instrueres til periodisk at kontrollere en meddelelseskø for at finde ud af om nogen anden applikation beder om brug af CPU'en og i givet fald at give kontrol til den ansøgning. Men mange Windows 3.1-applikationer kontrollerer kun meddelelseskøen sjældent eller slet ikke, og monopoliserer kontrol af CPU'en i så meget tid som de har brug for. Et præventive multi-tasking system som Windows 95 vil tage CPU-kontrol væk fra en kørende applikation og distribuere den til dem, der har højere prioritet baseret på systemets behov.

Kilde

Alle DOS ville se, at denne enkelt applikation (Windows eller andre) kører, som ville passere kontrol uden at gå ud. I teorien kan præ-emptive multi-tasking muligvis implementeres på toppen af DOS alligevel med brugen af en realtids ur og hardware interrupts for tværtimod at give kontrol til planlæggeren. Som Tonny kommenterede, blev dette faktisk gjort af nogle OS'er, der kører oven på DOS.

386 Forbedret tilstand?

Bemærk: Der har været nogle kommentarer om 386 forbedret tilstand af Windows 3.x er 32-bit og understøtter forudgående multitasking.

Dette er et interessant tilfælde. For at opsummere det linkede blogindlæg var 386 forbedret tilstand i grunden en 32-bit hypervisor, der kørte virtuelle maskiner. Inde i en af disse virtuelle maskiner kørte Windows 3.x standard tilstand, hvilket gør alle de ting, der er angivet ovenfor.

MS-DOS ville også køre inde i disse virtuelle maskiner, og tilsyneladende var de fortrinsvis multi-tasked - så det ser ud til, at 386-forbedret tilstands hypervisor deler CPU-tidsskiver mellem de virtuelle maskiner (hvoraf den ene kørte normal 3.x og andre som kørte MS-DOS), og hver VM vil gøre sine egne ting - 3.x ville samarbejde multi-task, mens MS-DOS ville være single-tasked.

MS-DOS

DOS selv var single-tasking på papir, men det havde støtte til TSR-programmer, der ville forblive i baggrunden, indtil det blev udløst af hardwareafbrydelser. Langt fra ægte multi-tasking, men ikke helt enkelt opgave.

Alt dette snak om bit-ness? Jeg spurgte om multi-tasking!

Tja, strengt taget er bit-ness og multi-tasking ikke afhængige af hinanden. Det bør være muligt at implementere enhver multi-tasking-tilstand i enhver bit-ness. Flytningen fra 16-bit-processorer til 32-bit-processorer introducerede dog også anden hardwarefunktionalitet, der kunne have gjort forudgående multitasking lettere at implementere.

Da 32-bit-programmerne var nye, var det lettere at få dem til at arbejde, da de blev tvinget til at blive slukket - hvilket måske har brudt nogle gamle 16-bit programmer.

Dette er selvfølgelig alle spekulationer. Hvis du virkelig ønsker at vide, hvorfor MS ikke implementerede præventive multi-tasking i Windows 3.x (386 forbedret tilstand uanset), skal du spørge nogen der arbejdede der.

Jeg ville også rette op på din antagelse om, at Windows 95 kun var en wrapper til DOS.

Efterfulgt af svaret fra Pete:

I et moderne operativsystem styrer operativsystemet alle hardware ressourcer, og løbende applikationer opbevares i sandkasser. En applikation er ikke tilladt at få adgang til hukommelse, som OS ikke har tildelt til den pågældende applikation, og den kan ikke direkte få adgang til hardwareenheder i computeren. Hvis hardwareadgang er påkrævet, skal applikationen kommunikere via enhedsdrivere.

OS kan håndhæve denne kontrol, fordi det tvinger CPU'en til at gå ind i beskyttet tilstand.

DOS går derimod aldrig i beskyttet tilstand, men forbliver i reel tilstand (*se nedenunder). I reel tilstand kan de kørende applikationer udføre alt, hvad det vil, dvs. adgang til hardware direkte. Men en applikation, der kører i ægte tilstand, kan også fortælle CPU'en at gå ind i beskyttet tilstand.

Og denne sidste del gør det muligt for programmer som Windows 95 at starte et multi-threaded-miljø, selvom de grundlæggende blev lanceret fra DOS.

DOS (Disk Operating System) var, så vidt jeg ved, ikke meget mere end et filhåndteringssystem. Det gav et filsystem, mekanismer til navigation af filsystemet, et par værktøjer og muligheden for at starte applikationer. Det tillod også nogle applikationer at forblive hjemmehørende, dvs. musedrivere og EMM-emulatorer. Men det forsøgte ikke at kontrollere hardwareen i computeren som det moderne operativsystem gør.

*Da DOS blev oprettet første gang i 1970'erne, eksisterede beskyttet tilstand ikke i CPU'en. Det var først indtil 80286-processoren i midten af 1980'erne, at beskyttet tilstand blev en del af CPU'en.

Sørg for at bladre videre til det oprindelige tråd og læse den livlige diskussion om dette emne ved at bruge linket herunder!

Har du noget at tilføje til forklaringen? Lyde af i kommentarerne. Vil du læse flere svar fra andre tech-savvy Stack Exchange brugere? Tjek den fulde diskussionstråd her.