Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

retrocomputing.stackexchange.com

Post reply on HN
Print view View original

171–180 of 201 posts

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

#171

Post by kllrnohj »

kees99 wrote: post #98

A somewhat similar effect is alive and well on Android: background processes run measurably faster while user holds/moves their finger across the screen, and couple of seconds thereafter. Mechanism is a bit different though: SufraceFlinger process that is responsible for acquiring touchscreen input, temporarily boosts CPU and GPU frequencies to make sure screen animations are nice and fluid.

> A somewhat similar effect is alive and well on Android: background processes run measurably faster while user holds/moves their finger across the screen

Only if they do not have enough load, that is. If you have an actually loaded background process on Android it by itself will keep the clocks high. If you have a process that has short bursts of work, though, then the duration of that burst will definitely vary in response to touch boost. This is all the same as "regular" linux as it's just an aspect of most governors (ondemand, interactive, etc...)

As in, touching the display will never make this loop go faster:

    void busyLoop() {
        Random rand = new Random();
        int data[] = new int[1000];
        for (int i = 0; i  {
                for (int i = 0; i
The hypothetical measure will observe duration to normalize to a number and then it'll stay roughly there until thermal throttling kicks in.

If, however, the loop was to look more like this:

    void busyLoop() {
        Random rand = new Random();
        int data[] = new int[1000];
        for (int i = 0; i  {
                for (int i = 0; i
Then you would see the measured duration decrease when your finger was on the screen vs. not, because the kernel will consistently see that the task is not keeping the CPU it's scheduled on loaded above a threshold, so the clocks will go down all the way to idle.

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

#172

Post by kllrnohj »

the-dude wrote: post #80
achandlerwhite wrote: post #55

Earlier quoted context omitted.

Note he said 100hz not mhz. Essentially 100 times per second the message queue would process but if you moved the mouse it would process faster.

And the BSDs and Linux also have the HZ parameter for scheduling and for a long time the default has been as low as 100 Hz. Not sure what the current status quo is.

Linux's default varies per architecture & platform. For a long, long time on ARM it still defaulted to 100hz. I think it's more like 250hz or 500hz now? You'll also see x86 desktop-focused build set it to 1000hz.

But scheduling happens far more often than this tick rate, too, so it's only preemption for busy threads and controls the timing windows for things like DVFS.

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

#173

Post by userbinator »

Sorry, but I'd just like to point out that top answer (about async I/O in Win95) is wrong and sounds like someone repeating something he (mis)heard once.

I actually wrote apps in the Win95 days, and I can say that async (i.e. overlapped) I/O, which seems to be what he's talking about in the rest of the answer about IO completions, basically does not exist at all on the Win9x series; it was an NT-exclusive feature. There were some bits and pieces that seemed to work somewhat from what I remember, but to quote my trusty old WIN32.HLP regarding the ReadFile function:

"Windows 95

For asynchronous read operations, hFile can be a communications resource, mailslot, or named pipe handle opened with the FILE_FLAG_OVERLAPPED flag by CreateFile, or a socket handle returned by the socket or accept functions. Windows 95 does not support asynchronous read operations on disk files."

...so his example about file copying and installers is invalidated. The correct answer(s) are of course lower down on the page and in the comments, where everyone talking about "pumping the message loop" gets it right.

The second anecdote about scrolling behaviour also hits vaguely beside the point; it has nothing to do with multitasking, is only tangentially related to "pumping the message loop", and can be explained very simply: moving the mouse causes a WM_MOUSEMOVE message to be sent to the window, containing the new coordinates of the cursor. The edit control that Notepad is composed of handles this message when in selection mode by checking if the position is outside of the control, and scrolls appropriately by a single amount if so. If you continue moving the mouse outside the control with a selection highlighted, the generation of WM_MOUSEMOVE continues, and thus the scrolling too. Stop moving the mouse, and the scrolling stops. There is nothing else to it. Other controls/windows (e.g. browsers) may handle this select-scroll behaviour differently; some will start a timer that continues to issue scroll messages as long as you hold down the button, and some even fancier ones will vary the rate of the timer depending on how far from the control's edge the current position is (so you can adjust the auto-scrolling speed easily.)

Only the third answer is when we start getting closer to an accurate explanation, the fourth answer about WM_TIMER is quite off-the-mark, and then the rest of them vary in accuracy between "close, but not quite" and "no, just no."

(Incidentally, this is also one of the reasons I don't use SE/SO.)

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

#174

Post by userbinator »

chris_wot wrote: post #137

There was a KB article where an old very of Microsoft Query (?) ran slowly. The second solution said to move the mouse around whilst the query ran. Funniest article I’ve ever seen in the Microsoft KB! But it worked.

This one? https://news.ycombinator.com/item?id=7011228

Unfortunately KB articles seem to be decaying at an alarming rate; only the archive has luckily saved this one from vanishing forever: http://web.archive.org/web/20140105042459/http://support.mic...

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

#175

Post by Nition »

delinka wrote: post #129
wongarsu wrote: post #104

Earlier quoted context omitted.

When I implement progress bars I most often implement "pessimistic progress", so "considering all timeouts, worst case we are 46.5% (of the time) to some result", with an update every few hundreed milliseconds. As possible mix in data from completed subtasks. Nobody ever complains if the process suddenly speeds up because progress was made before the timeout, as long as your initial estimate wasn't absurd (looks at W…

Absurd initial estimate? All of the estimates tend to be absurd. Done in 30s ... I mean 15min ... ah, 10s ... 1hr 7min ... Oh, come _on_ ...

Windows 95/98 used to occasionally do some particularly insane estimates. I took this screenshot many years ago of copying a tiny NetHack install between drives: https://i.imgur.com/q7tc9R1.png

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

#176

Post by darkpuma »

yokohummer7 wrote: post #52
UI_at_80x24 wrote: post #13

This wasn't just restricted to COM port based I/O either. Back then I had a Logitech bus mouse. The mouse was connected directly to an ISA card, and didn't use the COM ports as most mice did back then. (I needed the extra COM port/IRQ for my modems.) I too witnessed the 'windows is running slow when installing' bug. I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled fo…

> I often would use the mouse cursor to 'mark' the position of the loading bar (we really are spoiled for speed these days). This is just me, oh my gosh. I thought I was the only one who did that. But now I come to think about it, it can't be true. It has been a really long time since I used that technique last time...

Shit, I think I last used it last week! In my GUI wrapper for rsync while transferring some large files. It took about 45 minutes for one of the files.

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

#177

Post by snupples »

derefr wrote: post #170
inlined wrote: post #116

Earlier quoted context omitted.

True! I know some of the people involved in the windows update bar. Since cpu and dusk are so different across devices it’s hard to know actual time it will take. Instead teams divided their packages into theoretical weights and the progress bar showed the percent of total “weights”. That’s why it can be choppy is packages with few subdivisions have little to interpolate.

With a process that happens on regular intervals like a Windows Update, I always wondered why the system doesn't store metrics on how long the process has historically taken on previous runs, and then just uses a weighted average of historical times as a time-based total estimate, converted into a divisor for work-based progress estimates (i.e. if previous runs took 60 minutes on average, then progress at 25% would s…

Not sure if anyone's mentioned this yet, but the old original Mac OSX boot screen had a progress bar that was based on the exact length of the previous boot time.

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

#179

Post by AgentME »

_trampeltier wrote: post #16

From a comment: 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…

I've implemented the behavior of "scroll the field down while the user is holding something selected" before, and my initial implementation had this bug, so I think I can explain a likely reason this happens. My code listened to mouse movement events, and if a selection was present and the mouse was moved into the top or bottom regions of the scrollable area, then the area would scroll a bit, and a recurring timer for some number of milliseconds would be started (if already active, then it would be reset) which would case the area to scroll a bit more. (This timer would be canceled if the mouse was moved out of the auto-scroll region.) If you continually moved the mouse, then it's possible the application would get the mouse movement events at a higher rate than the timer would fire, so the scrollable area would scroll faster. I think I found out that the platform would emit the mouse movement events at up to 60fps, so I just tweaked the timer to match that. Not a perfect solution, maybe I'll update it eventually to check the system time and scroll slower if the mouse move events are arriving faster than the timer.
Post reply on HN