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.)
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 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.
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.
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.
> 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.
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"
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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?
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.
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"
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.
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.
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.
[+] [-] UI_at_80x24|6 years ago|reply
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.)
[+] [-] yokohummer7|6 years ago|reply
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...
[+] [-] samstave|6 years ago|reply
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.”
[+] [-] gsich|6 years ago|reply
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.
[+] [-] TomMarius|6 years ago|reply
[+] [-] isostatic|6 years ago|reply
But a few minutes later you'd be back to swap in floppy number 18
[+] [-] wnevets|6 years ago|reply
[+] [-] kees99|6 years ago|reply
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.
[+] [-] ben_w|6 years ago|reply
[+] [-] kllrnohj|6 years ago|reply
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:
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:
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.[+] [-] JoeAltmaier|6 years ago|reply
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.
[+] [-] chadcmulligan|6 years ago|reply
[+] [-] FillardMillmore|6 years ago|reply
Guess I owe my dad an apology now.
[+] [-] gibspaulding|6 years ago|reply
[+] [-] air7|6 years ago|reply
[+] [-] mrzool|6 years ago|reply
[+] [-] matthoiland|6 years ago|reply
[+] [-] mat_jack1|6 years ago|reply
[+] [-] _trampeltier|6 years ago|reply
It's not just Notepad :-) I do this often, when I have to mark a lot of things.
[+] [-] shawnz|6 years ago|reply
[+] [-] dTal|6 years ago|reply
[+] [-] AgentME|6 years ago|reply
[+] [-] michrassena|6 years ago|reply
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.
[+] [-] metalchianti|6 years ago|reply
[+] [-] DonHopkins|6 years ago|reply
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.
[+] [-] snarfy|6 years ago|reply
[+] [-] tempguy9999|6 years ago|reply
[+] [-] cantstop|6 years ago|reply
[+] [-] TeMPOraL|6 years ago|reply
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.
[+] [-] DonHopkins|6 years ago|reply
(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.
[+] [-] cardiffspaceman|6 years ago|reply
[+] [-] userbinator|6 years ago|reply
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.)
[+] [-] Tade0|6 years ago|reply
If I moved the mouse the HDD would spin furiously but once the mouse stopped it would resume trickling the writes/reads again.
[+] [-] segfaultbuserr|6 years ago|reply
[+] [-] raxxorrax|6 years ago|reply
[+] [-] yason|6 years ago|reply
[+] [-] consp|6 years ago|reply
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.
[+] [-] Vrondi|6 years ago|reply
[+] [-] analog31|6 years ago|reply
[+] [-] satysin|6 years ago|reply
"During installation constantly move the mouse in a circular motion over the installation window. This speeds up installation roughly 2-3x"
Good times :)
[+] [-] zahreeley|6 years ago|reply
[deleted]
[+] [-] inflatableDodo|6 years ago|reply
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.
[+] [-] dbtx|6 years ago|reply
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.
[+] [-] jaggednad|6 years ago|reply
[+] [-] RyJones|6 years ago|reply
[+] [-] glenneroo|6 years ago|reply
[+] [-] Sharlin|6 years ago|reply
[+] [-] UI_at_80x24|6 years ago|reply
All these years I've been wrong!
[+] [-] Kurakuan|6 years ago|reply
[+] [-] hwj|6 years ago|reply
> The effect was quite pronounced; large applications that could take an hour to install could be reduced to 15 minutes with suitable mouse input.