Why did moving the mouse cursor cause Windows 95 to run more quickly?Why bootable game disks were never a thing on IBM PC?Why can't VirtualBox install drivers for windows 95B?Can I run Windows 98 and games from the same era on an AMD Duron CPU?Xerox Parc and the three-button mouseSubmarine diver game where you had to collect fish and other things for your aquariumWindows 98 SE installation “hangs”How did Windows 95 verify the Certificate of Authenticity?How to use USB flash drives with Windows 98 SE?What did Microsoft customize on Windows 95 installation floppy disks?Why did Windows pick 260 characters as the maximum path length?Logitech drivers from Windows 95 Installer on the actual disk

What are the indigenous English words for a prostitute?

Found and corrected a mistake on someone's else paper -- praxis?

How quality assurance engineers test calculations?

Chorophyll and photosynthesis in plants with coloured leaves

Reverse dots and boxes

What's it called when the bad guy gets eaten?

Credit score and financing new car

Using Open with a filename that contains :

How often does the spell Sleet Storm require concentration checks?

When an electron changes its spin, or any other intrinsic property, is it still the same electron?

How to drill holes in 3/8" steel plates?

"was fiction" vs "were fictions"

Why is a mixture of two normally distributed variables only bimodal if their means differ by at least two times the common standard deviation?

What are some further readings in Econometrics you recommend?

When did "&" stop being taught alongside the alphabet?

Does a wizard need their hands free in order to cause their familiar from the Find Familiar spell to reappear?

What is the right approach to quit a job during probation period for a competing offer?

What is /bin/red

The rigidity of the countable product of free groups

Are there any sports for which the world's best player is female?

Backspace functionality in normal mode

Why do we need common sense in AI?

[Future]Historical experience as a guide to warship design?

Elf (adjective) vs. Elvish vs. Elven



Why did moving the mouse cursor cause Windows 95 to run more quickly?


Why bootable game disks were never a thing on IBM PC?Why can't VirtualBox install drivers for windows 95B?Can I run Windows 98 and games from the same era on an AMD Duron CPU?Xerox Parc and the three-button mouseSubmarine diver game where you had to collect fish and other things for your aquariumWindows 98 SE installation “hangs”How did Windows 95 verify the Certificate of Authenticity?How to use USB flash drives with Windows 98 SE?What did Microsoft customize on Windows 95 installation floppy disks?Why did Windows pick 260 characters as the maximum path length?Logitech drivers from Windows 95 Installer on the actual disk






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








360















I was playing Hypnospace Outlaw, a game about a retro-themed OS. This OS has a peculiar behavior that when loading a webpage, wiggling the mouse cursor will load the page faster.



That reminded me of something. When I was young, if I remember correctly, Windows 95(if not 98) had this weird behavior that when installing programs, wiggling the mouse cursor make the progress faster. What caused this? I googled for it, I couldn't find anything related.



Sorry for the vague explanation.










share|improve this question



















  • 26





    It's probably just perceptual, moving the mouse would for sure trigger more screen updates and look smoother than when not moving it.

    – Aybe
    Jul 1 at 7:26






  • 2





    @Aybe You might be right.

    – user2652379
    Jul 1 at 7:50






  • 58





    I remember somebody joking that it would cause the sand to fall faster in the hourglass icon, thereby speeding up the process.

    – Fred Larson
    Jul 1 at 16:26






  • 7





    A partial answer to supplement what is below: waiting threads get a priority boost when they wake up. Threads with a UI event get a larger boost than those which just have I/O events. I don't have any confirmation that this is the cause of the behavior you describe, but it does lend creedence to many of the answers below.

    – Cort Ammon
    Jul 1 at 19:39






  • 1





    this...this was sort of an urban myth when I was a kid back in nineties - and it turns out it's not a myth at all!

    – shabunc
    Jul 4 at 9:02

















360















I was playing Hypnospace Outlaw, a game about a retro-themed OS. This OS has a peculiar behavior that when loading a webpage, wiggling the mouse cursor will load the page faster.



That reminded me of something. When I was young, if I remember correctly, Windows 95(if not 98) had this weird behavior that when installing programs, wiggling the mouse cursor make the progress faster. What caused this? I googled for it, I couldn't find anything related.



Sorry for the vague explanation.










share|improve this question



















  • 26





    It's probably just perceptual, moving the mouse would for sure trigger more screen updates and look smoother than when not moving it.

    – Aybe
    Jul 1 at 7:26






  • 2





    @Aybe You might be right.

    – user2652379
    Jul 1 at 7:50






  • 58





    I remember somebody joking that it would cause the sand to fall faster in the hourglass icon, thereby speeding up the process.

    – Fred Larson
    Jul 1 at 16:26






  • 7





    A partial answer to supplement what is below: waiting threads get a priority boost when they wake up. Threads with a UI event get a larger boost than those which just have I/O events. I don't have any confirmation that this is the cause of the behavior you describe, but it does lend creedence to many of the answers below.

    – Cort Ammon
    Jul 1 at 19:39






  • 1





    this...this was sort of an urban myth when I was a kid back in nineties - and it turns out it's not a myth at all!

    – shabunc
    Jul 4 at 9:02













360












360








360


109






I was playing Hypnospace Outlaw, a game about a retro-themed OS. This OS has a peculiar behavior that when loading a webpage, wiggling the mouse cursor will load the page faster.



That reminded me of something. When I was young, if I remember correctly, Windows 95(if not 98) had this weird behavior that when installing programs, wiggling the mouse cursor make the progress faster. What caused this? I googled for it, I couldn't find anything related.



Sorry for the vague explanation.










share|improve this question
















I was playing Hypnospace Outlaw, a game about a retro-themed OS. This OS has a peculiar behavior that when loading a webpage, wiggling the mouse cursor will load the page faster.



That reminded me of something. When I was young, if I remember correctly, Windows 95(if not 98) had this weird behavior that when installing programs, wiggling the mouse cursor make the progress faster. What caused this? I googled for it, I couldn't find anything related.



Sorry for the vague explanation.







windows-98 windows-95 mouse






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jul 1 at 10:58









Alan B

6533 silver badges9 bronze badges




6533 silver badges9 bronze badges










asked Jul 1 at 6:45









user2652379user2652379

1,0463 gold badges3 silver badges6 bronze badges




1,0463 gold badges3 silver badges6 bronze badges







  • 26





    It's probably just perceptual, moving the mouse would for sure trigger more screen updates and look smoother than when not moving it.

    – Aybe
    Jul 1 at 7:26






  • 2





    @Aybe You might be right.

    – user2652379
    Jul 1 at 7:50






  • 58





    I remember somebody joking that it would cause the sand to fall faster in the hourglass icon, thereby speeding up the process.

    – Fred Larson
    Jul 1 at 16:26






  • 7





    A partial answer to supplement what is below: waiting threads get a priority boost when they wake up. Threads with a UI event get a larger boost than those which just have I/O events. I don't have any confirmation that this is the cause of the behavior you describe, but it does lend creedence to many of the answers below.

    – Cort Ammon
    Jul 1 at 19:39






  • 1





    this...this was sort of an urban myth when I was a kid back in nineties - and it turns out it's not a myth at all!

    – shabunc
    Jul 4 at 9:02












  • 26





    It's probably just perceptual, moving the mouse would for sure trigger more screen updates and look smoother than when not moving it.

    – Aybe
    Jul 1 at 7:26






  • 2





    @Aybe You might be right.

    – user2652379
    Jul 1 at 7:50






  • 58





    I remember somebody joking that it would cause the sand to fall faster in the hourglass icon, thereby speeding up the process.

    – Fred Larson
    Jul 1 at 16:26






  • 7





    A partial answer to supplement what is below: waiting threads get a priority boost when they wake up. Threads with a UI event get a larger boost than those which just have I/O events. I don't have any confirmation that this is the cause of the behavior you describe, but it does lend creedence to many of the answers below.

    – Cort Ammon
    Jul 1 at 19:39






  • 1





    this...this was sort of an urban myth when I was a kid back in nineties - and it turns out it's not a myth at all!

    – shabunc
    Jul 4 at 9:02







26




26





It's probably just perceptual, moving the mouse would for sure trigger more screen updates and look smoother than when not moving it.

– Aybe
Jul 1 at 7:26





It's probably just perceptual, moving the mouse would for sure trigger more screen updates and look smoother than when not moving it.

– Aybe
Jul 1 at 7:26




2




2





@Aybe You might be right.

– user2652379
Jul 1 at 7:50





@Aybe You might be right.

– user2652379
Jul 1 at 7:50




58




58





I remember somebody joking that it would cause the sand to fall faster in the hourglass icon, thereby speeding up the process.

– Fred Larson
Jul 1 at 16:26





I remember somebody joking that it would cause the sand to fall faster in the hourglass icon, thereby speeding up the process.

– Fred Larson
Jul 1 at 16:26




7




7





A partial answer to supplement what is below: waiting threads get a priority boost when they wake up. Threads with a UI event get a larger boost than those which just have I/O events. I don't have any confirmation that this is the cause of the behavior you describe, but it does lend creedence to many of the answers below.

– Cort Ammon
Jul 1 at 19:39





A partial answer to supplement what is below: waiting threads get a priority boost when they wake up. Threads with a UI event get a larger boost than those which just have I/O events. I don't have any confirmation that this is the cause of the behavior you describe, but it does lend creedence to many of the answers below.

– Cort Ammon
Jul 1 at 19:39




1




1





this...this was sort of an urban myth when I was a kid back in nineties - and it turns out it's not a myth at all!

– shabunc
Jul 4 at 9:02





this...this was sort of an urban myth when I was a kid back in nineties - and it turns out it's not a myth at all!

– shabunc
Jul 4 at 9:02










8 Answers
8






active

oldest

votes


















420














This is because of a flaw in the way Windows 95 generates events, and the fact that many applications are event driven.



Windows 95 applications often use asynchronous I/O, that is they ask for some file operation like a copy to be performed and then tell the OS that they can be put to sleep until that operation finishes. By sleeping they allow other applications to run, rather than wasting CPU time endlessly asking if the file operation has completed yet.



For reasons that are not entirely clear, but probably due to performance problems on low end machines, Windows 95 tends to bundle up the messages about I/O completion and doesn't immediately wake up the application to service them. However, it does wake the application for user input, presumably to keep it feeling responsive, and when the application is awake it will handle any pending I/O messages too.



Thus wiggling the mouse causes the application to process I/O messages faster, and install quicker. The effect was quite pronounced; large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input.






share|improve this answer




















  • 45





    @user2652379 Windows 10 seems to be better tuned for modern hardware, so it doesn't queue up I/O events in the same way. Therefore there is usually no benefit to applications. Also, many applications do I/O on a separate thread now anyway, so the user input events don't even reach the part handling file stuff.

    – user
    Jul 1 at 10:18






  • 109





    Could you provide a source for this information so I can dig deeper? If true, I owe some baby boomers apologies for things I said about 20 years ago.

    – user1717828
    Jul 1 at 16:52






  • 26





    Raymond Chen explains a similar bug: devblogs.microsoft.com/oldnewthing/?p=36423

    – snips-n-snails
    Jul 1 at 22:23






  • 6





    @IanRingrose: That's because NT had the original implementation of Async I/O, I assume from its VMS heritage. And there it's not tied to the event loop (message pump). Async I/O was a retrofit on Windows 95.

    – MSalters
    Jul 2 at 7:17






  • 13





    @user2652379 No, Windows 10 is an NT-based system (as was every Windows version since XP). NT never had this issue. Windows 95 had to deal with substantially less powerful hardware than NT, and had different approaches to handling compatibility with older versions of Windows and DOS. And even if it wasn't, Windows 10 has so many changes to the way both IO and UI messaging is handled that it would be quite unlikely this feature would still exist today. It should also be noted that the problem only happens when you're copying a large number of files, which many applications try to avoid anyway.

    – Luaan
    Jul 2 at 8:04


















90














Yes, it's a real effect resulting in causing a measurable speed up and can be reproduced at will:



Try opening a large file with Notepad on a contemporary machine. The window must not be full screen. When loaded, mark all text using the mouse (the keyboard works as well, it just needs more manual skill). While still holding the button down (and marking) move the mouse down, so the text gets marked and scrolled. Now compare the scroll speed while holding the mouse still versus wiggling it. Depending on your machine the speed up can be several times faster.



Amazing, isn't it?



It can be viewed in many other programs as well, Notepad is just an easy to reproduce example. It's related to the way multitasking worked in early versions of Windows. Here everything revolved around the message queue. Wiggling the mouse resulted in a flood of mouse-move messages, which in turn made programs wake up more often and (depending on their structure) updating their states each time, going into the message loop again, giving time to screen updates, resulting in an over all faster reaction. It shows a glimpse of the ways MS used to make Windows rather responsive despite its cooperative threaded nature.






share|improve this answer




















  • 11





    Windows 95 had pre-emptive multi tasking and threading. However, Microsoft spent a lot of effort making the event handling completely deterministic as it was in Windows 3.x and also the GDI (which was 95% the same as the Win 3.x GDI) was protected by a global lock so only one process could be in it at a time. I guess the issue was a weird emergent effect of that.

    – JeremyP
    Jul 1 at 9:50






  • 58





    Wow, this is so ingrained in me that I never really noticed that I reflexively wiggle my mouse when selecting a big chunk of text, and have been doing so for decades.

    – Nuclear Wang
    Jul 1 at 15:13






  • 59





    I thought it was just an OS feature - if you want slow scrolling in case you don't want to select too much, just move the mouse down; but if you want fast scrolling to select a lot of text, then move the mouse down while also moving it side to side.

    – pacoverflow
    Jul 1 at 18:35






  • 9





    This does sound like a UI- / usability feature, not like it has an effect on "running speed" of the application. Granted, it is an example of something moving faster while moving the mouse. I'm not sure it exactly answers the question, though.

    – Kakturus
    Jul 2 at 12:03







  • 7





    No this is wrong. This effect has nothing to do with performance, it has to do with handling WM_MOUSEMOVE and WM_TIMER in the message dispatch and the timer*increment being smaller than a hose of mouse moves.

    – Eric
    Jul 3 at 20:29


















33














It wasn't just Windows 95, but Windows 3.x as well, even though they work very differently.



Other answers talk about pre-emptive multitasking, so let's first clarify this:



Window 3.x was using cooperative multitasking where each app would release the cpu for the other apps to use it. Windows 95 uses pre-emptive multitasking where each app is allocated a time slice.



The answer is linked to how the graphic interface works: in a windows graphical app, there is a loop called the 'message pump':



Every event (mouse moved, window got resized, etc) is pushed into a queue. The app is responsible to check if it has messages waiting and, if yes, pull them and process them.



This is at this moment that Windows 3.x was switching to other apps since there was a single point where all apps where going to, but this doesn't apply to windows 95.



What really happens is that, on both OS, you need to process the message loop, but if you want to update something in the background, like a task, a display update, etc, you'd set a timer and the timer would put a message in the queue at a regular interval.



These were better ways to do things on Windows 95, but developers took time to transition from Windows 3.x and many apps were structured the same.



Since the main mechanism was to rely only on the message loop and background operations were done through timer messages, moving the mouse would trigger a lot of messages, move the app up in priority, wake the app up, and get the app to process the background tasks messages. Without moving the mouse, the timer messages would be read up only at a rather slow interval.



The most famous app for this was the disk defragmenter where operations would wait for a message to update the graphic interface! so shaking the mouse would speed up the defrag.






share|improve this answer























  • Was it just the UI that did not update in the "disk defragmenter", I think at least on NT, it did the real work in a different thread.

    – Ian Ringrose
    Jul 1 at 23:14






  • 3





    the disk defragmenter was doing work in chunk and the main loop was pulling messages checking what blocks were done, update the ui and trigger another block; they implemented the '95 defragmenter with a win 3.x structure because it took a while for people to do things differently. NT was a very different animal altogether at the time; if I remember NT and OS/2 were quite similar in a few points and microsoft really saw a 'home' line and a 'business' line.

    – Thomas
    Jul 2 at 10:11


















18














The reason is because of how WM_TIMER is limited to 15.6ms intervals by default. If you call SetTimer() with a 1ms interval it will still be called in 15.6ms intervals. WM_TIMER drives a lot of stuff in Win32 applications like network packet processing and such.



Moving the mouse causes WM_TIMER events to fire more often on Win95. So some applications will seem to run faster.



The 15.6ms value was set for various reasons: Not clogging up the event queue so that stuff like WM_PAINT would still dispatch often enough and more recently and importantly to save power. There are tons of articles talking about this:



https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/






share|improve this answer










New contributor



Tinic Uro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 1





    Do you have a source, or some sort of evidence, for the claim that "moving the mouse causes WM_TIMER events to fire more often"? I can't think of an intuitive reason why, given my knowledge of the design of Windows' message loops, so that would have to be a Windows 95-specific bug. The message loop dispatches SendMessage-generated messages in order, then PostMessage-generated messages in order, and, finally, synthesizes WM_TIMER, WM_PAINT, and/or WM_MOUSEMOVE messages, as needed.

    – Cody Gray
    Jul 4 at 4:43


















10














Raymond Chen from Microsoft has a great answer on his blog:




One danger of the MsgWaitForMultipleObjects function
is calling it when there are already messages waiting
to be processed, because MsgWaitForMultipleObjects
returns only when there is a new event in the queue.




His blog is a great read!






share|improve this answer










New contributor



rwbaskette is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.



















  • This is a great post...Raymond specifically mentions moving the mouse, showing an example where “Sometimes my program gets stuck and reports one fewer record than it should. I have to jiggle the mouse to get the value to update.”

    – Martin Burch
    yesterday


















9














Arguably, this is a common bug in early software based on an event-processing loop rather than a Windows bug: if some DD-paths of the loop only process a single event, then every time when two events are generated simultaneously, only one is processed and the other gets stuck. Moving the mouse generates more incoming events and restarts the loop. "Mouse move" events are typically processed by a GUI library, which handles them correctly (that is, processing all such events in the queue), so those events help get the loop going, and then disappear harmlessly.



Such bugs are easily missed when the testing is done by hand, since the act of testing itself generates enough input events to keep the bug hidden.






share|improve this answer




















  • 1





    Yours is the only answer I upvoted because it seems plausible to me that this issue is a misuse of the Windows SDK rather than a problem in Windows itself. Microsoft's Raymond Chen explains the bug more fully here: devblogs.microsoft.com/oldnewthing/?p=36423

    – snips-n-snails
    Jul 3 at 20:53


















1














Quick answer, by moving the cursor you were telling windows that you are the most important event running. When you stop interacting windows gives priority to other events. So installing programs even when in foreground would give priority to less important events. This bug is no longer present in current Windows versions.






share|improve this answer








New contributor



karmafunk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.


























    -3














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



    On cooperative multitasking, the foreground app has to yield control to other tasks. Thus if the foreground app got stuck, the whole machine froze.



    Preemptive multitasking, the system usually had a hardware interrupt, usually a timer, to force a yield.



    On Windows 95, the keyboard and mouse generated interrupts, moving the mouse caused the interrupt to fire and the OS to service it's event queue. A form of preemptive multitasking, instead of a fixed timer interrupt, you were doing it.



    The OS would update the status on screen at the interrupt and then go service the other tasks. The screen update would make it seem that the OS was processing faster.



    EDIT - 1/2 right ...
    Cannot pre-emptively multitask Win16 applications because it uses the same System Virtual Machine (VM) model as in Windows 3.1 to run Win16 applications. Thus, Windows 95 will revert to a cooperative multitasking environment when running Win16 applications and give them exclusive control of the CPU for as long as the applications are executing. As a result, true pre-emptive operation is impossible when multitasking a mixture of Win16 and Win32 applications.






    share|improve this answer




















    • 14





      Windows 95 is pre-emptive multitasking. It was, in fact, one of the major design goals of Windows 95.

      – user
      Jul 1 at 10:19











    • WIN95 from Packard Bell was awesome in all the featured apps they included . THey also used low DPI ball mice back in those days that needed more smoothing.= from averaging. Now laser mice are much higher DPI and can wake up my WIn7 just by tingle vibration on the couch or table with mouse.

      – Sunnyskyguy EE75
      Jul 1 at 20:31











    • @SunnyskyguyEE75 Funnily enough most wireless mice sidestep that issue because they themselves go to sleep and require significant movement to wake up.

      – Bob
      Jul 3 at 2:24











    • Not mine @Bob As soon as I sit on the couch with mouse at the end not moving, big screen TV turns on which is connected to computer, as it comes out of sleep mode, instantly. M185 LOgitech That doesn't even move the cursor when it's awake.1 AA cell, going on 1 year now., and it is used many hours daily.

      – Sunnyskyguy EE75
      Jul 3 at 2:40












    protected by Community Jul 4 at 15:22



    Thank you for your interest in this question.
    Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



    Would you like to answer one of these unanswered questions instead?














    8 Answers
    8






    active

    oldest

    votes








    8 Answers
    8






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    420














    This is because of a flaw in the way Windows 95 generates events, and the fact that many applications are event driven.



    Windows 95 applications often use asynchronous I/O, that is they ask for some file operation like a copy to be performed and then tell the OS that they can be put to sleep until that operation finishes. By sleeping they allow other applications to run, rather than wasting CPU time endlessly asking if the file operation has completed yet.



    For reasons that are not entirely clear, but probably due to performance problems on low end machines, Windows 95 tends to bundle up the messages about I/O completion and doesn't immediately wake up the application to service them. However, it does wake the application for user input, presumably to keep it feeling responsive, and when the application is awake it will handle any pending I/O messages too.



    Thus wiggling the mouse causes the application to process I/O messages faster, and install quicker. The effect was quite pronounced; large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input.






    share|improve this answer




















    • 45





      @user2652379 Windows 10 seems to be better tuned for modern hardware, so it doesn't queue up I/O events in the same way. Therefore there is usually no benefit to applications. Also, many applications do I/O on a separate thread now anyway, so the user input events don't even reach the part handling file stuff.

      – user
      Jul 1 at 10:18






    • 109





      Could you provide a source for this information so I can dig deeper? If true, I owe some baby boomers apologies for things I said about 20 years ago.

      – user1717828
      Jul 1 at 16:52






    • 26





      Raymond Chen explains a similar bug: devblogs.microsoft.com/oldnewthing/?p=36423

      – snips-n-snails
      Jul 1 at 22:23






    • 6





      @IanRingrose: That's because NT had the original implementation of Async I/O, I assume from its VMS heritage. And there it's not tied to the event loop (message pump). Async I/O was a retrofit on Windows 95.

      – MSalters
      Jul 2 at 7:17






    • 13





      @user2652379 No, Windows 10 is an NT-based system (as was every Windows version since XP). NT never had this issue. Windows 95 had to deal with substantially less powerful hardware than NT, and had different approaches to handling compatibility with older versions of Windows and DOS. And even if it wasn't, Windows 10 has so many changes to the way both IO and UI messaging is handled that it would be quite unlikely this feature would still exist today. It should also be noted that the problem only happens when you're copying a large number of files, which many applications try to avoid anyway.

      – Luaan
      Jul 2 at 8:04















    420














    This is because of a flaw in the way Windows 95 generates events, and the fact that many applications are event driven.



    Windows 95 applications often use asynchronous I/O, that is they ask for some file operation like a copy to be performed and then tell the OS that they can be put to sleep until that operation finishes. By sleeping they allow other applications to run, rather than wasting CPU time endlessly asking if the file operation has completed yet.



    For reasons that are not entirely clear, but probably due to performance problems on low end machines, Windows 95 tends to bundle up the messages about I/O completion and doesn't immediately wake up the application to service them. However, it does wake the application for user input, presumably to keep it feeling responsive, and when the application is awake it will handle any pending I/O messages too.



    Thus wiggling the mouse causes the application to process I/O messages faster, and install quicker. The effect was quite pronounced; large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input.






    share|improve this answer




















    • 45





      @user2652379 Windows 10 seems to be better tuned for modern hardware, so it doesn't queue up I/O events in the same way. Therefore there is usually no benefit to applications. Also, many applications do I/O on a separate thread now anyway, so the user input events don't even reach the part handling file stuff.

      – user
      Jul 1 at 10:18






    • 109





      Could you provide a source for this information so I can dig deeper? If true, I owe some baby boomers apologies for things I said about 20 years ago.

      – user1717828
      Jul 1 at 16:52






    • 26





      Raymond Chen explains a similar bug: devblogs.microsoft.com/oldnewthing/?p=36423

      – snips-n-snails
      Jul 1 at 22:23






    • 6





      @IanRingrose: That's because NT had the original implementation of Async I/O, I assume from its VMS heritage. And there it's not tied to the event loop (message pump). Async I/O was a retrofit on Windows 95.

      – MSalters
      Jul 2 at 7:17






    • 13





      @user2652379 No, Windows 10 is an NT-based system (as was every Windows version since XP). NT never had this issue. Windows 95 had to deal with substantially less powerful hardware than NT, and had different approaches to handling compatibility with older versions of Windows and DOS. And even if it wasn't, Windows 10 has so many changes to the way both IO and UI messaging is handled that it would be quite unlikely this feature would still exist today. It should also be noted that the problem only happens when you're copying a large number of files, which many applications try to avoid anyway.

      – Luaan
      Jul 2 at 8:04













    420












    420








    420







    This is because of a flaw in the way Windows 95 generates events, and the fact that many applications are event driven.



    Windows 95 applications often use asynchronous I/O, that is they ask for some file operation like a copy to be performed and then tell the OS that they can be put to sleep until that operation finishes. By sleeping they allow other applications to run, rather than wasting CPU time endlessly asking if the file operation has completed yet.



    For reasons that are not entirely clear, but probably due to performance problems on low end machines, Windows 95 tends to bundle up the messages about I/O completion and doesn't immediately wake up the application to service them. However, it does wake the application for user input, presumably to keep it feeling responsive, and when the application is awake it will handle any pending I/O messages too.



    Thus wiggling the mouse causes the application to process I/O messages faster, and install quicker. The effect was quite pronounced; large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input.






    share|improve this answer















    This is because of a flaw in the way Windows 95 generates events, and the fact that many applications are event driven.



    Windows 95 applications often use asynchronous I/O, that is they ask for some file operation like a copy to be performed and then tell the OS that they can be put to sleep until that operation finishes. By sleeping they allow other applications to run, rather than wasting CPU time endlessly asking if the file operation has completed yet.



    For reasons that are not entirely clear, but probably due to performance problems on low end machines, Windows 95 tends to bundle up the messages about I/O completion and doesn't immediately wake up the application to service them. However, it does wake the application for user input, presumably to keep it feeling responsive, and when the application is awake it will handle any pending I/O messages too.



    Thus wiggling the mouse causes the application to process I/O messages faster, and install quicker. The effect was quite pronounced; large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jul 3 at 3:17









    Duncan X Simpson

    1033 bronze badges




    1033 bronze badges










    answered Jul 1 at 8:29









    useruser

    7,4831 gold badge12 silver badges32 bronze badges




    7,4831 gold badge12 silver badges32 bronze badges







    • 45





      @user2652379 Windows 10 seems to be better tuned for modern hardware, so it doesn't queue up I/O events in the same way. Therefore there is usually no benefit to applications. Also, many applications do I/O on a separate thread now anyway, so the user input events don't even reach the part handling file stuff.

      – user
      Jul 1 at 10:18






    • 109





      Could you provide a source for this information so I can dig deeper? If true, I owe some baby boomers apologies for things I said about 20 years ago.

      – user1717828
      Jul 1 at 16:52






    • 26





      Raymond Chen explains a similar bug: devblogs.microsoft.com/oldnewthing/?p=36423

      – snips-n-snails
      Jul 1 at 22:23






    • 6





      @IanRingrose: That's because NT had the original implementation of Async I/O, I assume from its VMS heritage. And there it's not tied to the event loop (message pump). Async I/O was a retrofit on Windows 95.

      – MSalters
      Jul 2 at 7:17






    • 13





      @user2652379 No, Windows 10 is an NT-based system (as was every Windows version since XP). NT never had this issue. Windows 95 had to deal with substantially less powerful hardware than NT, and had different approaches to handling compatibility with older versions of Windows and DOS. And even if it wasn't, Windows 10 has so many changes to the way both IO and UI messaging is handled that it would be quite unlikely this feature would still exist today. It should also be noted that the problem only happens when you're copying a large number of files, which many applications try to avoid anyway.

      – Luaan
      Jul 2 at 8:04












    • 45





      @user2652379 Windows 10 seems to be better tuned for modern hardware, so it doesn't queue up I/O events in the same way. Therefore there is usually no benefit to applications. Also, many applications do I/O on a separate thread now anyway, so the user input events don't even reach the part handling file stuff.

      – user
      Jul 1 at 10:18






    • 109





      Could you provide a source for this information so I can dig deeper? If true, I owe some baby boomers apologies for things I said about 20 years ago.

      – user1717828
      Jul 1 at 16:52






    • 26





      Raymond Chen explains a similar bug: devblogs.microsoft.com/oldnewthing/?p=36423

      – snips-n-snails
      Jul 1 at 22:23






    • 6





      @IanRingrose: That's because NT had the original implementation of Async I/O, I assume from its VMS heritage. And there it's not tied to the event loop (message pump). Async I/O was a retrofit on Windows 95.

      – MSalters
      Jul 2 at 7:17






    • 13





      @user2652379 No, Windows 10 is an NT-based system (as was every Windows version since XP). NT never had this issue. Windows 95 had to deal with substantially less powerful hardware than NT, and had different approaches to handling compatibility with older versions of Windows and DOS. And even if it wasn't, Windows 10 has so many changes to the way both IO and UI messaging is handled that it would be quite unlikely this feature would still exist today. It should also be noted that the problem only happens when you're copying a large number of files, which many applications try to avoid anyway.

      – Luaan
      Jul 2 at 8:04







    45




    45





    @user2652379 Windows 10 seems to be better tuned for modern hardware, so it doesn't queue up I/O events in the same way. Therefore there is usually no benefit to applications. Also, many applications do I/O on a separate thread now anyway, so the user input events don't even reach the part handling file stuff.

    – user
    Jul 1 at 10:18





    @user2652379 Windows 10 seems to be better tuned for modern hardware, so it doesn't queue up I/O events in the same way. Therefore there is usually no benefit to applications. Also, many applications do I/O on a separate thread now anyway, so the user input events don't even reach the part handling file stuff.

    – user
    Jul 1 at 10:18




    109




    109





    Could you provide a source for this information so I can dig deeper? If true, I owe some baby boomers apologies for things I said about 20 years ago.

    – user1717828
    Jul 1 at 16:52





    Could you provide a source for this information so I can dig deeper? If true, I owe some baby boomers apologies for things I said about 20 years ago.

    – user1717828
    Jul 1 at 16:52




    26




    26





    Raymond Chen explains a similar bug: devblogs.microsoft.com/oldnewthing/?p=36423

    – snips-n-snails
    Jul 1 at 22:23





    Raymond Chen explains a similar bug: devblogs.microsoft.com/oldnewthing/?p=36423

    – snips-n-snails
    Jul 1 at 22:23




    6




    6





    @IanRingrose: That's because NT had the original implementation of Async I/O, I assume from its VMS heritage. And there it's not tied to the event loop (message pump). Async I/O was a retrofit on Windows 95.

    – MSalters
    Jul 2 at 7:17





    @IanRingrose: That's because NT had the original implementation of Async I/O, I assume from its VMS heritage. And there it's not tied to the event loop (message pump). Async I/O was a retrofit on Windows 95.

    – MSalters
    Jul 2 at 7:17




    13




    13





    @user2652379 No, Windows 10 is an NT-based system (as was every Windows version since XP). NT never had this issue. Windows 95 had to deal with substantially less powerful hardware than NT, and had different approaches to handling compatibility with older versions of Windows and DOS. And even if it wasn't, Windows 10 has so many changes to the way both IO and UI messaging is handled that it would be quite unlikely this feature would still exist today. It should also be noted that the problem only happens when you're copying a large number of files, which many applications try to avoid anyway.

    – Luaan
    Jul 2 at 8:04





    @user2652379 No, Windows 10 is an NT-based system (as was every Windows version since XP). NT never had this issue. Windows 95 had to deal with substantially less powerful hardware than NT, and had different approaches to handling compatibility with older versions of Windows and DOS. And even if it wasn't, Windows 10 has so many changes to the way both IO and UI messaging is handled that it would be quite unlikely this feature would still exist today. It should also be noted that the problem only happens when you're copying a large number of files, which many applications try to avoid anyway.

    – Luaan
    Jul 2 at 8:04













    90














    Yes, it's a real effect resulting in causing a measurable speed up and can be reproduced at will:



    Try opening a large file with Notepad on a contemporary machine. The window must not be full screen. When loaded, mark all text using the mouse (the keyboard works as well, it just needs more manual skill). While still holding the button down (and marking) move the mouse down, so the text gets marked and scrolled. Now compare the scroll speed while holding the mouse still versus wiggling it. Depending on your machine the speed up can be several times faster.



    Amazing, isn't it?



    It can be viewed in many other programs as well, Notepad is just an easy to reproduce example. It's related to the way multitasking worked in early versions of Windows. Here everything revolved around the message queue. Wiggling the mouse resulted in a flood of mouse-move messages, which in turn made programs wake up more often and (depending on their structure) updating their states each time, going into the message loop again, giving time to screen updates, resulting in an over all faster reaction. It shows a glimpse of the ways MS used to make Windows rather responsive despite its cooperative threaded nature.






    share|improve this answer




















    • 11





      Windows 95 had pre-emptive multi tasking and threading. However, Microsoft spent a lot of effort making the event handling completely deterministic as it was in Windows 3.x and also the GDI (which was 95% the same as the Win 3.x GDI) was protected by a global lock so only one process could be in it at a time. I guess the issue was a weird emergent effect of that.

      – JeremyP
      Jul 1 at 9:50






    • 58





      Wow, this is so ingrained in me that I never really noticed that I reflexively wiggle my mouse when selecting a big chunk of text, and have been doing so for decades.

      – Nuclear Wang
      Jul 1 at 15:13






    • 59





      I thought it was just an OS feature - if you want slow scrolling in case you don't want to select too much, just move the mouse down; but if you want fast scrolling to select a lot of text, then move the mouse down while also moving it side to side.

      – pacoverflow
      Jul 1 at 18:35






    • 9





      This does sound like a UI- / usability feature, not like it has an effect on "running speed" of the application. Granted, it is an example of something moving faster while moving the mouse. I'm not sure it exactly answers the question, though.

      – Kakturus
      Jul 2 at 12:03







    • 7





      No this is wrong. This effect has nothing to do with performance, it has to do with handling WM_MOUSEMOVE and WM_TIMER in the message dispatch and the timer*increment being smaller than a hose of mouse moves.

      – Eric
      Jul 3 at 20:29















    90














    Yes, it's a real effect resulting in causing a measurable speed up and can be reproduced at will:



    Try opening a large file with Notepad on a contemporary machine. The window must not be full screen. When loaded, mark all text using the mouse (the keyboard works as well, it just needs more manual skill). While still holding the button down (and marking) move the mouse down, so the text gets marked and scrolled. Now compare the scroll speed while holding the mouse still versus wiggling it. Depending on your machine the speed up can be several times faster.



    Amazing, isn't it?



    It can be viewed in many other programs as well, Notepad is just an easy to reproduce example. It's related to the way multitasking worked in early versions of Windows. Here everything revolved around the message queue. Wiggling the mouse resulted in a flood of mouse-move messages, which in turn made programs wake up more often and (depending on their structure) updating their states each time, going into the message loop again, giving time to screen updates, resulting in an over all faster reaction. It shows a glimpse of the ways MS used to make Windows rather responsive despite its cooperative threaded nature.






    share|improve this answer




















    • 11





      Windows 95 had pre-emptive multi tasking and threading. However, Microsoft spent a lot of effort making the event handling completely deterministic as it was in Windows 3.x and also the GDI (which was 95% the same as the Win 3.x GDI) was protected by a global lock so only one process could be in it at a time. I guess the issue was a weird emergent effect of that.

      – JeremyP
      Jul 1 at 9:50






    • 58





      Wow, this is so ingrained in me that I never really noticed that I reflexively wiggle my mouse when selecting a big chunk of text, and have been doing so for decades.

      – Nuclear Wang
      Jul 1 at 15:13






    • 59





      I thought it was just an OS feature - if you want slow scrolling in case you don't want to select too much, just move the mouse down; but if you want fast scrolling to select a lot of text, then move the mouse down while also moving it side to side.

      – pacoverflow
      Jul 1 at 18:35






    • 9





      This does sound like a UI- / usability feature, not like it has an effect on "running speed" of the application. Granted, it is an example of something moving faster while moving the mouse. I'm not sure it exactly answers the question, though.

      – Kakturus
      Jul 2 at 12:03







    • 7





      No this is wrong. This effect has nothing to do with performance, it has to do with handling WM_MOUSEMOVE and WM_TIMER in the message dispatch and the timer*increment being smaller than a hose of mouse moves.

      – Eric
      Jul 3 at 20:29













    90












    90








    90







    Yes, it's a real effect resulting in causing a measurable speed up and can be reproduced at will:



    Try opening a large file with Notepad on a contemporary machine. The window must not be full screen. When loaded, mark all text using the mouse (the keyboard works as well, it just needs more manual skill). While still holding the button down (and marking) move the mouse down, so the text gets marked and scrolled. Now compare the scroll speed while holding the mouse still versus wiggling it. Depending on your machine the speed up can be several times faster.



    Amazing, isn't it?



    It can be viewed in many other programs as well, Notepad is just an easy to reproduce example. It's related to the way multitasking worked in early versions of Windows. Here everything revolved around the message queue. Wiggling the mouse resulted in a flood of mouse-move messages, which in turn made programs wake up more often and (depending on their structure) updating their states each time, going into the message loop again, giving time to screen updates, resulting in an over all faster reaction. It shows a glimpse of the ways MS used to make Windows rather responsive despite its cooperative threaded nature.






    share|improve this answer















    Yes, it's a real effect resulting in causing a measurable speed up and can be reproduced at will:



    Try opening a large file with Notepad on a contemporary machine. The window must not be full screen. When loaded, mark all text using the mouse (the keyboard works as well, it just needs more manual skill). While still holding the button down (and marking) move the mouse down, so the text gets marked and scrolled. Now compare the scroll speed while holding the mouse still versus wiggling it. Depending on your machine the speed up can be several times faster.



    Amazing, isn't it?



    It can be viewed in many other programs as well, Notepad is just an easy to reproduce example. It's related to the way multitasking worked in early versions of Windows. Here everything revolved around the message queue. Wiggling the mouse resulted in a flood of mouse-move messages, which in turn made programs wake up more often and (depending on their structure) updating their states each time, going into the message loop again, giving time to screen updates, resulting in an over all faster reaction. It shows a glimpse of the ways MS used to make Windows rather responsive despite its cooperative threaded nature.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jul 3 at 6:43

























    answered Jul 1 at 7:56









    RaffzahnRaffzahn

    62.7k6 gold badges153 silver badges257 bronze badges




    62.7k6 gold badges153 silver badges257 bronze badges







    • 11





      Windows 95 had pre-emptive multi tasking and threading. However, Microsoft spent a lot of effort making the event handling completely deterministic as it was in Windows 3.x and also the GDI (which was 95% the same as the Win 3.x GDI) was protected by a global lock so only one process could be in it at a time. I guess the issue was a weird emergent effect of that.

      – JeremyP
      Jul 1 at 9:50






    • 58





      Wow, this is so ingrained in me that I never really noticed that I reflexively wiggle my mouse when selecting a big chunk of text, and have been doing so for decades.

      – Nuclear Wang
      Jul 1 at 15:13






    • 59





      I thought it was just an OS feature - if you want slow scrolling in case you don't want to select too much, just move the mouse down; but if you want fast scrolling to select a lot of text, then move the mouse down while also moving it side to side.

      – pacoverflow
      Jul 1 at 18:35






    • 9





      This does sound like a UI- / usability feature, not like it has an effect on "running speed" of the application. Granted, it is an example of something moving faster while moving the mouse. I'm not sure it exactly answers the question, though.

      – Kakturus
      Jul 2 at 12:03







    • 7





      No this is wrong. This effect has nothing to do with performance, it has to do with handling WM_MOUSEMOVE and WM_TIMER in the message dispatch and the timer*increment being smaller than a hose of mouse moves.

      – Eric
      Jul 3 at 20:29












    • 11





      Windows 95 had pre-emptive multi tasking and threading. However, Microsoft spent a lot of effort making the event handling completely deterministic as it was in Windows 3.x and also the GDI (which was 95% the same as the Win 3.x GDI) was protected by a global lock so only one process could be in it at a time. I guess the issue was a weird emergent effect of that.

      – JeremyP
      Jul 1 at 9:50






    • 58





      Wow, this is so ingrained in me that I never really noticed that I reflexively wiggle my mouse when selecting a big chunk of text, and have been doing so for decades.

      – Nuclear Wang
      Jul 1 at 15:13






    • 59





      I thought it was just an OS feature - if you want slow scrolling in case you don't want to select too much, just move the mouse down; but if you want fast scrolling to select a lot of text, then move the mouse down while also moving it side to side.

      – pacoverflow
      Jul 1 at 18:35






    • 9





      This does sound like a UI- / usability feature, not like it has an effect on "running speed" of the application. Granted, it is an example of something moving faster while moving the mouse. I'm not sure it exactly answers the question, though.

      – Kakturus
      Jul 2 at 12:03







    • 7





      No this is wrong. This effect has nothing to do with performance, it has to do with handling WM_MOUSEMOVE and WM_TIMER in the message dispatch and the timer*increment being smaller than a hose of mouse moves.

      – Eric
      Jul 3 at 20:29







    11




    11





    Windows 95 had pre-emptive multi tasking and threading. However, Microsoft spent a lot of effort making the event handling completely deterministic as it was in Windows 3.x and also the GDI (which was 95% the same as the Win 3.x GDI) was protected by a global lock so only one process could be in it at a time. I guess the issue was a weird emergent effect of that.

    – JeremyP
    Jul 1 at 9:50





    Windows 95 had pre-emptive multi tasking and threading. However, Microsoft spent a lot of effort making the event handling completely deterministic as it was in Windows 3.x and also the GDI (which was 95% the same as the Win 3.x GDI) was protected by a global lock so only one process could be in it at a time. I guess the issue was a weird emergent effect of that.

    – JeremyP
    Jul 1 at 9:50




    58




    58





    Wow, this is so ingrained in me that I never really noticed that I reflexively wiggle my mouse when selecting a big chunk of text, and have been doing so for decades.

    – Nuclear Wang
    Jul 1 at 15:13





    Wow, this is so ingrained in me that I never really noticed that I reflexively wiggle my mouse when selecting a big chunk of text, and have been doing so for decades.

    – Nuclear Wang
    Jul 1 at 15:13




    59




    59





    I thought it was just an OS feature - if you want slow scrolling in case you don't want to select too much, just move the mouse down; but if you want fast scrolling to select a lot of text, then move the mouse down while also moving it side to side.

    – pacoverflow
    Jul 1 at 18:35





    I thought it was just an OS feature - if you want slow scrolling in case you don't want to select too much, just move the mouse down; but if you want fast scrolling to select a lot of text, then move the mouse down while also moving it side to side.

    – pacoverflow
    Jul 1 at 18:35




    9




    9





    This does sound like a UI- / usability feature, not like it has an effect on "running speed" of the application. Granted, it is an example of something moving faster while moving the mouse. I'm not sure it exactly answers the question, though.

    – Kakturus
    Jul 2 at 12:03






    This does sound like a UI- / usability feature, not like it has an effect on "running speed" of the application. Granted, it is an example of something moving faster while moving the mouse. I'm not sure it exactly answers the question, though.

    – Kakturus
    Jul 2 at 12:03





    7




    7





    No this is wrong. This effect has nothing to do with performance, it has to do with handling WM_MOUSEMOVE and WM_TIMER in the message dispatch and the timer*increment being smaller than a hose of mouse moves.

    – Eric
    Jul 3 at 20:29





    No this is wrong. This effect has nothing to do with performance, it has to do with handling WM_MOUSEMOVE and WM_TIMER in the message dispatch and the timer*increment being smaller than a hose of mouse moves.

    – Eric
    Jul 3 at 20:29











    33














    It wasn't just Windows 95, but Windows 3.x as well, even though they work very differently.



    Other answers talk about pre-emptive multitasking, so let's first clarify this:



    Window 3.x was using cooperative multitasking where each app would release the cpu for the other apps to use it. Windows 95 uses pre-emptive multitasking where each app is allocated a time slice.



    The answer is linked to how the graphic interface works: in a windows graphical app, there is a loop called the 'message pump':



    Every event (mouse moved, window got resized, etc) is pushed into a queue. The app is responsible to check if it has messages waiting and, if yes, pull them and process them.



    This is at this moment that Windows 3.x was switching to other apps since there was a single point where all apps where going to, but this doesn't apply to windows 95.



    What really happens is that, on both OS, you need to process the message loop, but if you want to update something in the background, like a task, a display update, etc, you'd set a timer and the timer would put a message in the queue at a regular interval.



    These were better ways to do things on Windows 95, but developers took time to transition from Windows 3.x and many apps were structured the same.



    Since the main mechanism was to rely only on the message loop and background operations were done through timer messages, moving the mouse would trigger a lot of messages, move the app up in priority, wake the app up, and get the app to process the background tasks messages. Without moving the mouse, the timer messages would be read up only at a rather slow interval.



    The most famous app for this was the disk defragmenter where operations would wait for a message to update the graphic interface! so shaking the mouse would speed up the defrag.






    share|improve this answer























    • Was it just the UI that did not update in the "disk defragmenter", I think at least on NT, it did the real work in a different thread.

      – Ian Ringrose
      Jul 1 at 23:14






    • 3





      the disk defragmenter was doing work in chunk and the main loop was pulling messages checking what blocks were done, update the ui and trigger another block; they implemented the '95 defragmenter with a win 3.x structure because it took a while for people to do things differently. NT was a very different animal altogether at the time; if I remember NT and OS/2 were quite similar in a few points and microsoft really saw a 'home' line and a 'business' line.

      – Thomas
      Jul 2 at 10:11















    33














    It wasn't just Windows 95, but Windows 3.x as well, even though they work very differently.



    Other answers talk about pre-emptive multitasking, so let's first clarify this:



    Window 3.x was using cooperative multitasking where each app would release the cpu for the other apps to use it. Windows 95 uses pre-emptive multitasking where each app is allocated a time slice.



    The answer is linked to how the graphic interface works: in a windows graphical app, there is a loop called the 'message pump':



    Every event (mouse moved, window got resized, etc) is pushed into a queue. The app is responsible to check if it has messages waiting and, if yes, pull them and process them.



    This is at this moment that Windows 3.x was switching to other apps since there was a single point where all apps where going to, but this doesn't apply to windows 95.



    What really happens is that, on both OS, you need to process the message loop, but if you want to update something in the background, like a task, a display update, etc, you'd set a timer and the timer would put a message in the queue at a regular interval.



    These were better ways to do things on Windows 95, but developers took time to transition from Windows 3.x and many apps were structured the same.



    Since the main mechanism was to rely only on the message loop and background operations were done through timer messages, moving the mouse would trigger a lot of messages, move the app up in priority, wake the app up, and get the app to process the background tasks messages. Without moving the mouse, the timer messages would be read up only at a rather slow interval.



    The most famous app for this was the disk defragmenter where operations would wait for a message to update the graphic interface! so shaking the mouse would speed up the defrag.






    share|improve this answer























    • Was it just the UI that did not update in the "disk defragmenter", I think at least on NT, it did the real work in a different thread.

      – Ian Ringrose
      Jul 1 at 23:14






    • 3





      the disk defragmenter was doing work in chunk and the main loop was pulling messages checking what blocks were done, update the ui and trigger another block; they implemented the '95 defragmenter with a win 3.x structure because it took a while for people to do things differently. NT was a very different animal altogether at the time; if I remember NT and OS/2 were quite similar in a few points and microsoft really saw a 'home' line and a 'business' line.

      – Thomas
      Jul 2 at 10:11













    33












    33








    33







    It wasn't just Windows 95, but Windows 3.x as well, even though they work very differently.



    Other answers talk about pre-emptive multitasking, so let's first clarify this:



    Window 3.x was using cooperative multitasking where each app would release the cpu for the other apps to use it. Windows 95 uses pre-emptive multitasking where each app is allocated a time slice.



    The answer is linked to how the graphic interface works: in a windows graphical app, there is a loop called the 'message pump':



    Every event (mouse moved, window got resized, etc) is pushed into a queue. The app is responsible to check if it has messages waiting and, if yes, pull them and process them.



    This is at this moment that Windows 3.x was switching to other apps since there was a single point where all apps where going to, but this doesn't apply to windows 95.



    What really happens is that, on both OS, you need to process the message loop, but if you want to update something in the background, like a task, a display update, etc, you'd set a timer and the timer would put a message in the queue at a regular interval.



    These were better ways to do things on Windows 95, but developers took time to transition from Windows 3.x and many apps were structured the same.



    Since the main mechanism was to rely only on the message loop and background operations were done through timer messages, moving the mouse would trigger a lot of messages, move the app up in priority, wake the app up, and get the app to process the background tasks messages. Without moving the mouse, the timer messages would be read up only at a rather slow interval.



    The most famous app for this was the disk defragmenter where operations would wait for a message to update the graphic interface! so shaking the mouse would speed up the defrag.






    share|improve this answer













    It wasn't just Windows 95, but Windows 3.x as well, even though they work very differently.



    Other answers talk about pre-emptive multitasking, so let's first clarify this:



    Window 3.x was using cooperative multitasking where each app would release the cpu for the other apps to use it. Windows 95 uses pre-emptive multitasking where each app is allocated a time slice.



    The answer is linked to how the graphic interface works: in a windows graphical app, there is a loop called the 'message pump':



    Every event (mouse moved, window got resized, etc) is pushed into a queue. The app is responsible to check if it has messages waiting and, if yes, pull them and process them.



    This is at this moment that Windows 3.x was switching to other apps since there was a single point where all apps where going to, but this doesn't apply to windows 95.



    What really happens is that, on both OS, you need to process the message loop, but if you want to update something in the background, like a task, a display update, etc, you'd set a timer and the timer would put a message in the queue at a regular interval.



    These were better ways to do things on Windows 95, but developers took time to transition from Windows 3.x and many apps were structured the same.



    Since the main mechanism was to rely only on the message loop and background operations were done through timer messages, moving the mouse would trigger a lot of messages, move the app up in priority, wake the app up, and get the app to process the background tasks messages. Without moving the mouse, the timer messages would be read up only at a rather slow interval.



    The most famous app for this was the disk defragmenter where operations would wait for a message to update the graphic interface! so shaking the mouse would speed up the defrag.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jul 1 at 16:20









    ThomasThomas

    2,7497 silver badges21 bronze badges




    2,7497 silver badges21 bronze badges












    • Was it just the UI that did not update in the "disk defragmenter", I think at least on NT, it did the real work in a different thread.

      – Ian Ringrose
      Jul 1 at 23:14






    • 3





      the disk defragmenter was doing work in chunk and the main loop was pulling messages checking what blocks were done, update the ui and trigger another block; they implemented the '95 defragmenter with a win 3.x structure because it took a while for people to do things differently. NT was a very different animal altogether at the time; if I remember NT and OS/2 were quite similar in a few points and microsoft really saw a 'home' line and a 'business' line.

      – Thomas
      Jul 2 at 10:11

















    • Was it just the UI that did not update in the "disk defragmenter", I think at least on NT, it did the real work in a different thread.

      – Ian Ringrose
      Jul 1 at 23:14






    • 3





      the disk defragmenter was doing work in chunk and the main loop was pulling messages checking what blocks were done, update the ui and trigger another block; they implemented the '95 defragmenter with a win 3.x structure because it took a while for people to do things differently. NT was a very different animal altogether at the time; if I remember NT and OS/2 were quite similar in a few points and microsoft really saw a 'home' line and a 'business' line.

      – Thomas
      Jul 2 at 10:11
















    Was it just the UI that did not update in the "disk defragmenter", I think at least on NT, it did the real work in a different thread.

    – Ian Ringrose
    Jul 1 at 23:14





    Was it just the UI that did not update in the "disk defragmenter", I think at least on NT, it did the real work in a different thread.

    – Ian Ringrose
    Jul 1 at 23:14




    3




    3





    the disk defragmenter was doing work in chunk and the main loop was pulling messages checking what blocks were done, update the ui and trigger another block; they implemented the '95 defragmenter with a win 3.x structure because it took a while for people to do things differently. NT was a very different animal altogether at the time; if I remember NT and OS/2 were quite similar in a few points and microsoft really saw a 'home' line and a 'business' line.

    – Thomas
    Jul 2 at 10:11





    the disk defragmenter was doing work in chunk and the main loop was pulling messages checking what blocks were done, update the ui and trigger another block; they implemented the '95 defragmenter with a win 3.x structure because it took a while for people to do things differently. NT was a very different animal altogether at the time; if I remember NT and OS/2 were quite similar in a few points and microsoft really saw a 'home' line and a 'business' line.

    – Thomas
    Jul 2 at 10:11











    18














    The reason is because of how WM_TIMER is limited to 15.6ms intervals by default. If you call SetTimer() with a 1ms interval it will still be called in 15.6ms intervals. WM_TIMER drives a lot of stuff in Win32 applications like network packet processing and such.



    Moving the mouse causes WM_TIMER events to fire more often on Win95. So some applications will seem to run faster.



    The 15.6ms value was set for various reasons: Not clogging up the event queue so that stuff like WM_PAINT would still dispatch often enough and more recently and importantly to save power. There are tons of articles talking about this:



    https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/






    share|improve this answer










    New contributor



    Tinic Uro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.














    • 1





      Do you have a source, or some sort of evidence, for the claim that "moving the mouse causes WM_TIMER events to fire more often"? I can't think of an intuitive reason why, given my knowledge of the design of Windows' message loops, so that would have to be a Windows 95-specific bug. The message loop dispatches SendMessage-generated messages in order, then PostMessage-generated messages in order, and, finally, synthesizes WM_TIMER, WM_PAINT, and/or WM_MOUSEMOVE messages, as needed.

      – Cody Gray
      Jul 4 at 4:43















    18














    The reason is because of how WM_TIMER is limited to 15.6ms intervals by default. If you call SetTimer() with a 1ms interval it will still be called in 15.6ms intervals. WM_TIMER drives a lot of stuff in Win32 applications like network packet processing and such.



    Moving the mouse causes WM_TIMER events to fire more often on Win95. So some applications will seem to run faster.



    The 15.6ms value was set for various reasons: Not clogging up the event queue so that stuff like WM_PAINT would still dispatch often enough and more recently and importantly to save power. There are tons of articles talking about this:



    https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/






    share|improve this answer










    New contributor



    Tinic Uro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.














    • 1





      Do you have a source, or some sort of evidence, for the claim that "moving the mouse causes WM_TIMER events to fire more often"? I can't think of an intuitive reason why, given my knowledge of the design of Windows' message loops, so that would have to be a Windows 95-specific bug. The message loop dispatches SendMessage-generated messages in order, then PostMessage-generated messages in order, and, finally, synthesizes WM_TIMER, WM_PAINT, and/or WM_MOUSEMOVE messages, as needed.

      – Cody Gray
      Jul 4 at 4:43













    18












    18








    18







    The reason is because of how WM_TIMER is limited to 15.6ms intervals by default. If you call SetTimer() with a 1ms interval it will still be called in 15.6ms intervals. WM_TIMER drives a lot of stuff in Win32 applications like network packet processing and such.



    Moving the mouse causes WM_TIMER events to fire more often on Win95. So some applications will seem to run faster.



    The 15.6ms value was set for various reasons: Not clogging up the event queue so that stuff like WM_PAINT would still dispatch often enough and more recently and importantly to save power. There are tons of articles talking about this:



    https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/






    share|improve this answer










    New contributor



    Tinic Uro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    The reason is because of how WM_TIMER is limited to 15.6ms intervals by default. If you call SetTimer() with a 1ms interval it will still be called in 15.6ms intervals. WM_TIMER drives a lot of stuff in Win32 applications like network packet processing and such.



    Moving the mouse causes WM_TIMER events to fire more often on Win95. So some applications will seem to run faster.



    The 15.6ms value was set for various reasons: Not clogging up the event queue so that stuff like WM_PAINT would still dispatch often enough and more recently and importantly to save power. There are tons of articles talking about this:



    https://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/







    share|improve this answer










    New contributor



    Tinic Uro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.








    share|improve this answer



    share|improve this answer








    edited Jul 4 at 4:40









    Cactus

    7597 silver badges27 bronze badges




    7597 silver badges27 bronze badges






    New contributor



    Tinic Uro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.








    answered Jul 3 at 16:51









    Tinic UroTinic Uro

    1812 bronze badges




    1812 bronze badges




    New contributor



    Tinic Uro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.




    New contributor




    Tinic Uro is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    • 1





      Do you have a source, or some sort of evidence, for the claim that "moving the mouse causes WM_TIMER events to fire more often"? I can't think of an intuitive reason why, given my knowledge of the design of Windows' message loops, so that would have to be a Windows 95-specific bug. The message loop dispatches SendMessage-generated messages in order, then PostMessage-generated messages in order, and, finally, synthesizes WM_TIMER, WM_PAINT, and/or WM_MOUSEMOVE messages, as needed.

      – Cody Gray
      Jul 4 at 4:43












    • 1





      Do you have a source, or some sort of evidence, for the claim that "moving the mouse causes WM_TIMER events to fire more often"? I can't think of an intuitive reason why, given my knowledge of the design of Windows' message loops, so that would have to be a Windows 95-specific bug. The message loop dispatches SendMessage-generated messages in order, then PostMessage-generated messages in order, and, finally, synthesizes WM_TIMER, WM_PAINT, and/or WM_MOUSEMOVE messages, as needed.

      – Cody Gray
      Jul 4 at 4:43







    1




    1





    Do you have a source, or some sort of evidence, for the claim that "moving the mouse causes WM_TIMER events to fire more often"? I can't think of an intuitive reason why, given my knowledge of the design of Windows' message loops, so that would have to be a Windows 95-specific bug. The message loop dispatches SendMessage-generated messages in order, then PostMessage-generated messages in order, and, finally, synthesizes WM_TIMER, WM_PAINT, and/or WM_MOUSEMOVE messages, as needed.

    – Cody Gray
    Jul 4 at 4:43





    Do you have a source, or some sort of evidence, for the claim that "moving the mouse causes WM_TIMER events to fire more often"? I can't think of an intuitive reason why, given my knowledge of the design of Windows' message loops, so that would have to be a Windows 95-specific bug. The message loop dispatches SendMessage-generated messages in order, then PostMessage-generated messages in order, and, finally, synthesizes WM_TIMER, WM_PAINT, and/or WM_MOUSEMOVE messages, as needed.

    – Cody Gray
    Jul 4 at 4:43











    10














    Raymond Chen from Microsoft has a great answer on his blog:




    One danger of the MsgWaitForMultipleObjects function
    is calling it when there are already messages waiting
    to be processed, because MsgWaitForMultipleObjects
    returns only when there is a new event in the queue.




    His blog is a great read!






    share|improve this answer










    New contributor



    rwbaskette is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.



















    • This is a great post...Raymond specifically mentions moving the mouse, showing an example where “Sometimes my program gets stuck and reports one fewer record than it should. I have to jiggle the mouse to get the value to update.”

      – Martin Burch
      yesterday















    10














    Raymond Chen from Microsoft has a great answer on his blog:




    One danger of the MsgWaitForMultipleObjects function
    is calling it when there are already messages waiting
    to be processed, because MsgWaitForMultipleObjects
    returns only when there is a new event in the queue.




    His blog is a great read!






    share|improve this answer










    New contributor



    rwbaskette is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.



















    • This is a great post...Raymond specifically mentions moving the mouse, showing an example where “Sometimes my program gets stuck and reports one fewer record than it should. I have to jiggle the mouse to get the value to update.”

      – Martin Burch
      yesterday













    10












    10








    10







    Raymond Chen from Microsoft has a great answer on his blog:




    One danger of the MsgWaitForMultipleObjects function
    is calling it when there are already messages waiting
    to be processed, because MsgWaitForMultipleObjects
    returns only when there is a new event in the queue.




    His blog is a great read!






    share|improve this answer










    New contributor



    rwbaskette is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    Raymond Chen from Microsoft has a great answer on his blog:




    One danger of the MsgWaitForMultipleObjects function
    is calling it when there are already messages waiting
    to be processed, because MsgWaitForMultipleObjects
    returns only when there is a new event in the queue.




    His blog is a great read!







    share|improve this answer










    New contributor



    rwbaskette is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.








    share|improve this answer



    share|improve this answer








    edited Jul 4 at 4:40









    Cactus

    7597 silver badges27 bronze badges




    7597 silver badges27 bronze badges






    New contributor



    rwbaskette is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.








    answered Jul 4 at 0:51









    rwbasketterwbaskette

    1092 bronze badges




    1092 bronze badges




    New contributor



    rwbaskette is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.




    New contributor




    rwbaskette is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.














    • This is a great post...Raymond specifically mentions moving the mouse, showing an example where “Sometimes my program gets stuck and reports one fewer record than it should. I have to jiggle the mouse to get the value to update.”

      – Martin Burch
      yesterday

















    • This is a great post...Raymond specifically mentions moving the mouse, showing an example where “Sometimes my program gets stuck and reports one fewer record than it should. I have to jiggle the mouse to get the value to update.”

      – Martin Burch
      yesterday
















    This is a great post...Raymond specifically mentions moving the mouse, showing an example where “Sometimes my program gets stuck and reports one fewer record than it should. I have to jiggle the mouse to get the value to update.”

    – Martin Burch
    yesterday





    This is a great post...Raymond specifically mentions moving the mouse, showing an example where “Sometimes my program gets stuck and reports one fewer record than it should. I have to jiggle the mouse to get the value to update.”

    – Martin Burch
    yesterday











    9














    Arguably, this is a common bug in early software based on an event-processing loop rather than a Windows bug: if some DD-paths of the loop only process a single event, then every time when two events are generated simultaneously, only one is processed and the other gets stuck. Moving the mouse generates more incoming events and restarts the loop. "Mouse move" events are typically processed by a GUI library, which handles them correctly (that is, processing all such events in the queue), so those events help get the loop going, and then disappear harmlessly.



    Such bugs are easily missed when the testing is done by hand, since the act of testing itself generates enough input events to keep the bug hidden.






    share|improve this answer




















    • 1





      Yours is the only answer I upvoted because it seems plausible to me that this issue is a misuse of the Windows SDK rather than a problem in Windows itself. Microsoft's Raymond Chen explains the bug more fully here: devblogs.microsoft.com/oldnewthing/?p=36423

      – snips-n-snails
      Jul 3 at 20:53















    9














    Arguably, this is a common bug in early software based on an event-processing loop rather than a Windows bug: if some DD-paths of the loop only process a single event, then every time when two events are generated simultaneously, only one is processed and the other gets stuck. Moving the mouse generates more incoming events and restarts the loop. "Mouse move" events are typically processed by a GUI library, which handles them correctly (that is, processing all such events in the queue), so those events help get the loop going, and then disappear harmlessly.



    Such bugs are easily missed when the testing is done by hand, since the act of testing itself generates enough input events to keep the bug hidden.






    share|improve this answer




















    • 1





      Yours is the only answer I upvoted because it seems plausible to me that this issue is a misuse of the Windows SDK rather than a problem in Windows itself. Microsoft's Raymond Chen explains the bug more fully here: devblogs.microsoft.com/oldnewthing/?p=36423

      – snips-n-snails
      Jul 3 at 20:53













    9












    9








    9







    Arguably, this is a common bug in early software based on an event-processing loop rather than a Windows bug: if some DD-paths of the loop only process a single event, then every time when two events are generated simultaneously, only one is processed and the other gets stuck. Moving the mouse generates more incoming events and restarts the loop. "Mouse move" events are typically processed by a GUI library, which handles them correctly (that is, processing all such events in the queue), so those events help get the loop going, and then disappear harmlessly.



    Such bugs are easily missed when the testing is done by hand, since the act of testing itself generates enough input events to keep the bug hidden.






    share|improve this answer















    Arguably, this is a common bug in early software based on an event-processing loop rather than a Windows bug: if some DD-paths of the loop only process a single event, then every time when two events are generated simultaneously, only one is processed and the other gets stuck. Moving the mouse generates more incoming events and restarts the loop. "Mouse move" events are typically processed by a GUI library, which handles them correctly (that is, processing all such events in the queue), so those events help get the loop going, and then disappear harmlessly.



    Such bugs are easily missed when the testing is done by hand, since the act of testing itself generates enough input events to keep the bug hidden.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jul 4 at 4:38









    Cody Gray

    1,1786 silver badges21 bronze badges




    1,1786 silver badges21 bronze badges










    answered Jul 3 at 13:19









    Dmitry GrigoryevDmitry Grigoryev

    3032 silver badges6 bronze badges




    3032 silver badges6 bronze badges







    • 1





      Yours is the only answer I upvoted because it seems plausible to me that this issue is a misuse of the Windows SDK rather than a problem in Windows itself. Microsoft's Raymond Chen explains the bug more fully here: devblogs.microsoft.com/oldnewthing/?p=36423

      – snips-n-snails
      Jul 3 at 20:53












    • 1





      Yours is the only answer I upvoted because it seems plausible to me that this issue is a misuse of the Windows SDK rather than a problem in Windows itself. Microsoft's Raymond Chen explains the bug more fully here: devblogs.microsoft.com/oldnewthing/?p=36423

      – snips-n-snails
      Jul 3 at 20:53







    1




    1





    Yours is the only answer I upvoted because it seems plausible to me that this issue is a misuse of the Windows SDK rather than a problem in Windows itself. Microsoft's Raymond Chen explains the bug more fully here: devblogs.microsoft.com/oldnewthing/?p=36423

    – snips-n-snails
    Jul 3 at 20:53





    Yours is the only answer I upvoted because it seems plausible to me that this issue is a misuse of the Windows SDK rather than a problem in Windows itself. Microsoft's Raymond Chen explains the bug more fully here: devblogs.microsoft.com/oldnewthing/?p=36423

    – snips-n-snails
    Jul 3 at 20:53











    1














    Quick answer, by moving the cursor you were telling windows that you are the most important event running. When you stop interacting windows gives priority to other events. So installing programs even when in foreground would give priority to less important events. This bug is no longer present in current Windows versions.






    share|improve this answer








    New contributor



    karmafunk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.























      1














      Quick answer, by moving the cursor you were telling windows that you are the most important event running. When you stop interacting windows gives priority to other events. So installing programs even when in foreground would give priority to less important events. This bug is no longer present in current Windows versions.






      share|improve this answer








      New contributor



      karmafunk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





















        1












        1








        1







        Quick answer, by moving the cursor you were telling windows that you are the most important event running. When you stop interacting windows gives priority to other events. So installing programs even when in foreground would give priority to less important events. This bug is no longer present in current Windows versions.






        share|improve this answer








        New contributor



        karmafunk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.









        Quick answer, by moving the cursor you were telling windows that you are the most important event running. When you stop interacting windows gives priority to other events. So installing programs even when in foreground would give priority to less important events. This bug is no longer present in current Windows versions.







        share|improve this answer








        New contributor



        karmafunk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.








        share|improve this answer



        share|improve this answer






        New contributor



        karmafunk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.








        answered Jul 4 at 9:16









        karmafunkkarmafunk

        1112 bronze badges




        1112 bronze badges




        New contributor



        karmafunk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.




        New contributor




        karmafunk is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
        Check out our Code of Conduct.























            -3














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



            On cooperative multitasking, the foreground app has to yield control to other tasks. Thus if the foreground app got stuck, the whole machine froze.



            Preemptive multitasking, the system usually had a hardware interrupt, usually a timer, to force a yield.



            On Windows 95, the keyboard and mouse generated interrupts, moving the mouse caused the interrupt to fire and the OS to service it's event queue. A form of preemptive multitasking, instead of a fixed timer interrupt, you were doing it.



            The OS would update the status on screen at the interrupt and then go service the other tasks. The screen update would make it seem that the OS was processing faster.



            EDIT - 1/2 right ...
            Cannot pre-emptively multitask Win16 applications because it uses the same System Virtual Machine (VM) model as in Windows 3.1 to run Win16 applications. Thus, Windows 95 will revert to a cooperative multitasking environment when running Win16 applications and give them exclusive control of the CPU for as long as the applications are executing. As a result, true pre-emptive operation is impossible when multitasking a mixture of Win16 and Win32 applications.






            share|improve this answer




















            • 14





              Windows 95 is pre-emptive multitasking. It was, in fact, one of the major design goals of Windows 95.

              – user
              Jul 1 at 10:19











            • WIN95 from Packard Bell was awesome in all the featured apps they included . THey also used low DPI ball mice back in those days that needed more smoothing.= from averaging. Now laser mice are much higher DPI and can wake up my WIn7 just by tingle vibration on the couch or table with mouse.

              – Sunnyskyguy EE75
              Jul 1 at 20:31











            • @SunnyskyguyEE75 Funnily enough most wireless mice sidestep that issue because they themselves go to sleep and require significant movement to wake up.

              – Bob
              Jul 3 at 2:24











            • Not mine @Bob As soon as I sit on the couch with mouse at the end not moving, big screen TV turns on which is connected to computer, as it comes out of sleep mode, instantly. M185 LOgitech That doesn't even move the cursor when it's awake.1 AA cell, going on 1 year now., and it is used many hours daily.

              – Sunnyskyguy EE75
              Jul 3 at 2:40
















            -3














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



            On cooperative multitasking, the foreground app has to yield control to other tasks. Thus if the foreground app got stuck, the whole machine froze.



            Preemptive multitasking, the system usually had a hardware interrupt, usually a timer, to force a yield.



            On Windows 95, the keyboard and mouse generated interrupts, moving the mouse caused the interrupt to fire and the OS to service it's event queue. A form of preemptive multitasking, instead of a fixed timer interrupt, you were doing it.



            The OS would update the status on screen at the interrupt and then go service the other tasks. The screen update would make it seem that the OS was processing faster.



            EDIT - 1/2 right ...
            Cannot pre-emptively multitask Win16 applications because it uses the same System Virtual Machine (VM) model as in Windows 3.1 to run Win16 applications. Thus, Windows 95 will revert to a cooperative multitasking environment when running Win16 applications and give them exclusive control of the CPU for as long as the applications are executing. As a result, true pre-emptive operation is impossible when multitasking a mixture of Win16 and Win32 applications.






            share|improve this answer




















            • 14





              Windows 95 is pre-emptive multitasking. It was, in fact, one of the major design goals of Windows 95.

              – user
              Jul 1 at 10:19











            • WIN95 from Packard Bell was awesome in all the featured apps they included . THey also used low DPI ball mice back in those days that needed more smoothing.= from averaging. Now laser mice are much higher DPI and can wake up my WIn7 just by tingle vibration on the couch or table with mouse.

              – Sunnyskyguy EE75
              Jul 1 at 20:31











            • @SunnyskyguyEE75 Funnily enough most wireless mice sidestep that issue because they themselves go to sleep and require significant movement to wake up.

              – Bob
              Jul 3 at 2:24











            • Not mine @Bob As soon as I sit on the couch with mouse at the end not moving, big screen TV turns on which is connected to computer, as it comes out of sleep mode, instantly. M185 LOgitech That doesn't even move the cursor when it's awake.1 AA cell, going on 1 year now., and it is used many hours daily.

              – Sunnyskyguy EE75
              Jul 3 at 2:40














            -3












            -3








            -3







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



            On cooperative multitasking, the foreground app has to yield control to other tasks. Thus if the foreground app got stuck, the whole machine froze.



            Preemptive multitasking, the system usually had a hardware interrupt, usually a timer, to force a yield.



            On Windows 95, the keyboard and mouse generated interrupts, moving the mouse caused the interrupt to fire and the OS to service it's event queue. A form of preemptive multitasking, instead of a fixed timer interrupt, you were doing it.



            The OS would update the status on screen at the interrupt and then go service the other tasks. The screen update would make it seem that the OS was processing faster.



            EDIT - 1/2 right ...
            Cannot pre-emptively multitask Win16 applications because it uses the same System Virtual Machine (VM) model as in Windows 3.1 to run Win16 applications. Thus, Windows 95 will revert to a cooperative multitasking environment when running Win16 applications and give them exclusive control of the CPU for as long as the applications are executing. As a result, true pre-emptive operation is impossible when multitasking a mixture of Win16 and Win32 applications.






            share|improve this answer















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



            On cooperative multitasking, the foreground app has to yield control to other tasks. Thus if the foreground app got stuck, the whole machine froze.



            Preemptive multitasking, the system usually had a hardware interrupt, usually a timer, to force a yield.



            On Windows 95, the keyboard and mouse generated interrupts, moving the mouse caused the interrupt to fire and the OS to service it's event queue. A form of preemptive multitasking, instead of a fixed timer interrupt, you were doing it.



            The OS would update the status on screen at the interrupt and then go service the other tasks. The screen update would make it seem that the OS was processing faster.



            EDIT - 1/2 right ...
            Cannot pre-emptively multitask Win16 applications because it uses the same System Virtual Machine (VM) model as in Windows 3.1 to run Win16 applications. Thus, Windows 95 will revert to a cooperative multitasking environment when running Win16 applications and give them exclusive control of the CPU for as long as the applications are executing. As a result, true pre-emptive operation is impossible when multitasking a mixture of Win16 and Win32 applications.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jul 2 at 10:42

























            answered Jul 1 at 10:00









            jimjim

            2682 silver badges5 bronze badges




            2682 silver badges5 bronze badges







            • 14





              Windows 95 is pre-emptive multitasking. It was, in fact, one of the major design goals of Windows 95.

              – user
              Jul 1 at 10:19











            • WIN95 from Packard Bell was awesome in all the featured apps they included . THey also used low DPI ball mice back in those days that needed more smoothing.= from averaging. Now laser mice are much higher DPI and can wake up my WIn7 just by tingle vibration on the couch or table with mouse.

              – Sunnyskyguy EE75
              Jul 1 at 20:31











            • @SunnyskyguyEE75 Funnily enough most wireless mice sidestep that issue because they themselves go to sleep and require significant movement to wake up.

              – Bob
              Jul 3 at 2:24











            • Not mine @Bob As soon as I sit on the couch with mouse at the end not moving, big screen TV turns on which is connected to computer, as it comes out of sleep mode, instantly. M185 LOgitech That doesn't even move the cursor when it's awake.1 AA cell, going on 1 year now., and it is used many hours daily.

              – Sunnyskyguy EE75
              Jul 3 at 2:40













            • 14





              Windows 95 is pre-emptive multitasking. It was, in fact, one of the major design goals of Windows 95.

              – user
              Jul 1 at 10:19











            • WIN95 from Packard Bell was awesome in all the featured apps they included . THey also used low DPI ball mice back in those days that needed more smoothing.= from averaging. Now laser mice are much higher DPI and can wake up my WIn7 just by tingle vibration on the couch or table with mouse.

              – Sunnyskyguy EE75
              Jul 1 at 20:31











            • @SunnyskyguyEE75 Funnily enough most wireless mice sidestep that issue because they themselves go to sleep and require significant movement to wake up.

              – Bob
              Jul 3 at 2:24











            • Not mine @Bob As soon as I sit on the couch with mouse at the end not moving, big screen TV turns on which is connected to computer, as it comes out of sleep mode, instantly. M185 LOgitech That doesn't even move the cursor when it's awake.1 AA cell, going on 1 year now., and it is used many hours daily.

              – Sunnyskyguy EE75
              Jul 3 at 2:40








            14




            14





            Windows 95 is pre-emptive multitasking. It was, in fact, one of the major design goals of Windows 95.

            – user
            Jul 1 at 10:19





            Windows 95 is pre-emptive multitasking. It was, in fact, one of the major design goals of Windows 95.

            – user
            Jul 1 at 10:19













            WIN95 from Packard Bell was awesome in all the featured apps they included . THey also used low DPI ball mice back in those days that needed more smoothing.= from averaging. Now laser mice are much higher DPI and can wake up my WIn7 just by tingle vibration on the couch or table with mouse.

            – Sunnyskyguy EE75
            Jul 1 at 20:31





            WIN95 from Packard Bell was awesome in all the featured apps they included . THey also used low DPI ball mice back in those days that needed more smoothing.= from averaging. Now laser mice are much higher DPI and can wake up my WIn7 just by tingle vibration on the couch or table with mouse.

            – Sunnyskyguy EE75
            Jul 1 at 20:31













            @SunnyskyguyEE75 Funnily enough most wireless mice sidestep that issue because they themselves go to sleep and require significant movement to wake up.

            – Bob
            Jul 3 at 2:24





            @SunnyskyguyEE75 Funnily enough most wireless mice sidestep that issue because they themselves go to sleep and require significant movement to wake up.

            – Bob
            Jul 3 at 2:24













            Not mine @Bob As soon as I sit on the couch with mouse at the end not moving, big screen TV turns on which is connected to computer, as it comes out of sleep mode, instantly. M185 LOgitech That doesn't even move the cursor when it's awake.1 AA cell, going on 1 year now., and it is used many hours daily.

            – Sunnyskyguy EE75
            Jul 3 at 2:40






            Not mine @Bob As soon as I sit on the couch with mouse at the end not moving, big screen TV turns on which is connected to computer, as it comes out of sleep mode, instantly. M185 LOgitech That doesn't even move the cursor when it's awake.1 AA cell, going on 1 year now., and it is used many hours daily.

            – Sunnyskyguy EE75
            Jul 3 at 2:40






            protected by Community Jul 4 at 15:22



            Thank you for your interest in this question.
            Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



            Would you like to answer one of these unanswered questions instead?



            Popular posts from this blog

            Category:9 (number) SubcategoriesMedia in category "9 (number)"Navigation menuUpload mediaGND ID: 4485639-8Library of Congress authority ID: sh85091979ReasonatorScholiaStatistics

            Circuit construction for execution of conditional statements using least significant bitHow are two different registers being used as “control”?How exactly is the stated composite state of the two registers being produced using the $R_zz$ controlled rotations?Efficiently performing controlled rotations in HHLWould this quantum algorithm implementation work?How to prepare a superposed states of odd integers from $1$ to $sqrtN$?Why is this implementation of the order finding algorithm not working?Circuit construction for Hamiltonian simulationHow can I invert the least significant bit of a certain term of a superposed state?Implementing an oracleImplementing a controlled sum operation

            Magento 2 “No Payment Methods” in Admin New OrderHow to integrate Paypal Express Checkout with the Magento APIMagento 1.5 - Sales > Order > edit order and shipping methods disappearAuto Invoice Check/Money Order Payment methodAdd more simple payment methods?Shipping methods not showingWhat should I do to change payment methods if changing the configuration has no effects?1.9 - No Payment Methods showing upMy Payment Methods not Showing for downloadable/virtual product when checkout?Magento2 API to access internal payment methodHow to call an existing payment methods in the registration form?