442

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 searched for it, I couldn't find anything related.

Sorry for the vague explanation.

user3840170
  • 23,072
  • 4
  • 91
  • 150
user2652379
  • 2,040
  • 3
  • 7
  • 7
  • 36
    It's probably just perceptual, moving the mouse would for sure trigger more screen updates and look smoother than when not moving it. – Eric Cartman Jul 01 '19 at 07:26
  • 2
    @Aybe You might be right. – user2652379 Jul 01 '19 at 07:50
  • 79
    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 01 '19 at 16:26
  • 10
    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 01 '19 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 04 '19 at 09:02
  • 3
    This question seems to have really gotten out there - cross-posted to all kinds of other sites. 162k views and counting - more than 3x the next question in RC, ever! And highest question score and highest answer score too! Based on some other questions that I've been +1'd on lately, I think it is actually bringing some new "real" users - i.e., not just clicking to the one question. Thank you user2652379 – manassehkatz-Moving 2 Codidact Jul 04 '19 at 15:53
  • 1
    I remember programming bare DOS (no EMM386 etc. messing with stuff) and using the "hlt" instruction for timing, so it'd pause every timer tick at 18.2 times per second, since the hardware interrupt of the timer would break out of the hlt instruction, but swirling the mouse around created many more hw ints, so everything would speed up. – Arthur Kalliokoski Jan 22 '21 at 18:35

8 Answers8

514

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.

Dessa Simpson
  • 103
  • 3
user
  • 15,213
  • 3
  • 35
  • 69
  • If that's the case, is modern OS like Windows 10 might still have this (very tiny) effect too? – user2652379 Jul 01 '19 at 09:49
  • 50
    @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 01 '19 at 10:18
  • 134
    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 01 '19 at 16:52
  • 32
    Raymond Chen explains a similar bug: https://devblogs.microsoft.com/oldnewthing/?p=36423 – snips-n-snails Jul 01 '19 at 22:23
  • 1
    I don't recall this issue with Windows NT, even version NT 3.5. Maybe it was just a windows 3/95 code base issue. – Ian Ringrose Jul 01 '19 at 23:11
  • 3
    That's why you get an optical mouse and swing from a pendulum next to a suitable background, to generate keel-alive messages... ;-) – Dronz Jul 01 '19 at 23:36
  • 11
    @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 02 '19 at 07:17
  • I might be imagining it, but I seem to recall there was a device that emulated a mouse moving back and forth by 1 pixel specifically to speed up this kind of thing. – user Jul 02 '19 at 08:00
  • 16
    @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 02 '19 at 08:04
  • 2
    This reminds me of a story about an ancient multi-user system that prioritised interactive applications over large batch jobs. It distinguished between them by listening to keyboard events from the terminal it came from. So if you had to run a big job, you could speed it up by mashing a key on your terminal. – mcv Jul 03 '19 at 13:28
  • 2
    "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" -- err, that's synchronous IO. Async IO means the application does NOT go to sleep and can go off and do something else and be notified through an interrupt/signal/message that some event like IO completion has occurred. – aaa90210 Jul 03 '19 at 19:53
  • @aaa90210 it's async, because the app doesn't have to busy poll to keep checking if the operation finished, and the call to the DLL/kernel doesn't block. Async is the terminology that Microsoft uses. – user Jul 04 '19 at 08:08
  • 2
    @aaa90210 It's async because it doesn't have to go to sleep. In synchronous calls (like most traditional Unix calls) the application has no say in whether it goes to sleep or not, it's automatically blocked until the operation is complete. There's no polling by the application in a synchronous operation. – JeremyP Jul 04 '19 at 10:32
  • My assumption is that it's a combined effect with the PS/2 port (keyboards and mice used these inputs prior to USB) and how it generates system interrupts on user input. Newer usb devices do not. – NodeNodeNode Jul 08 '19 at 15:36
  • 2
    In modern times this is making a come-back for power saving. – user Mar 31 '20 at 09:54
  • The last paragraph woke my memory of adult techies moving the mouse every now and then while installing Office or some Adobe thing, and when I ask, they said 'to prevent machine hanging'... Now I think the real purpose of that mouse move is to accelerate the tedious installation, both psychologically and technically... – Fred Qian Nov 11 '22 at 00:44
109

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.

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 15
    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 01 '19 at 09:50
  • 74
    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 Hoagie Jul 01 '19 at 15:13
  • 73
    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 01 '19 at 18:35
  • 4
    on my Windows 10 computer with notepad, the selection doesn't scroll at all if I don't move my mouse. – qwr Jul 01 '19 at 21:26
  • 5
    Same on Windows XP with Notepad - no movement, no scroll. But TextPad does scroll, so the behavior is application-dependent. – Bruce Abbott Jul 01 '19 at 23:54
  • 2
    Come to think of it, I wiggled my mouse when dragging down the fill handle in Excel. Maybe this is one of the cases? – user2652379 Jul 02 '19 at 01:15
  • 4
    not the best example, because mouse wiggling and text selection are both UI functions, unlike installing programs and loading webpages – szulat Jul 02 '19 at 08:25
  • @szulat Webpages are even more about UI functions, as they involve tons of drawing - but more important the example is meant to be most easy reproducable. It works without any additional features like internet or large installation media, it works with each and every Windows installation since the very first. – Raffzahn Jul 02 '19 at 11:21
  • 19
    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 02 '19 at 12:03
  • 1
    This is not about the OS, this is about the mouse. If you move the mouse an acceleration will be detected and the page will scroll faster. You can check this by going into the mouse setting, set the acceleration and speed to the maximum and seeing that when you try again, the text will scroll even faster when you move the mouse. – ChatterOne Jul 03 '19 at 09:28
  • @ChatterOne That acceleration is about the mouse messages, and a rather new add on. Back then there was no such setup, still the effect was there. Just go and boot up some Windows 3.x – Raffzahn Jul 03 '19 at 20:24
  • 20
    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 03 '19 at 20:29
  • 1
    @ChatterOne What? In what possible sense is this "about the mouse" and not the OS? – Rag Jul 04 '19 at 03:25
  • 3
    The example is false. That's just a quirk of how the MS Edit control works, as Notepad is just a host for one with some code to save and load, and has nothing to do with how much time the thread is being given and therefore making it scroll faster. – James Jul 04 '19 at 05:48
  • @Raffzahn My point was that it's about detecting mouse movement in a specific area, it's not related to the OS performance itself. There's an area where the mouse movement is detected and if you move the mouse in that area the text will scroll. The reason why it scrolls is because you have the cursor following the mouse movement. Yes, you have a cursor also when you cannot type. Even in OS X if you are in an area just below the window it will scroll slowly, but further away it will scroll faster. We can debate whether this is implemented properly or not, but it's still not related to the OS. – ChatterOne Jul 04 '19 at 06:42
  • 1
    This answer is absolutely different from the top answer. – Nakilon Jul 04 '19 at 07:45
  • 2
    This effect also happens in most X11 apps supporting mouse text selection on Linux, so it's not really related to the way Windows works, even less so to its early versions. – Ruslan Jul 04 '19 at 15:14
  • 8
    This is wrong. Yes, wiggling your mouse while drag-scrolling does cause the drag-scroll to happen faster, but it's not related to the question. I don't think the drag-scroll speed is related to machine speed. We probably can't undo 90 votes... @Raffzahn, could you put an UPDATE: line in your answer that takes all these comments into account? – daveloyall Jul 05 '19 at 17:14
42

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.

Thomas
  • 3,842
  • 18
  • 25
  • 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 01 '19 at 23:14
  • 5
    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 02 '19 at 10:11
  • 1
    Yeah, NT originally started from MS working with IBM on what was supposed to be OS/2's successor, "NT OS/2". I can't remember what happened, exactly, but it led to Microsoft taking it and releasing it as its own product, tying it into the Windows line even though it was a full-fledged OS instead of just a glorified GUI (and basing a sizable chunk of 9x on stuff ported from NT, IIRC). – Justin Time - Reinstate Monica Jul 09 '19 at 19:10
27

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/

Cactus
  • 2,700
  • 14
  • 43
Tinic Uro
  • 279
  • 2
  • 2
  • 4
    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 - on strike Jul 04 '19 at 04:43
22

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!

Cactus
  • 2,700
  • 14
  • 43
rwbaskette
  • 345
  • 1
  • 3
  • 1
    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 Jul 07 '19 at 08:43
  • 3
    That blog post is about the intended, documented behavior of MsgWaitForMultipleObjects, and some buggy user code that calls it incorrectly. While it's plausible that some installer could have had a bug along those lines, it would malfunction in the same way on every version of Windows, because the API is supposed to behave that way. – benrg Dec 05 '19 at 00:02
18

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.

Cody Gray - on strike
  • 1,554
  • 14
  • 21
Dmitry Grigoryev
  • 452
  • 3
  • 9
  • 3
    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: https://devblogs.microsoft.com/oldnewthing/?p=36423 – snips-n-snails Jul 03 '19 at 20:53
4

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.

karmafunk
  • 149
  • 2
-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.

jim
  • 386
  • 3
  • 5
  • 18
    Windows 95 is pre-emptive multitasking. It was, in fact, one of the major design goals of Windows 95. – user Jul 01 '19 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. – Tony Stewart EE75 Jul 01 '19 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 03 '19 at 02: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. – Tony Stewart EE75 Jul 03 '19 at 02:40
  • 2
    @user Windows 95 supported preemptive multitasking for Win32 software, but Win16 software was still cooperatively multitasked, and most installers were 16-bit. If this problem was specific to installers, as OP suggests, then it could easily have been due to some Win16-specific problem. – benrg Dec 05 '19 at 00:11