12Sep
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 høflighed af SuperUser-en underafdeling af Stack Exchange, en community-drevet gruppe af Q & A-websteder.
Windows 95 screenshot høflighed af Wikipedia.
Spørgsmål
SuperUser-læser LeNoob ønsker at vide, hvor ældre versioner af Windows kunne køre som multi-tasking-systemer? :
Jeg læste, at DOS er et single-tasking OS.Men hvis ældre versioner af Windows( også inklusive Windows 95?) Kun var 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.Citat Raymond Chen:
- MS-DOS tjente to formål i Windows 95: 1.) Det fungerede som boot loader.& Amp;2.) Det fungerede som 16-bit arven enhedsdriverlag.
Windows 95 er faktisk hooked / overrode næsten alle MS-DOS, og holder det som et kompatibilitetslag, mens du gør alt det store 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 ogkun brugt kooperativ multi-tasking - det er den, 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 sportede forudgående multitasking).En opgave måtte give til operativsystemet for at kunne planlægge en anden opgave. Udbyttet blev bygget ind i visse API-opkald, især meddelelsesbehandling. Så længe en opgave behandlede beskeder 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 nogenanden ansøgning beder om brug af CPU'en og i givet fald at give kontrol til denne ansøgning. Men mange Windows 3.1-applikationer kontrollerer kun meddelelseskøen sjældent eller slet ikke, og monopoliserer styringen 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 anden) 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 vil dele CPU-tidsskiver mellem de virtuelle maskiner( hvoraf den ene kørte normal 3.xog andre, der 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-tasked heller.
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-programmer var nye, var det lettere at få dem til at arbejde, da de blev tvinget til at slukke - hvilket måske har brudt nogle gamle 16-bit-programmer.
Det er selvfølgelig alle spekulationer. Hvis du virkelig ønsker at vide, hvorfor MS ikke gennemførte forudgående multitasking i Windows 3.x( 386 forbedret tilstand uanset), skal du spørge nogen, der har arbejdet der.
Jeg ønskede også at rette 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'et 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 nedenfor).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ø, selv om 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 OS 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 den oprindelige tråd og læse den livlige diskussion om dette emne ved at bruge linket nedenfor!
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.
