Windows NT on 600MHz machine opens apps instantly. What happened?

It blows my mind how unresponsive modern tech is, and it frustrates me constantly. What makes it even worse is how unpredictable the lags are so you can't even train yourself around it.

I was watching Halt and Catch Fire and in the first season the engineering team makes a great effort to meet something called the "Doherty Threshold" to keep the responsiveness of the machine so the user doesn't get frustrated and lose interest. I guess that is lost to time!

I was just reading this week about someone trying to get their UHK keyboard to launch an application on Windows by producing a sequence of keys starting with the Windows key. They needed to put in a delay to get this to work, and it reminded me of my frustrations launching programs in Windows as the start menu takes its sweet and variable time. Not least because I know the technology has been focused on getting adverts into the start menu.

This is partly an OS design issue. There's no deep reason the OS should ever throw away keypresses, but contemporary GUIs have a very weak and flaky notion of focus. Contrast this with mainframe apps where users could learn to go incredibly fast, because keystrokes were buffered per connection and the mainframe would process them serially, so even if you typed faster than the machine could process them it wouldn't matter, no keys were lost.

It's not necessarily Windows throwing away keypress events but the order of events system wide not necessarily staying in the expected order or the target for an event not being active at the right time.

If you activate the start menu with a keypress it's going to grab focus. Before it grabs focus the previous window in focus will get events. The same applies with panels (drawers? I forget Windows' name for them) in the Start Menu. There's a non-zero time between activation and grabbing focus to receive keypress events.

Everything from animation delays to stupid enumeration bugs can affect a windows not grabbing focus to receive keypress events. Scripting a UI always has challenges with timing like this.

A mainframe terminal has a single input context. You can fire off a bunch of events quickly because there's no real opportunity for another process (on that terminal) to grab focus and receive those events.

Note the above doesn't absolve Windows of any stupid performance/UX problems with bad animation timings and general shittiness. Microsoft has been focusing on delivering ads and returning telemetry with Windows instead of fixing UX and performance issues.

Yes, my point is that an alternative OS design could serialize keystrokes such that a keypress has to be handled (including focus changes) before the next keys are delivered, allowing you to type ahead without keypresses going to the wrong place or depending on the vagaries of timing. It might require a different approach to UI API and design, though.