No, it has to do with every time you move the mouse over a window, a hover event is sent to the application, which runs its main event loop. Either the installer only updated its progress bar when an event happened (in which case it would only appear to be going faster, because the progress bar would move more smoothly) or there was some really terribly written code that literally only made progress when an (unrelated) event happened. My guess is the former.

Explanation for that is here: https://devblogs.microsoft.com/oldnewthing/20210126-00/?p=10...

There must be so many subtle features like these that people use subconsciously, and when they try to move to another operating system, they try it, nothing happens and they get frustrated.

I still have the brainwash/muscle-memory to type:

$ gunzip -c somefile.tar.gz | tar xvf -

.. because there was, once, a day when the terminal buffer available for this pipe was bigger than available memory offered to a process by default, meaning the thing would unpack faster if I did that versus:

$ tar zxvf somefile.tar.gz

Admittedly, this discrepancy of available memory was usually because the BOFH hadn't realized there was also an allocation for pipes-per-user, so it was a neat trick to get around the hard limits that BOFH had imposed on some of my processes in terms of heap allocation ..

> There should at least be mention that changing this resolution can affect other processes.

That sorta is what it’s saying. If you don’t set it yourself, you won’t get any better than the “default system resolution”. But if the default system resolution changes (say, by entering a sort of “performance mode” when playing games or watching videos), then it would imply it will affect all processes that are using the default, right?

Think of it this way, the global timer resolution of the system is minOf(allProcessesTimerResolution). If no process needs higher accuracy timing then there is nothing hindering the system from sleeping longer periods to save power and/or have less interrupt overhead (An feature I'd say).

These API's are from the 90s, in the beginning of the 90s where these API's are from having an global system interrupt firing 1000 times per second could very well have taken a percent or two or more from overall CPU performance (people already complained about the "overhead" of having a "real OS").

On the other hand writing audio-players on DOS you had the luxury of receiving your own interrupt within a few samples worth of audio, this meant that you could have very tight audio-buffers with less latency and quicker response to user triggers.

Not having that possibility to get that timing fidelity would have made Windows a no-go platform for audio-software, thus giving developers the freedom to enable it when needed was needed. Removing it in the next 10 years would probably have risked bad regressions.

Like a sibling comment noted, they finally removed it during Windows 10's lifespan and with modern CPU's _AND_ multicore they probably felt safe enough with performance margins to separate high accuracy threads/processes to separate cores and let other cores sleep more and actually win more battery life out of it.

It might not be "perfect engineering", but considering the number of schedulers written for Linux over the years to address desktop(audio) vs server loads it was a fairly practical and usable design.

I still don't get your objection. Changing system timer settings is required to show HD videos on a browser window in a smooth way.

Are you objecting to the fact that that's the case or that browser windows are being used to show HD videos?