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 fråga &Svarssession 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 tillstånd 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 startlastare.& Amp;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 ochanvände endast kooperativ multi-tasking - det är den där de inte tvingar ett löpande program att byta ut;De väntar på att det löpande programmet ger 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 planera 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 multi-tasking inte längre.

Windows 3.x Arkitektur

För 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å med att köra instrueras att regelbundet kontrollera en meddelandekö för att få reda på om någonannan ansökan ber om användning av CPU och, om så är fallet, att ge kontroll över den applikationen. Men många Windows 3.1-program skulle kontrollera meddelandekön bara sällan, eller inte alls, och monopolisera kontrollen av CPU: n i 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 ovanpå 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 förbättrad läge delar CPU-tidssnitt mellan de virtuella maskinerna( varav den var normal 3.xoch 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 bitness? Jag frågade om multi-tasking!

Tja, strängt taget är inte bit-ness 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. Men flyttningen 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 lättare att få dem att fungera när de tvingades stängas 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 styr operativsystemet alla hårdvaruresurser, och löpande applikationer hålls i sandlådor. En ansökan är inte tillåten för åtkomst till minne som operativsystemet inte har tilldelat den applikationen, och det kan inte direkt komma åt hårdvaruenheter i datorn. Om hårdvaruåtkomst krävs måste applikationen kommunicera via enhetsdrivrutinerna.

OS kan hantera denna kontroll, eftersom den 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 programmen 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 Operativsystem) 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 länken nedan!

Har 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.