Hoe was multi-tasking mogelijk in oudere versies van Windows?

Gezien het feit dat DOS een besturingssysteem met één taak was en de banden die het had met eerdere versies van Windows, hoe lukte het eerdere versies van Windows om multi-tasking uit te voeren? Het Super & Q & A-bericht van vandaag bekijkt de antwoorden op deze vraag.

De Question & Answer-sessie van vandaag komt tot ons dankzij SuperUser - een onderdeel van Stack Exchange, een gemeenschapsgedreven groep van Q & A-websites.

Windows 95 screenshot met dank aan Wikipedia.

De vraag

SuperUser-lezer LeNoob wil weten hoe oudere versies van Windows konden worden uitgevoerd als multi-tasking-systemen ?:

Ik heb gelezen dat DOS een besturingssysteem met één taak is. Maar als oudere versies van Windows (inclusief Windows 95?) Gewoon wrappers waren voor DOS, hoe konden ze dan worden uitgevoerd als een multi-tasking OS??

Goede vraag! Hoe oudere versies van Windows kunnen worden uitgevoerd als multi-tasking-systemen?

Het antwoord

Bijdragers van SuperUser Bob en Pete hebben het antwoord voor ons. Als eerste, Bob:

Windows 95 was veel meer dan "slechts een dekblad" voor MS-DOS. Quoting Raymond Chen:

• MS-DOS diende twee doelen in Windows 95: 1.) Het diende als de bootloader. & 2.) Het fungeerde als de 16-bits legacy device driver-laag.

Windows 95 heeft feitelijk alle MS-DOS gehackt / overschreven, waardoor het als een compatibiliteitslaag is gebleven terwijl alle zware taken zelf worden uitgevoerd. Het implementeerde ook pre-emptive multi-tasking voor 32-bit programma's.

Pre-Windows 95

Windows 3.x en ouder waren meestal 16-bits (met uitzondering van Win32s, een soort compatibiliteitslaag die 16 en 32 overbrugt, maar we zullen dit hier negeren), waren meer afhankelijk van DOS en gebruikten alleen samenwerkende multi-tasking - dat is degene waar ze een lopend programma niet dwingen om uit te schakelen; ze wachten tot het draaiende programma controle oplevert (eigenlijk, zeg "Ik ben klaar" door het OS te vertellen om het volgende programma uit te voeren dat in de wachtrij staat).

• Multi-tasking was coöperatief, net als in oude versies van MacOS (hoewel in tegenstelling tot Multi-tasking DOS 4.x, die preventieve multi-tasking droeg). Een taak moest het besturingssysteem overgeven om een ​​andere taak te plannen. De opbrengsten waren ingebouwd in bepaalde API-aanroepen, met name de verwerking van berichten. Zolang een taak tijdig berichten verwerkte, was alles geweldig. Als een taak de verwerking van berichten stopte en bezig was met het uitvoeren van een of andere verwerkingslus, was multi-tasking niet meer.

Windows 3.x-architectuur

Over hoe vroege Windows-programma's controle zouden opleveren:

• Windows 3.1 maakt gebruik van coöperatieve multi-tasking - wat betekent dat elke applicatie die wordt uitgevoerd, wordt geïnstrueerd om periodiek een berichtenwachtrij te controleren om te achterhalen of een andere toepassing vraagt ​​om gebruik van de CPU en, zo ja, om controle te geven aan die toepassing. Veel Windows 3.1-applicaties controleren de berichtenwachtrij echter slechts zelden of helemaal niet en monopoliseren de besturing van de CPU zo lang als nodig is. Een preventief multi-tasking-systeem zoals Windows 95 neemt het CPU-beheer weg van een draaiende applicatie en distribueert het naar degenen met een hogere prioriteit op basis van de systeembehoeften.

Bron

Alles wat DOS zou zien is dat deze enkele applicatie (Windows of andere) draait, die controle zou kunnen doorgeven zonder te verlaten. In theorie kan pre-emptive multi-tasking mogelijk toch worden geïmplementeerd bovenop DOS met behulp van een realtime klok en hardware-interrupts om onder dwang controle te geven aan de scheduler. Zoals Tonny opmerkte, werd dit feitelijk gedaan door enkele besturingssystemen die bovenop DOS werden uitgevoerd.

386 Verbeterde modus?

Opmerking: er zijn enkele opmerkingen gemaakt over de 386 enhanced-modus van Windows 3.x die 32-bits is en ondersteuning biedt voor pre-emptive multi-tasking.

Dit is een interessante zaak. Om de gelinkte blogpost samen te vatten, was 386 enhanced mode in feite een 32-bits hypervisor, die virtuele machines draaide. In een van die virtuele machines werd Windows 3.x standaardmodus uitgevoerd, die alle hierboven genoemde dingen doet.

MS-DOS zou ook in die virtuele machines draaien, en blijkbaar hadden ze een pre-emptieve multi-taak - dus het lijkt erop dat de 386 enhanced mode hypervisor CPU-tijdschijven deelt tussen de virtuele machines (waarvan er één normale 3.x draaide en andere die MS-DOS draaien), en elke VM zal zijn eigen ding doen - 3.x zou op meerdere manieren samenwerken, terwijl MS-DOS een taak met één taak zou hebben.

MS-DOS

DOS zelf was single-tasking op papier, maar het had wel ondersteuning voor TSR-programma's die op de achtergrond zouden blijven tot ze werden geactiveerd door een hardware-interrupt. Verre van ware multi-tasking, maar ook niet volledig single-tasked.

Al dat gepraat over bit-heid? Ik vroeg over multi-tasking!

Welnu, strikt genomen zijn de bitness en multi-tasking niet afhankelijk van elkaar. Het zou mogelijk moeten zijn om elke multi-tasking-modus in elke bit-heid te implementeren. De overstap van 16-bits processors naar 32-bits processors introduceerde echter ook andere hardwarefunctionaliteit waardoor pre-emptive multi-tasking eenvoudiger te implementeren was.

Omdat 32-bits programma's nieuw waren, was het ook gemakkelijker om ze aan het werk te krijgen toen ze gedwongen werden uitgeschakeld - wat mogelijk een aantal oudere 16-bit-programma's had verbroken.

Natuurlijk is dit allemaal speculatie. Als je echt wilt weten waarom MS geen pre-emptieve multi-tasking implementeerde in Windows 3.x (ondanks de verbeterde 386-modus), moet je iemand vragen die daar werkte.

Ook wilde ik uw veronderstelling corrigeren dat Windows 95 slechts een dekblad was voor DOS.

Gevolgd door het antwoord van Pete:

In een modern besturingssysteem bestuurt het besturingssysteem alle hardwarebronnen en worden actieve applicaties bewaard in sandboxen. Het is een applicatie niet toegestaan ​​om toegang te krijgen tot het geheugen dat het besturingssysteem niet heeft toegewezen aan die applicatie en het heeft geen directe toegang tot hardwareapparaten op de computer. Als hardwaretoegang vereist is, moet de toepassing communiceren via stuurprogramma's.

Het besturingssysteem kan dit besturingselement afdwingen, omdat het de CPU dwingt de beschermde modus te betreden.

DOS komt echter nooit in de beveiligde modus, maar blijft in de echte modus (*zie hieronder). In de real-modus kunnen de actieve applicaties alles uitvoeren wat het wil, d.w.z. rechtstreeks toegang krijgen tot hardware. Maar een toepassing die in de real-modus wordt uitgevoerd, kan de CPU ook vertellen de beveiligde modus in te gaan.

En in dit laatste deel kunnen toepassingen zoals Windows 95 een omgeving met meerdere threads starten, hoewel ze in principe vanuit DOS zijn gestart.

DOS (Disk Operating System) was, voor zover ik weet, niet veel meer dan een bestandsbeheersysteem. Het bood een bestandssysteem, mechanismen voor het navigeren door het bestandssysteem, een paar hulpmiddelen en de mogelijkheid om applicaties te starten. Het stond ook toe dat sommige applicaties resident bleven, d.w.z. muisstuurprogramma's en EMM-emulators. Maar het heeft niet geprobeerd om de hardware in de computer te besturen zoals een modern besturingssysteem dat doet.

*Toen DOS voor het eerst werd gemaakt in de jaren 1970, bestond de beschermde modus niet in de CPU. Het was pas in de 80286-processor in het midden van de jaren tachtig dat de beschermde modus deel ging uitmaken van de CPU.

Blader door naar de originele discussielijn en lees de levendige discussie over dit onderwerp via de onderstaande link!

Heb je iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk hier de volledige discussiethread.