Comment by pjc50
14 hours ago
> making the main menu bar ALL UPPER CASE
I remember that. Especially silly.
> Windows RT (not to be confused with WinRT, because Microsoft product naming!)
The gold standard will always be "Xbox one series X", designed to be confused with Xbox one series S.
Windows RT had one other anti-consumer and anti-developer feature: it was locked down like a Chromebook, so you could only use Store apps on it.
> Windows RT had one other anti-consumer and anti-developer feature: it was locked down like a Chromebook, so you could only use Store apps on it.
That was at least in part due to the aforementioned obsession with iPad and generally mobile. One thing that Sinofsky is not wrong about in his post is that the classic Win32 app model is not conductive to good battery life - there's very little there to properly handle things like automatic background suspension or low-power push notifications. WinRT was designed with that in mind, but that would make no difference if the apps would just ignore it, hence the heavy-handed push for WinRT apps only (AFAIR it wasn't restricted to Store, although you had to jump through some "developer mode" hoops to deploy apps directly).
The main reason Win32 can't handle automatic background suspension or low-power push notifications is simply that those features haven't been exposed to it. There's nothing preventing a Win32 program from receiving those types of notifications and then being force-ended by the OS if it doesn't respond in time.
When I first started porting programs to Windows ARM64, I didn't have an ARM64 device and had to test in QEMU. It ran extremely slowly, probably 1/50th of real time. All UWP programs like Calculator ran like a slug. But which programs still ran reasonably? Classic WinDbg and Task Manager. Two programs that were still plain Win32.
There are significant issues with Win32, namely its lack of a permissions and isolation and lack of hardware acceleration in the old windowing UI (User/GDI). But the idea that Win32 is inherently power inefficient is, IMO, just BS. Its roots go back to CPUs that were orders of magnitude slower than modern CPUs and there is nothing difficult about making a Win32 program that idles at 0% CPU when not in use.