Why did moving the mouse cursor cause Windows 95 to run more quickly? | Hacker News Reader

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

retrocomputing.stackexchange.com

1,188 pointsfolli196 comments

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 for speed these days). That way when I would walk-away from an install I could see if the progress meter moved while I was away. More often then not the progress bar would still be where it was when I had left. By moving the mouse activity would return and the installation would continue.

I always assumed it was the graphics that were not being updated. A small bug with the install would keep running but the lack of input interrupts caused the display to get 'stuck'. (That would explain the sudden 'jump' in progress bar movement as soon as I wiggled the mouse.)

Get off my lawn!

But what newbies will bever know the heck of: dip switch settings for IRQ for modems.

Thats what literally got me into computers...

In order to dial up BBSs and play tthe Pit and dl warez.

—-

Ive told this story before, but in about 1992? Or so - i got grounded for a month because i had been calling in long distance to a bbs in san jose to play the pit - and racked up a long distance bill of $926 - my dad was livid.

He yelled at me and said “why are you wasting all this time with computers! Its never going to do anything for you!”

Years later after i became successful with yee olde computerz! He apologized to me and said “im sorry i yelled at you for that time you cost me all that money in long distance charges.”

I also got yelled at by my dad for racking up long distance charges in 1991 or 92 but in my case it was only about $150 for calling the Sierra BBS to download stuff for King's Quest games or something :)

Wonderful!

Were you also calling into PCLink?

I used to have a challenge with my best friend at the time:

We used to call 411 and challenge to whom could keep the 411 operator on the phone longest.

Same here, except it was San Jose to San Jose. However still had a bill because I was in Zone 1 and the BBS was in Zone 3 (phone book tells you which zone) So.. charges. Dad wasn't mad, I think he realized I was going to get a job in the field.

You up-dadded me!!!

> Ive told this story before, but in about 1992? Or so - i got grounded for a month because i had been calling in long distance to a bbs in san jose to play the pit - and racked up a long distance bill of $926 - my dad was livid.

I had this problem until I discovered a bug in a Major BBS door game (TradeWars 2002) that let me have unlimited BBS credits. No more charges on my moms phone bill and even was able to trade those for other things in real life. Early bitcoin in a way. Looking back on it, my need to get online overrode my ethics regarding either my moms bank account or the sysops running the BBS. Oh well.

I've told the exact same story. Weird.

Also $926?

Doubtful - I was calling from Tahoe City California to San Jose California...

And it was a summer month long binge on PCLink and BBSs...

(I later convinced my highschool to install a CAD network on which we installed a BBS Called Heaven and Hell and ran a warez site from there....

Fun times.

EDIT: Oh -- and it was run on an EverexStep Cube machine... I think it was a 386?

"Years later after i became successful with yee olde computerz! He apologized to me and said “im sorry i yelled at you for that time you cost me all that money in long distance charges.”"

At which point you lit up your Havana Muy Gordo with a $1000 bill and said, "Don't sweat it?"

Similar but earlier story... staying up late at night or waking up early before school to login to BBS's. First with a Practical Peripherals modem that my dad acquired to dial into his business (which still used teletype). I got myself a Hayes 2400[1] and convinced my dad to get the fixed calling within your area code which I mostly paid for with my part-time work. I tried to stay within my LATA which included Sherwood Forest, Camelot, some others with doors and FIDO that can't recall. And then I made a mistake and on the advice of another BBS'er tried one in what I thought was a neighboring LATA. It was great! Active! Doors! gFiles! Warez! But was actually zones away in Texas. I had a good old time until the bill came. My Dad was purple he was so angry and I worked a lot of odd jobs to pay that off.

. .

[1] somehow just before college I got a used USR Courier HST. Then I sent it in with what was probably all of my hard earned beer money for upgrade to a Courier v.Everything... I still have that one, found it while moving https://v.gd/gF83mM)

> But what newbies will bever know the heck of: dip switch settings for IRQ for modems.

And dip switches to set hard drives to primary/secondary. Get that wrong and your machine didn’t boot.

those were jumpers :)

And making sure ATM0(?) was sent so that the modem was quiet...

One time I was installing Windows 95, I had to move the cursor the whole time because otherwise the installation got stuck. I discovered this after at least 30 tries.

I remember having this exact some experience once before! I'm glad I wasn't the only one.

> 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...

What ? I still do that at least once a week/month.

Last time it was for the linux dropbox updater, last week.

I am also a fan of using another window so I can use the mouse and still have a marker to monitor progress.

Today everything goes so fast that it's faster to kill and restart if it's not visibly moving, IMHO

I guess what has changed is me, not the computing environment. When I was young, I easily grew impatient when things were going slow. Nowadays I still kinda feel nervous, but not to the point to warrant such bookkeeping methods.

My urge to measure everything has only grown with age. I don't chalk it up to nervousness though. I'd say it's driven by curiosity and and a desire to forecast.

I do this all the time too, but unfortunately many processes today only go around in circls instead of showing the actual progress.

to be fair, "actual progress" is almost always a misnomer anyway.

I find the Progress bar is usually about as accurate as the Time Remaining calculation. Both are better than nothing but more of a fiction than reality.

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 Windows Explorer). Even a naive progress bar counting down the 60s timeout is more informative and satisfying to watch than an endless spinner.

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

Vista, I think it was Vista, "fixed" that by adding an estimation pass first, that often took longer than the copy itself, and was almost as bad at estimating. It sometimes took much longer. The fix was far worse than the problem, yet it survived unchanged.

It was so bad I ended up discovering Teracopy which was decent at estimation, and far faster at copying. Was a must-have until I migrated away from Windows.

How exactly do utilities like Teracopy implement high-performance copying? In other words, what are the performance bottlenecks in explorer.exe? Personally, I've observed that:

1. Explorer attempts to do a file enumeration prior to copying, which sometimes could waste a lot of time.

2. It seems tools like Teracopy use buffering aggressively, which can speed up the copying significantly based on my experience on Windows XP with slow HDDs.

Are there any other points worth noting?

Single pass and aggressive buffering seems to cover what I remember, but it worked better than it I expected, even on high speed drives or SSD to high speed drive. They may have had other tricks, it's been a while now.

The other thing that I liked is it's non-blocking - you can continue doing copies while one is in progress, if it's to the same destination it gets added to the queue in progress. If different destination it goes in a new queue that waits for the first to finish.

We used to call these "Microsoft Minutes"...

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.

Progress indicators that moving perfectly and steadily are probably time based, but I'd have thought they've always been work based. Example: you know you have to copy 20GB across the network; update the progress bar with 'percent of data complete' periodically (on a timer, in the byte copying loop, whatever.)

I've seen dual progress bars: one for "overall progress" (each one of five tasks fills this bar 20%) and one for the current task (maybe downloading, maybe unpacking, maybe copying, maybe waiting for hardware to reply...)

We pushed "progress bar" data to the client via SignalR once x% of a slow moving process were complete.

I've written progress bars that combine all of the above. Each sub-task had a weight though, and adaptive interpolation was used to animate the progress bar between chunky updates from less granular tasks based on how far they usually increment over which time interval.

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 say "45 minutes remaining", then if it suddenly jumped to 50% would immediately say "30 minutes remaining." Even if they're choppy, those time estimates would actually be correct if you sampled and averaged them.)

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.

A couple of weeks ago, I marked the (no)progress bar on a macOS update with a piece of surgical tape.

Thank you for posting a physical marker; I was afraid I was the only person that's done so.

I've been known to use Post-its and the frame of my monitor as a marker. Both are much easier with how prevalent dual-monitors are these days.

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.

>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 for speed these days).

Most software doesn't feel any faster compared to Windows 95 (see Wirth's law). Also most shitware does not display a loading bar anymore, instead you get some spinning stuff that's just an animation.

> Also most shitware does not display a loading bar anymore, instead you get some spinning stuff that's just an animation.

In fairness, that's because users constantly complained about loading bars not being accurate (they'd freeze, change speeds, stop right at the end etc.), but having a "true" loading bar that proceeds smoothly basically requires solving the Halting Problem. So out it went.

Let them complain and ignore it.

Was this a win95 only bug? I remember doing the mouse thing on 98 as well.

I mean, I still do the mouse thing all the time, regardless of OS. Not because I actually expect it to go faster, mind you, but rather because I'm bored.

> That way when I would walk-away from an install

But a few minutes later you'd be back to swap in floppy number 18

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 previous employer of mine explicitly requested this behaviour in their app. The app showed a map, and could align map north with compass north; to save battery, it would drop to an incredibly low frame rate (1fps?) about one second after your finger left the screen. It achieves the power goal, and has a high rating in the App Store, so I learned something about user requirements and being humble from this experience.

Question (I don't know how Android works) -- how is there even a "frame rate" for a map that isn't moving? Shouldn't it not be doing anything at all when nobody is touching anything?

> could align map north with compass north

Maybe the map turns as you turn so as to maintain compass north.

Just to confirm: yes, that is exactly what I meant.

Oh I see, it was supposed to align in real time, I missed that. Thanks.

I assume you might need it for the “person” icon while the user moves around the city?

Most maps these days are rendered via OpenGL (or Metal) and in those cases you still manually flip buffers and order GPU to render a frame. It's possible to control this process to avoid exessive power usage.

Of course, for most developers that might mean to not update/invalidate() a map view constantly :)

> 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 < data.length; i++) {
            data[i] = rand.nextInt();
        }
        while (true) {
            measure(() -> {
                for (int i = 0; i < data.length; i++) {
                    data[i] = (data[i] * 4) % 1000;
                }
            });
        }
    }

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 < data.length; i++) {
            data[i] = rand.nextInt();
        }
        while (true) {
            measure(() -> {
                for (int i = 0; i < data.length; i++) {
                    data[i] = (data[i] * 4) % 1000;
                }
            });
            try {
                Thread.sleep(5);
            } catch (InterruptedException ex) {}
        }
    }

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.

Further, when installing, it would hang at some point without any sign of a prompt but would instantly continue if the mouse were moved. You could easily test this - turn your mouse upside-down during install and wait (to avoid any incidental mouse motion due to desk vibration etc).

Told my IT friend who was loading my machine and he said "you're confused; I've installed hundreds of times and never seen that". So I turned his mouse upside down and waited. Voila! It hung.

I recall quite a few times having to send a message to the message queue in code I'd written for this reason. I forget why though - someone can probably remind me, if I didn't send a message it would just stop.

Here I was thinking this was some sort of urban myth caused by superstitions in an age with less abundance of easily accessible tech information.

Guess I owe my dad an apology now.

It looks like you're not the only one! From the comments on the top response: > "If true, I owe some baby boomers apologies for things I said about 20 years ago"

Call him and tell him!

That's sweet. It will make his day.

I'm in your situation, I'm so impressed!

Me too. What a humbling slap-in-the-face, no? Sometimes when an idea sounds silly, and comes from a less technical person, one might disregard it even though it's easily testable/provable.

I love these kind of issues, here are two classics:

- Open Office won't print on Tuesdays: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...

- Can't send email more than 500 miles: http://web.mit.edu/jemorris/humor/500-miles

One thing about the famous "500 miles" post that I realized doesn't make sense:

----

An odd feature of our campus network at the time was that it was 100% switched. An outgoing packet wouldn't incur a router delay until hitting the POP and reaching a router on the far side. So time to connect to a lightly-loaded remote host on a nearby network would actually largely be governed by the speed of light distance to the destination rather than by incidental router delays.

Feeling slightly giddy, I typed into my shell:

$ units 1311 units, 63 prefixes

You have: 3 millilightseconds You want: miles * 558.84719 / 0.0017893979

----

But surely for Sendmail to register a "connect" with a remote SMTP server would require at least one (or many?) round trips to the remote server, so one-way speed of light time doesn't seem like it would really be relevant. Am I missing something?

Possibly the introduction wherein the author says:

"The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining."

If memory serves he goes into further detail about the alterations and some common objections to the story in his FAQ:

https://www.ibiblio.org/harris/500milemail-faq.html

I believe one version of this story explains that the math (and the situation) has been simplified for the sake of this story in order to make it readable.

Makes sense, I can share this story to people without any computer knowledge, but something explaining how connections are established would be wholly incomprehensible to them.

The speed of electricity in copper is lower than the speed of light in a vacuum. The speed of light in fiber optics seems to be even lower.

That last one is brilliant.

What in the world could possibly be the reason in that first story for the 'file' program to look for the string 'Tue' and change to the Jam filetype? That's gotta be a very niche case, right?

On that subject, don't make fun of people who paste screenshots into Word docs and email them. On Windows 95, that was a really good idea!

MS Word was one of the few ubiquitous tools that would compress images, and certainly one of the few that people could be counted on to know. MS Paint didn't support PNG until Win98, and even then wouldn't do it by default.

If you didn't go via Word, chances are you'd be emailing a 900kB BMP at a time when people used 28.8k modems to access Hotmail accounts with 2MB caps.

Also, MSPaint on Windows XP adds ".PNG" extension in uppercase which is also annoying.

I just send my dad an apology as well.

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 on your machine the speed up can be several times faster.

It's not just Notepad :-) I do this often, when I have to mark a lot of things.

Strange but mine doesn't scroll UNLESS I move the mouse. I wonder if this is because I have the "Adjust for best performance" option set?

It's not clear that this is caused by the same effect. A commenter suggests that this behaviour is actually due to how mouse acceleration affects scrolling speed which I am more inclined to believe.

Yeah there is no way this has anything to do with the same behavior. What's likely happening is there's a delay in auto-scroll, and by generating new mouse events your triggering manual scrolls at a higher rate (or in addition to?) than auto-scroll.

I think it is not acceleration, but rather a position of mouse relative to the edge of a window.

I think you'll find that Shift + Page Down is the fastest way to mark a lot of text, since you're doing it page by page instead of character by character.

Or, since GP said "mark all text", use Ctrl/Command+A.

Of course neither of these would demonstrate the effect they were talking about.

    ggVG

  ggVG

I typed that into Notepad and it did exactly what I expected: it displayed 'ggVG' in the edit window. I can even save it to a file!

Thank you for the tip.

It even works on my latest Firefox beta on Windows 10 (on this HN page). Hmm...They may not the same thing.

I had completely forgotten about the mouse-wiggling trick! It's just one of those things I used to do without thinking about it. It makes sense that an event loop was waiting for an event to fire.

I don't know the reason for that, but like the cursor to mark the progress bar method above, I do this trick to this day. You don't have to highlight first, you can just highlight as you go, wiggle the mouse outside of the bounds of the window, and then deselect when you get where you're going. And it's not just in Notepad, I do this in a programmers editor too.

Isn't it funny that many of us learned these sames ways of interacting with computers without being explicitly taught. If this were on the Internet, I would say it's a way to gauge whether you're a robot, but otherwise, it's just a measure of my impatience. Maybe it's just an acquired skill from growing up playing video games.

Are you suggesting it’s faster or slower when you wiggle the mouse? If it’s slower it could be because you put more events in the event queue that have to be pumped.

This applies to Macs as well. Or at least it used to, in some situations — now that I think about it, I can't really recall the last time I did that. The standard behaviour now seems to be scrolling faster the farther the mouse is from the edge of the pane (which is clearly a deliberate, and useful, UI decision).

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.

When I used to hang out at Radio Shack in the mall to play on a TRS-80's after school, they would draw a pair of asterisks in the corner of the screen and occasionally flash one of them on and off, as they loaded from cassette tape.

One of the older kids who hung out there would tell us newer kids that we could speed up loading by repeatedly pressing the up arrow key on the keyboard.

Of course us new kids didn't realize that the loading speed was completely determined by the cassette tape speed, which the keyboard couldn't possibly affect.

But at least it gave us something to do while waiting, and the older kids something to laugh at.

Reminds me back in the day using a file sharing/community program called Caraccho (for Mac) - similar to Hotline. Often people would queue up on someone's server (running of their desktop computer) to download a file since the server admin could set how many concurrent downloads from all users were allowed. Folks would send messages to people saying that if they hit Command-Q it makes the client run in "quick mode" which will speed up their download. Of course some folks would fall for this and you'd see their name drop off the server, moving everyone up 1 spot in the queue. Super effective for users that had not setup an avatar indicating they were new to the system and would fall for anything once.

Reminds me of the runescape cheat of alt+f4

I'm confident that the Alt+f4 cheat-code was around before Runescape ;) It was inevitably told to every new member at our LAN parties in the late 90s - the few who knew were often assigned admin duty to diagnose network/PC problems (which were frequent).

> Reminds me back in the day using a file sharing/community program called Caraccho (for Mac) - similar to Hotline. Often people would queue up on someone's server (running of their desktop computer) to download a file since the server admin could set how many concurrent downloads from all users were allowed. Folks would send messages to people saying that if they hit Command-Q it makes the client run in "quick mode" which will speed up their download. Of course some folks would fall for this and you'd see their name drop off the server, moving everyone up 1 spot in the queue. Super effective for users that had not setup an avatar indicating they were new to the system and would fall for anything once.

This was also common on IRC to get script kiddies to kick themselves.

https://en.wikipedia.org/wiki/Placebo_button

I'm surprised that article doesn't mention the "Close Doors" button on elevators. It is frequently disconnected and does nothing.

It is perhaps more appropriate to say the button frequently does nothing because you frequently lack the proper permissions... https://youtu.be/ZUvGfuLlZus

In my day, they told new people that Alt-F4 made all kinds of programs run faster, unlock cheat codes, etc. Especially the online games. You always knew the adventurers when you saw "has disconnected from game."

It's this bit of code:

    while(GetMessage(&msg, NULL, 0, 0) > 0)  
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

The mouse isr would cause a loop like this to execute at some point, processing all the messages on the queue. Win95 had preemption, but it ran at 100hz. Moving the mouse caused additional queue processing on top of the time sliced preemption.

At that time, it was more like the 75mhz range.

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.

For FreeBSD it's been 1000 for... ages, except for virtual machines, where it seems to be 100 by default.

Some guides for better battery life on FreeBSD recommend setting it to 100 Hz.

Tickless

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.

I thought the windows clock defaulted to ~60Hz. I understand it could be pushed up by software to 1Khz for audio players to work correctly. I may be very wrong on the latter point though.

Ah, the operant conditioning of software.

To this day, when waiting for some long or compute-intensive operation, I tend to instinctively move the mouse around. I guess this may be why.

Ironically, even though I grew up on Windows, I don't remember any actual case of "moving the mouse speeds thing up" on this OS - I only remember the infamous Linux cases (mouse move regenerates entropy, unblocking processes that got stuck when generating a random number call). But there must have been something, and I must have experienced it early enough in my childhood.

While running emacs over a modem to arpanet or dialup, I got into the habit of regularly typing ^A ^E to pace my cursor back and forth across the current line, to keep the connection and emacs warm.

(Like a caged leopard or mad scientist pacing back and forth.)

I could feel how responsive the connection and emacs were over time by the delay between typing and seeing the cursor move. Both the network and emacs contributed to the feeling:

There was the overall "weather" of the network: sometimes sunny and fast, sometimes sprinkled with light delays, and sometimes stormy congestion. Then there were occasional incidents that came and went, like network hiccoughs and emacs paging and grinding. And then there was the overall load of the system, which gave you the baseline delay (which gave it a very tactile day -vs- night feeling, since you got more of the machine to yourself during the night when it felt snappy, but it felt sluggish during the day).

It really felt like either the network, emacs, or both would fall asleep if you didn't keep them warm and lavish them with attention.

A VAX 11/780 running Gosling Emacs over a dialup had a very different feel than a PDP-10 running ITS Emacs over the arpanet. The busy VAX was bursty and had a lot of bumpy paging -- you had to keep your buffers warm or they would all get paged out and it would take a long time to wake back up, but there was no network delay from the direct dialup. While the PDP-10 ran smoothly like a well lubricated steam locomotive, sometimes slowing down when busy, but hovering around same speed instead of bursting, and the delay was mostly the feel of arpanet congestion and imps dozing off.

(Or so I imagined. I had a lot of time to sit and think while waiting for the cursor to move again, and the mind wanders and wonders what's happening...)

TOPS-20 had a wonderful ^T keyboard interrupt that you could type to instantly show the system load and time. (But of course you couldn't use that in emacs, which puts the tty into raw mode.)

Somebody at the university implemented ^T to 4.2 BSD on the cs department's busy VAX 11/780, by modifying the tty driver. But initially, there was no limit to how often you could type it, and calculating the current system load wasn't a trivial operation.

So on a fast terminal, if you held down and auto-repeated ^T, it would bring the entire system to its knees, and you could watch the load go up and up and up as you caused it to! Very satisfying indeed.

Eventually they put in a one-per-second limit on ^T.

> While running Emacs over a modem, I got into the habit of regularly typing ^A ^E to pace my cursor back and forth across the current line, to keep connection warm.

Huh. I got into that habit recently, because over the past year, I've been frequently working on the go, by SSH-ing to my home desktop and using Emacs terminal frame (emacsclient -t)[0]. I do regular "weather checks" with ^A and ^E - because the hardware has its weather, SSH has its weather, and the link I'm on has its own weather too (particularly when using an LTE hotspot, though I've noticed even when being in the same LAN, the response time is not always consistent).

What's old is new again :).

[0] - With terminal emulators supporting 256 colors, it looks very similar to the GUI Emacs. This mode of working is really quite good, and lets me use my underpowered sidearm 2-in-1 tablet/netbook to do things that would ordinarily require powerful hardware.

And you're continuously sampling the weather with every keystroke, not just when you're typing ^A ^E while you're thinking or spacing out.

After a million or so keystrokes and feedback delays, your brain can't help but build a model of what it means.

My ISP drops SSH connections (actually any TCP connections) that have been idle for too long. I have worked around that by adding

  Host *
  ServerAliveInterval <suitable number>

to my SSH client config. Works wonders.

> > While running Emacs over a modem, I got into the habit of regularly typing ^A ^E to pace my cursor back and forth across the current line, to keep connection warm.

> Huh. I got into that habit recently, because over the past year, I've been frequently working on the go, by SSH-ing to my home desktop and using Emacs terminal frame (emacsclient -t)[0]. I do regular "weather checks" with ^A and ^E - because the hardware has its weather, SSH has its weather, and the link I'm on has its own weather too (particularly when using an LTE hotspot, though I've noticed even when being in the same LAN, the response time is not always consistent).

You may find mosh [0] to be useful, as it buffers input client side to remove input lag.

[0]: https://mosh.org/

The ^T command is actually still around in Unix/Linux, but only when the program is reading input using canonical/cooked/non-raw mode. That's pretty uncommon these days, since input tends to be wrapped in readline or similar to allow for editing.

You can test it by running `ed`:

    ed scratch.txt
    2096
    ^T
    load: 0.57  cmd: ed 74469 waiting 0.00u 0.00s
    q

Running `stty -a` lists all of the characters that have special meaning when the TTY driver handles input this way, before the program sees it.

> Somebody at the university implemented ^T to 4.2 BSD on the cs department's busy VAX 11/780, by modifying the tty driver.

macOS has this too!

Likewise because of Amiga workplace terminal emulator. Applications that constantly output to stdout would go faster if you kept the mouse moving.

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.)

I remember when I was a kid that I used this "hack" to speed up installations.

If I moved the mouse the HDD would spin furiously but once the mouse stopped it would resume trickling the writes/reads again.

"large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input."

So in today's world... why do so many PCs emit a slight sound when moving the mouse. I know that there are high frequencies involved and periphery is one of the worst perpetrators of electromagnetic interference, but I still find that strange. And what exactly is emitting the sound here?

I'd have to guess the CPU - it gets hammered with interrupts and its load changes. But it could be anything really...

Don't USB mice use polling rather than interrupts?

Most likely voltage regulotor coils (which live in PSU / GPU or motherboard)

When it whas really quiet, I could hear sound from my old cellphone when the screen updatet (Moto G4).

Generally it's cheap/poorly designed audio amplifier circuits. Even though modern PC audio is mostly digital, the final stage (getting sound out the speaker) is still analog. If the motherboard designer isn't careful about how they place/isolate/ground the analog audio circuitry, it can pick up some of the PC's stray high frequency noise which gets worse the more you turn up the volume since now the noise gets amplified too.

A work around if you have a motherboard that is particularly bad about this is to use the digital audio output (S/PDIF via an optical or RCA jack) to connect an external amplifier or you could stream it via software. This tends to only be an option if the machine is stationary and not terribly realistic for people with a laptop on the go.

They claim the PC is emitting the sound, not their speakers. So they are likely describing coil whine, not interference.

You're assuming a precision in their post that I wasn't (i.e. that it's actually coming from the PCB, rather than 'the collection of parts called a PC sitting in front of me'... which would include the speakers for most people)

> You're assuming a precision in their post that I wasn't (i.e. that it's actually coming from the PCB, rather than 'the collection of parts called a PC sitting in front of me'... which would include the speakers for most people)

For what it's worth, this _is_ hacker news. I concede not everyone is tech savvy but I tend to respond to comments as if they are.

Could be coil whine? Many modern GPUs are notorious for it.

> https://en.wikipedia.org/wiki/Electromagnetically_excited_ac...

Similarly I can hear my Kindle buzz when I change page. Electric components can have some coil whine when being pushed

Making a huge selection with mouse in LibreOffice spreadsheets even today goes faster if you move the mouse while dragging one endpoint of the selection over the spreadsheet borders which causes the sheet to scroll. Likely the very same cause: there's a timer or other repeating tick to scroll content at a reasonable speed but the sheet is also scrolled when input events wake up the same loop.

The same is true in MS Word and even in many web browsers.

I remember this with any selection in windows on at least 3.1/95/98/SE.

This happened if you kept the mouse just inside the window and moved it about 10-20px up and down in/out pf the window in the direction of the selection.

It was a way for me to scroll faster than with the wheel or cursors on web pages if you selected some text and then kept the selection on the end of the screen and moved the mouse wildly in the edge of the screen.

As I was younger then, there was probably a better solution to do this but I was not aware of it.

We had a milling machine that ran from Win95, and we had to discipline ourselves not to move the mouse when it was milling a complex shape. Otherwise the machine would stutter and give us a nasty finish on the machined part.

I remember writing documentation circa 2002 for a development environment that required Visual Studio 6.0 and as part of the install notes I wrote something along the lines of -

"During installation constantly move the mouse in a circular motion over the installation window. This speeds up installation roughly 2-3x"

Good times :)

In some applications with scrolling work areas, I'd end up trying to move it in pixel perfect straight lines when dragging stuff past the visible work area, so as to speed up the refresh and keep the mouse in the part of the border where you get maximum scrolling speed.

I always assumed that Windows95 was just scared of mice, so if you shook one at it, it would either run faster in fear, leaving a trail of random disc sectors, or suddenly hide under its special blue blanket and refuse to come out again.

I have a terrifically annoying bug that shows up somewhere between X and GTK and all Gecko-based browsers. While I'm scrolling down in a web page with the mouse wheel, within a few seconds the page will stop moving. The mouse will still move around, but it will stop changing its cursor based on hovered elements, and further mouse actions will do nothing. It will unjam itself something like 30 seconds later if I wait, or immediately if I press any key. Then all the queued mouse events will rush through at once, so if the key I hit was Ctrl, the page's contents zoom out and I have to reset it. If I hit Shift, it walks back through the history and I lose my place. So I was hitting Alt for a while, besides shopping for a distro.

I couldn't debug it normally, or even get a clue about which package needs to be downgraded, because I can't pop over to the terminal without unjamming it. So I'd need another machine with which to SSH in, and those are all unusable ATM (well, I probably just needed to suck it up and install SSH on the phone). But ${somehow} I found out that triggering a redraw with ${something} also unjams it, so I set the clock in the XFCE panel (also GTK, FWIW) to display seconds as well. Now it still jams but always for less than a second.

> ${somehow}, ${something}

Sorry, something resurfaced-- I think I remember now that I switched on seconds for the sake of finding out more precisely how long a jam would last. Immediately it became obvious that they didn't last long anymore, and that the reason it used to be "30-ish seconds" was whenever the minutes finally changed, it broke loose just the same way.

Hmm, it goes away if I use Fluxbox instead of XFCE. Neat.

Wow, I remember doing this as a kid and thinking to myself that I was being stupid because surely wiggling the mouse would make the computer have to process more input and actually slow down whatever I was impatiently waiting for. I still did it though, because I _felt_ like it made things go faster. Turns out that intuition was right. Funny how we can learn to do things that actually work even when our conscious mind doesn’t believe they do.

This reminds me of using NUM LOCK to see if your CPU was responding to the A20 interrupt.

Are you telling me that's not the correct way to find out?

All these years I've been wrong!

Not at all! If it works, do it!

Isn’t the use of the lock buttons, like, the standard way to test whether the OS/hardware still responds to something or if it’s reboot time?

They’re soft now. It might indicate your usb driver is wedged, not if your CPU is responding to interrupts at all.

This is a problem for NTP developers - finding real serial ports on modern hardware

The keyboard lights have always been soft. There are certainly more layers now between a keyboard and an os though.

The softness is precisely what made them a useful check, though. Tapping num lock has two important properties: Nothing should ever be blocking that process, and it's harmless to do and should never really affect what's happening.

And this reminds me of when I accidentally figured out playing MOD sound files in DOS 6 with a new and especially beautiful STM/MOD player at the time would sound considerably better from my 486's PC speaker if I pressed the pause/break key to literally lock up the system. Apparently the player would buffer enough of the song that even though everything froze up, the sound would continue playing. I couldn't afford a dedicated Soundblaster/Gravis sound card but I still pined to hear all the amazing music coming out from the demo scene. The quality of course wasn't comparable to a dedicated soundcard but it was still a huge improvement over the typical beeps/bloops of the built-in PC speaker.

Ooh, which MOD player? I was partial to Cubic Player, and before that VP (Visual Player), which was the first place I ever saw an oscilloscope.

4 channels realtime audio + 5 osc's on a 286 out the PC speaker. Phenomenal. Sounded like shit until I got a Sound Blaster, though....

Galaxy 2.12 (glx212.zip) is my favorite for pre-386 machines. It'll do remarkable things with a covox or even pc speaker, and realtime FFT (not faux bouncing bars, either!) to boot!

Sometimes the software itself may even just be designed that way too. https://thedailywtf.com/articles/Hidden-Tax-Moves

From the answer on Stack Exchange:

> The effect was quite pronounced; large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input.

In 1986, some computer graphics researchers in California (namely Conrad Huang, Ken Arnold, and Greg Couch at U. of California, San Francisco, Computer Graphics Lab) wrote a multi-player TTY game called hunt.

The game of hunt is clocked by the arrival of events. So that is to say, the arrival of packets from the game clients into the server drives the game forward. The more furiously people play and the more players there are, the more rapid is the movement of automatic objects, like shots traversing through the maze.

I last played this in 1995. I had a WYSE 50 terminal hooked up to a Linux box and played with a friend. One of us was on the console, one on the terminal.

I remember I had to patch something socket-related in the source code to get it working.

Entertaining, but probably unrelated: there was a systems paper from the late '90s or early 2000s (SOSP?) where the authors used an extremely low priority process recording timestamps to instrument system behavior. Basically, because the process wouldn't run if anything else was runnable, it wouldn't generate its periodic timestamps. As a result, they could easily see relatively low-level details about system CPU behavior.

One thing they discovered was that Windows 95 would enter a tight CPU polling loop if you held the mouse button down. So, don't do that.

[Edit: dammit, I cannot find the paper. Sorry. It was really interesting.]

I definitely remember seeing scrolling-is-faster-if-you-wiggle-the-mouse on Linux too, back in the day, and being surprised that a bug (? misfeature?) like that would show up on such different stacks.

Back in the day it wasn't a bug, but rather more of a cheat to make your system feel faster than it really was: if the system actually gave the UI a fair share of CPU cycles, the system would feel incredibly sluggish. Conversely, if it gave the UI the lions share of CPU, nothing would ever get done in the background. So it compromised and gave the UI preferential treatment when the user was active (i.e. when there was recent mouse/keyboard activity), and a more fair allocation when they weren't so other things could get done.

I used to open the CD drive when the entire computer would freeze up. I wonder if its the same thing.

Same here! I can't remember if I did the moving mouse thing, but I definitely opened the CD drive to unfreeze the computer.

I totally forgot about that! I did it, too. It's like it jarred it back into interactivity.

I had something that may have been related. In VLC with my old monitor (1920x1080) watching a film it would often flicker painfully. I found moving the mouse continually would make it smooth. A bit of python...

  import ctypes, time
  
  def move(x, y):
      ctypes.windll.user32.SetCursorPos(x, y)
  
  for x in range(10000000):
      move(0, 0)
      time.sleep(0.01)
      move(1, 1)

... and all was well.

(When I upgraded to a 4K monitor things got worse and the cursor fiddle doesn't help).

    for x in range(10000000):

Why not just use `while True:` ?

I... really don't know!

One thing that also worked was to open and close the CD-ROM tray. It felt like HDD was waiting for something that open-close action on the CD-ROM drive would trigger some reaction.

Its like rage shake for mouse! If you are angry and shake your mouse in rage it moves things faster. I imagine this would be a very satisfying thing to be able to do.

Given all the me too's. How about this one, same basic problem in the mid 2000's with linux. We were running a few servers with a normal desktop distro. I got the bright idea that since no one was actually on the console we could save some ram/CPU by changing the default runlevel and not starting X/etc. Took about 2 days before someone complained we were running about 20% slower than normal.

I think in the end the solution was to just fire off a X/xdm pair as I wasted a few days looking at scheduling/numa/shared interrupts/etc trying to get a good solid solution that didn't require starting X. We ran it like that for a couple years until eventually someone tried it again (after a bunch of software/hardware upgrades) and the perf didn't fall off.

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.

I always thought that this scroll behavior is known and special in that it helps precise scrolling. I know winapi and why this happens, but never viewed it as a wild bug. Can’t recall now, but I think Mac and Linux behave the same way. Can someone confirm that?

Reminds me of https://devblogs.microsoft.com/oldnewthing/?p=32233

Raymond Chen's blog is always a great source of interesting information.

But I remember the times when that blog didn't look like a webdesign internship project in progress. And there were interesting comments…

So much history was lost when microsoft migrated the blogs and deleted the comments...

As a matter of fact, I think he actually answered the question:

https://devblogs.microsoft.com/oldnewthing/?p=36423

“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.“

Wow, I always moved the cursor over the progress bar as I believed it made the installation go faster, but I never had actual proof. I guess I wasn't the only one.

I remember that with Windows 98SE, when it got stuck most of the times you can make it come back to life again by opening/closing the CD tray a lot of times...

Had that in an app i was working on ages ago.

We were doing some processing on a database and updating the progress bar every record. We processed the UI messages at that point as well so any click on Cancel could get through.

As customer databases grew, the processing began to exhibit this behaviour.

If I remember well, we fixed it by only updating the progress bar every 1%. It may have been more complicated than that though, I had moved on to another job when the fix was done.

This is why I love HN.

I miss this mysterious, charming, golden era of tech.

yes its good software doesn't behave strangely any more

Now the only thing left is to figure out why Dungeon Keeper II crashed roughly 50% of the time at startup. Don't ask about my procurance of said software; we do not speak of such things.

EDIT: And of course, a person who should not be named at the time remarked: "Computers always do the same thing, DKII can't be crashing sometimes and other times not..."

Funny. I've seen people doing this back in the windows 95 days but believed that was just a superstition.

So should be possible to build a usb turbo button (or foot pedal) which just triggers mouse movement events?

I think I remember (1980s/90s) if you were copying a file to/from a remote host (with ftp or something), you could improve the throughput speed by pinging the remote. Maybe ethernet, or maybe ppp/slip, I'm not sure.

What olden times are the article and the comments speaking of? Scrolling is still faster when selecting while wiggling the mouse, at least on Windows 7 with Firefox, for me. Just tried it right now to make sure.

Would it actually run more quickly or just feel like it was running faster? I thought moving the mouse gave more frequent feedback but I didn’t think it reduced the time it took to install an application.

i used to have an obsessive habit of right-clicking the desktop and selecting refresh. took me ages to exorcise that out of me when i switched to a linux. i remember not liking that it didn't have that option.

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...

This still happens in a way in current OS's...

When marking text to copy and making it scroll, moving the mouse left and right will speed up the scrolling sometimes.

Try it in a long Word doc or in Firefox.

And when you click in Excel while it is stuck computing, does it prioritise the cell you are clicking on, or could it be that it actually does compute more quickly then?

While we are at it, can anyone tell me why selecting large text in a scrollable window works faster when you move the mouse?

I had an ailing Windows 95 Laptop that in its later years stopped functioning entirely unless I wiggled the mouse.

This all makes a lot of sense now.

Rather than being interrupt driven (CPU interrupts), it was event driven.

Can flushing buffers be considered a cache invalidation problem?

To understand if all the OS it is freeze

Best game ad I have seen for a while

noice, did not know that! Maybe I should give Win95 a go, as macOS is going pretty down.

I can't stop laughing!

In order to show the properly random and non-deterministic behavior (e.g. random BSODs) that Windows users have come to expect, MS Windows needs to continuously gather high-quality entropy from its surrounding environment. That's why it stops when you're not wiggling the mouse; it's just waiting for you to provide the additional entropy it needs.

No, it’s actually a little-known feature that allows Win95 to temporarily upclock the CPU during peak loads, using the power generated by vigorous mouse movements.

Reply on news.ycombinator.com