> WinRT (2012) - it (or the embodiment in Windows 8) failed in the market but it also showed both the problem and potential solution to building for new markets while respecting the past

I can't express how wrong this is. WinRT was the most destructive thing that the Windows team ever did to the OS. It drove a hard stake into Windows, splitting it in half and declaring that anything previous to Windows 8, oriented toward desktop, or using primary input through mouse and keyboard over touch was dead. Microsoft basically told all existing Windows developers that if they weren't building a new, touch-oriented, mobile-style app specifically for Windows 8, they didn't matter and wouldn't get any support whatsoever, which is exactly what happened every time they broke existing desktop functionality. Calling this "respecting the past" is a crass insult and taking no responsibility for damaging the Windows development experience and accelerating development away from native Windows apps.

The Huffman decoding implementation is also bigger in production implementations for both speed and error checking. Two Huffman trees need to be exactly complete except in the special case of a single code, and in most cases they are flattened to two-level tables for speed (though the latest desktop CPUs have enough L1 cache to use single-level).

Finally, the LZ copy typically has special cases added for using wider than byte copies for non-overlapping, non-wrapping runs. This is a significant decoding speed optimization.

Win32 controls ignoring system colors goes much farther back than dark mode being introduced in Windows 10. The theming engine that broke a lot of that functionality was introduced in Windows XP. Beyond that, there were always a few hardcoded colors like disabled gray text going back to Windows 95.

Dark mode ignoring Win32 system colors is not incompetence. It was _intentional_. Dark mode was introduced by the UWP side, which intentionally did not extend it to Win32. To this day, there is not even a Win32 API for desktop apps to query whether dark mode is even enabled. The official recommendation is to compute the luminance of the UWP foreground color setting:

https://learn.microsoft.com/en-us/windows/apps/desktop/moder...

On top of this, there are a small handful of system UIs that do support dark mode and make your program look inconsistent with dark mode regardless. Message boxes will switch to dark mode, and so will file dialogs -- which is a problem if you've used the Vista-style customization, as any syslinks will appear in a color of blue that's hard to read against the dark mode background.

Winforms is also .NET based, so it's inaccessible if you don't want to write your UI in and take a dependency on .NET.

- Multiple monitors - Non-full screen views - Sideloading outside of the Store - Offline installation - Explicit threads - thread pool only - Aligned memory allocation - malloc only - Any C++ compiler other than MSVC - Support for any version of Windows other than Windows 8 - Running apps as administrator - Running more than one instance of an app at a time - Runtime shader compilation

If any ONE of these things was a blocker, you could not write a Metro style app. And yet Microsoft pushed this extremely hard -- including almost completely ending any maintenance of Win32 APIs. And despite the many relaxations and extensions, UWP is still largely useless today, and now even itself seems to be going into maintenance mode. All of which has done a lot of damage to the state of Windows desktop platform development.

As an example of how bizarre UWP is, for some reason every time they published a list of new APIs added to it, they converted the list of API identifiers to lowercase in the documentation:

https://learn.microsoft.com/en-us/windows/uwp/whats-new/wind...

It's relatively insignificant, but... why? Just one of many things that showed how immature UWP was.

L1D caches have also gotten bigger -- as big as 128KB. A Deflate/zlib implementation, for instance, can use a brute force full 32K entry LUT for the 15-bit Huffman decoding on some chips, no longer needing the fast small table.

The way that the vector registers were extended to 256-bit causes problems when legacy 128-bit and 256-bit ops are mixed. Doing so puts the CPU into a mode where all legacy 128-bit ops are forced to blend the high half, which can reduce throughput of existing SSE2-based library routines to as low as 1/4 throughput. For this reason, AVX code has to aggressively use the VZEROUPPER instruction to ensure that the CPU is not left in AVX 256-bit vector mode before possibly returning to any library or external code that uses SSE2. VZEROUPPER sets a flag to zero the high half of all 256-bit registers, so it's cheap on modern x86 CPUs but can be expensive to emulate without hardware support.

The other problem is that only the low 128 bits of vector registers are preserved across function calls due to the Windows x64 calling convention and the VZEROUPPER issue. This means that practically any call to external code forces the compiler to spill all AVX vectors to memory. Ideally 256-bit vector usage is concentrated in leaf routines so this isn't an issue, but where used in non-leaf routines, it can result in a lot of memory traffic.

Funny thing is that at the time, I was lamenting how much slower VC6 was than VC4. Macro playback, for instance, got much slower in VC6. It's all relative.

It also has a basic mistake in text editor UX: the caret blinks independently of caret movement. This means that the caret is invisible half of the time while trying to navigate text. Most text editors avoid this by restarting the blink cycle to force the caret visible on each movement.

Similarly, Windows Update used to consume ungodly amounts of CPU time because the update system would write a multi-hundred megabyte text log and then spend forever compressing it for upload. Then they remembered their own ETL system and switched to much more efficient binary logs.

Firefox also has problems on HDD, I remember it locking up for minutes at a time doing cache maintenance until I switched permanently to SSDs.

That being said, a lot of tricks work better with center/extent instead of min/max, such as computing the AABB around an OBB or doing separating axis tests with abs() tricks. A bounding box and bounding sphere can also be stored together as center/extent/radius with only one additional value needed. Min/max works better for accumulation, though.

As a developer, it's easy to be blind to this because they're on "your side", but it's bad for the health of your support forums.