Hur var Multi-Tasking Possible i äldre versioner av Windows?

Med tanke på att DOS var ett operativsystem med enkel uppgift och de band som den hade med tidiga versioner av Windows, hur lyckades tidigare versioner av Windows med att utföra multi-tasking? Dagens SuperUser Q & A-inlägg tittar på svaren på den här frågan.

Dagens Question & Answer-session kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

Windows 95 skärmdump med vänlighet av Wikipedia.

Frågan

SuperUser-läsare LeNoob vill veta hur äldre versioner av Windows kunde köra som multi-tasking-system ?:

Jag läste att DOS är ett operativsystem med enkel uppgift. Men om äldre versioner av Windows (inklusive Windows 95?) Bara var wrappers för DOS, hur kunde de köras som ett multi-tasking OS?

Bra fråga! Hur lyckades äldre versioner av Windows köra som multi-tasking-system?

Svaret

SuperUser-bidragsgivare Bob och Pete har svaret för oss. Först upp, Bob:

Windows 95 var långt mer än "bara ett omslag" för MS-DOS. Citat Raymond Chen:

• MS-DOS serverade två syften i Windows 95: 1.) Det fungerade som startläsare. & 2.) Det fungerade som 16-bitars äldre enhetsdrivrutinslagret.

Windows 95 hakade / överrättade nästan alla MS-DOS, och behöll det som ett kompatibilitetslager samtidigt som man gjorde allt tungt lyfta sig själv. Det genomförde också förebyggande multi-tasking för 32-bitars program.

Pre-Windows 95

Windows 3.x och äldre var mestadels 16-bitars (med undantag för Win32s, ett slags kompatibilitetslager som överbryggar 16 och 32, men vi kommer att ignorera det här), var mer beroende av DOS och använde endast kooperativ multi-tasking - det är det där de inte tvingar ett löpande program att byta ut; de väntar på att programmet körs för att ge kontroll (i princip säger "Jag är klar" genom att berätta för OS att köra nästa program som väntar).

• Multi-tasking var kooperativ, precis som i gamla versioner av MacOS (men i motsats till Multi-tasking DOS 4.x, som sportade förebyggande multi-tasking). En uppgift hade att ge till operativsystemet för att kunna schemalägga en annan uppgift. Utbytena byggdes in i vissa API-samtal, särskilt meddelandebehandling. Så länge en uppgift behandlade meddelanden i tid, var allt bra. Om en uppgift slutade att behandla meddelanden och var upptagen med att utföra en bearbetningsslinga, var inte multi-tasking längre.

Windows 3.x Arkitektur

När det gäller hur tidigt Windows-program skulle ge kontroll:

• Windows 3.1 använder kooperativ multi-tasking - vilket innebär att varje applikation som håller på att köras instrueras att regelbundet kontrollera en meddelandekön för att ta reda på om någon annan applikation begär användning av CPU och i så fall ge kontroll till den ansökan. Men många Windows 3.1-program skulle kontrollera meddelandekön bara sällan, eller inte alls, och monopolisera kontrollen av CPU-enheten så mycket tid som de krävde. Ett förebyggande multi-tasking-system som Windows 95 tar CPU-kontroll bort från en pågående applikation och distribuerar den till de som har högre prioritet baserat på systemets behov.

Källa

Alla DOS skulle se är den här enstaka applikationen (Windows eller andra) som körs, vilket skulle ge kontrollen utan att gå ut. I teorin kan förebyggande multi-tasking eventuellt implementeras på toppen av DOS i alla fall med hjälp av en realtids klocka och hårdvaruavbrott för att tvinga ge kontroll till schemaläggaren. Som Tonny kommenterar, så gjordes det faktiskt av vissa operativsystem som körde ovanpå DOS.

386 Förbättrat läge?

Obs! Det har förekommit några kommentarer om 386 förbättrat läge för Windows 3.x som är 32-bitars, och stödjer förebyggande multi-tasking.

Detta är ett intressant fall. För att sammanfatta det länkade bloggposten var 386 förbättrat läge i grunden en 32-bitars hypervisor, som körde virtuella maskiner. Inuti en av dessa virtuella maskiner körde Windows 3.x standardläge, vilket gör alla saker som anges ovan.

MS-DOS skulle också köras inuti de virtuella maskinerna, och uppenbarligen var de förebyggande multi-tasked - så det verkar som att hypotesen 386 med förbättrad läge kommer att dela CPU-tidssnitt mellan de virtuella maskinerna (varav den var normal 3.x och andra som körde MS-DOS), och varje VM kommer att göra sin egen sak - 3.x skulle fungera gemensamt med flera uppdrag, medan MS-DOS skulle vara enstaka.

MS-DOS

DOS själv var enstaka uppgift på papper, men det hade stöd för TSR-program som skulle ligga kvar i bakgrunden tills det utlöstes av ett hårdvaruproblem. Långt från sant multi-tasking, men inte helt enkelt uppgift.

Allt detta tal om bit-ness? Jag frågade om multi-tasking!

Tja, strängt taget är inte bitness och multi-tasking beroende av varandra. Det borde vara möjligt att implementera något multi-tasking-läge i vilken bit-ness som helst. Förflyttningen från 16-bitars processorer till 32-bitars processorer introducerade också annan hårdvarufunktionalitet som kunde ha gjort förebyggande multi-tasking lättare att implementera.

Eftersom 32-bitarsprogrammen var nya, var det också lättare att få dem att fungera när de tvingades tvingas ut - vilket kan ha brutit några äldre 16-bitars program.

Det här är givetvis allt spekulationer. Om du verkligen vill veta varför MS inte genomförde förebyggande multi-tasking i Windows 3.x (trots 386 förbättrat läge), måste du fråga någon som arbetade där.

Jag ville också korrigera ditt antagande om att Windows 95 bara var ett omslag för DOS.

Följd av svaret från Pete:

I ett modernt operativsystem kontrollerar operativsystemet alla hårdvara resurser, och löpande applikationer hålls i sandlådor. En applikation är inte tillåten att få åtkomst till minne som operativsystemet inte har tilldelat till den applikationen, och det kan inte direkt komma åt maskinvaruenheter i datorn. Om hårdvaruåtkomst krävs måste applikationen kommunicera via enhetsdrivrutinerna.

Operativsystemet kan genomföra denna kontroll, eftersom det tvingar CPU: n att gå in i skyddat läge.

DOS å andra sidan går aldrig in i skyddat läge, men stannar i realt läge (*se nedan). I verkligt läge kan de löpande applikationerna utföra allt som helst, det vill säga tillgång till maskinvara direkt. Men en applikation som körs i realt läge kan också berätta för CPU: n att gå in i skyddat läge.

Och den här sista delen tillåter applikationer som Windows 95 att starta en tråd med flera trådar trots att de ursprungligen lanserades från DOS.

DOS (Disk Operating System) var, så vitt jag vet, inte mycket mer än ett filhanteringssystem. Det tillhandahöll ett filsystem, mekanismer för navigering i filsystemet, några verktyg och möjligheten att starta applikationer. Det möjliggjorde också vissa applikationer att stanna bosatta, dvs musförare och EMM-emulatorer. Men det försökte inte kontrollera hårdvaran i datorn som ett modernt operativsystem gör.

*När DOS skapades första gången på 1970-talet fanns det skyddade läget inte i CPU. Det var inte förrän 80286-processorn i mitten av 1980-talet som skyddade läget blev en del av processorn.

Se till att bläddra vidare till den ursprungliga tråden och läs igenom den livliga diskussionen om det här ämnet med hjälp av länken nedan!

Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.