Waarom zorgde het verplaatsen van de muiscursor ervoor dat Windows 95 sneller ging werken?

Ik was Hypnospace Outlaw aan het spelen, een spel over een retro-thema OS. Dit OS heeft een eigenaardig gedrag dat bij het laden van een webpagina, het bewegen van de muiscursor de pagina sneller zal laden.

Dat deed me ergens aan denken. Toen ik jong was, als ik me goed herinner, had Windows 95(zo niet 98) dit vreemde gedrag dat bij het installeren van programma's, wiebelen met de muiscursor de voortgang versnelde. Wat veroorzaakte dit? Ik heb er naar gegoogled, maar ik kon niets vinden dat er mee te maken had.

Sorry voor de vage uitleg.

Dit is te wijten aan een fout in de manier waarop Windows 95 gebeurtenissen genereert, en het feit dat veel toepassingen gebeurtenisgestuurd zijn.

Windows 95 toepassingen maken vaak gebruik van asynchrone I/O, dat wil zeggen dat ze vragen om een bestandsbewerking, zoals kopiëren, uit te voeren en dan het OS vertellen dat ze in slaapstand kunnen worden gezet totdat die bewerking is voltooid. Door te slapen stellen zij andere toepassingen in staat om te draaien, in plaats van eindeloos CPU-tijd te verspillen met de vraag of de bestandsbewerking al is voltooid.

Om redenen die niet geheel duidelijk zijn, maar waarschijnlijk te wijten zijn aan prestatieproblemen op machines in het lagere segment, heeft Windows 95 de neiging de berichten over I/O-voltooiing te bundelen en de toepassing niet onmiddellijk wakker te maken om ze te bedienen. Het wekt echter wel de toepassing voor gebruikersinvoer, vermoedelijk om het responsief te houden, en wanneer de toepassing wakker is zal het ook alle hangende I/O-berichten afhandelen.

Dus wiebelen met de muis zorgt ervoor dat de applicatie I/O berichten sneller verwerkt, en sneller installeert. Het effect was vrij uitgesproken; grote toepassingen die een uur nodig hadden om te installeren, konden met de juiste muisinvoer worden teruggebracht tot 15 minuten.

Commentaren (16)

Ja, het's een echt effect dat een meetbare versnelling veroorzaakt en naar believen kan worden gereproduceerd:

Probeer een groot bestand te openen met Notepad op een hedendaagse machine. Het venster mag niet volledig scherm zijn. Markeer na het laden alle tekst met de muis (het toetsenbord werkt ook, het vereist alleen meer handigheid). Terwijl u de knop ingedrukt houdt (en markeert) beweegt u de muis omlaag, zodat de tekst gemarkeerd en gescrolld wordt. Vergelijk nu de scrollsnelheid terwijl u de muis stilhoudt versus terwijl u de muis beweegt. Afhankelijk van je machine kan de snelheid verschillende keren hoger liggen.

Verbazingwekkend, is het niet?

Het kan ook in veel andere programma's worden bekeken, Notepad is slechts een gemakkelijk te reproduceren voorbeeld. Het'heeft te maken met de manier waarop multitasking werkte in vroege versies van Windows. Hier draaide alles om de berichtenwachtrij. Wiebelen met de muis resulteerde in een stortvloed van muis-bewegingsberichten, die er op hun beurt voor zorgden dat programma's vaker wakker werden en (afhankelijk van hun structuur) telkens hun toestand bijwerkten, weer in de berichten-lus gingen, tijd gaven aan scherm-updates, resulterend in een over het geheel genomen snellere reactie. Het laat een glimp zien van de manieren die MS gebruikte om Windows nogal responsief te maken ondanks zijn coöperatieve threaded aard.

Commentaren (18)

Windows pre-NT (Windows 1,2,3,3.11,95,98) was coöperatief multitasking vs NT's (2000, XP, Vista, 7 & 10) preemptive multitasking.

Bij coöperatieve multitasking moet de voorgrond-applicatie controle afstaan aan andere taken. Dus als de voorgrond toepassing vast kwam te zitten, bevroor de hele machine.

Bij preemptive multitasking had het systeem meestal een hardware interrupt, meestal een timer, om het opgeven te forceren.

Op Windows 95 genereerden het toetsenbord en de muis interrupts, het bewegen van de muis veroorzaakte dat de interrupt afging en het OS zijn event queue ging bedienen. Een vorm van preemptive multitasking, in plaats van een vaste timer interrupt, deed jij het.

Het OS zou de status op het scherm bijwerken bij de interrupt en dan de andere taken gaan bedienen. De scherm update zou het laten lijken dat het OS sneller aan het verwerken was.

EDIT - 1/2 rechts ... Kan Win16 toepassingen niet pre-emptief multitasken omdat het hetzelfde System Virtual Machine (VM) model gebruikt als in Windows 3.1 om Win16 toepassingen uit te voeren. Windows 95 keert dus terug naar een coöperatieve multitasking-omgeving wanneer Win16-toepassingen worden uitgevoerd en geeft deze de exclusieve controle over de CPU zolang de toepassingen worden uitgevoerd. Dientengevolge is echte preventieve werking onmogelijk bij het multitasken van een combinatie van Win16- en Win32-toepassingen.

Commentaren (5)