Why Moving the Mouse in Windows 95 Made the OS Faster

If you’ve computed for a long enough period of time, chances are you’ve seen some weird stuff. For example, I once had an HP printer that and I swear to God, I’m not kidding would only print when turned off. It would sit, placidly mocking your attempts to send print jobs to its damnable, hellspawned queue, until you actually hit the power button to shut the printer down. Upon being deactivated, the spiteful ink-swilling beast would print a single document. If you needed to print multiple documents, you had to turn the printer on and off in between each one. This behavior persisted through multiple OS installations and several motherboards.

One of the rumors I remember hearing about Windows 95, long long ago, was that moving the mouse during long application installations could boost installation speed. It always seemed faintly ridiculous, though the idea of your mouse having an impact on system performance wasn’t, as anyone who ever tried a USB 1.0 mouse can attest. In the early days of USB 1.0, it was possible for mouse-clicks to interrupt your CPU and for your mouse to be completely unresponsive when your CPU was under heavy load. Fun times.

According to a post at Stack Exchange, via PC Gamer, this was one rumor with some actual truth to it. Stack Exchange user “user” explains:

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.

It would seem that whether one observed this effect in action likely depended on how the installer was written, but the fact that there was a real effect in the first place is kind of hilarious. Even today, this kind of thing isn’t completely unknown. In the PC version of the original Dead Space, your saved game reload rate is tied directly to the game’s frame rate. If you want to load games more quickly, disable V-Sync (this may require Nvidia Inspector, I don’t honestly recall). I found this issue myself and tested it years ago. If it takes 45 seconds to load a saved game with a 30fps locked frame rate, and you run the game at 240fps unlocked, it’ll take 5-6 seconds to load your game. My working theory is that the game only completes a certain amount of I/O work per frame and that this is hard-coded in the engine. Speed up the frame rate, and you speed up I/O.

It’s not exactly the same as this old Windows 95 issue, but it’s a similar idea. Anybody got any other weird, surprising, or interesting tales of random computer hardware?