Backwards-compatibility between new Windows OS releases and previously available apps has always been great. Recently, things have regressed a little bit, but even on Windows 11, you can still run anything available for Windows 8 (released over a decade ago) just fine by simply ticking a checkbox.
And for apps where the out-of-the-box mitigations don't work, the inscrutably-named Assessment and Deployment Kit (https://learn.microsoft.com/en-us/windows-hardware/get-start...) will most likely help you out. Sure, some truly ancient apps (mostly DOS and OG-WinAPI) really won't work anymore, but those are better relegated to a VM anyway, if only for security reasons.
If you want to understand why Windows still occupies a lot of IT mindset even in Y2K22, understanding the traditional Microsoft approach to backwards compatibility (as much demonstrated deficiencies as it has...) is a necessary first step.
Yes, I'm sure such exercises work fine for any real-life OS: if you take, say, Ubuntu 1.0, then run all the intermediate upgrade steps, you'll eventually end up with an up-to-date system as well.
The real question, though, is: after a successful OS upgrade, how many of your installed apps still work without issues?
On Linux, this varies: popular source-available apps tend to do fine, whereas less-common and proprietary (not to mention expensive!) apps fail after even minor updates, with no other resolution than 'ask your app supplier to do better', which is not always an option due to said supplier being too burned-out, bankrupt, or both.
On MacOS, apps generally seem to have a 2-5 year lifetime, after which they break for various (often minor) reasons. Resolution is as per above, and often unavailable due to suppliers disappearing or giving up because of to the relatively small size of the MacOS market. iOS has similar issues.
On Windows, you can generally continue to use even the most obsolete apps for 10-20 years, and often even longer. Of course, traumatic generational changes (obsoleting DOS or 16-bit WinAPI apps) still take their toll, but compared to other operating systems, this happens a lot less often, and migration tooling is often available.
The entire WoW64 subsystem is the epitome of Microsoft backwards compatibility fervor.
WoW64 makes 32-bit programs work under 64-bit Windows by providing an entire 32-bit copy of the 64-bit operating system, and then transparently redirecting reference calls made by 32-bit programs to them instead.
It's simple in design, brute force in execution, and practical in results. I hope Microsoft never changes their backwards compatibility philosophy; other operating system vendors should strive to be like them.
Not only that, they built an entire x86 and x64 emulator into Windows for Arm, so that (for example) if you install Parallels on a M1/M2 Mac and run Windows on it, you're getting the special Windows for Arm build, but many of your apps will still run because of the built in emulation of Windows.
It's just crazy compared to how much software just completely breaks between different macOS releases with no recourse, or have to be recompiled and reinstalled from scratch on Linuxes. Microsoft's bad at a lot of things, but they deserve a huge amount of credit for their backward compatibility on Windows...
While you’re right that Linux doesn’t have the binary compatibility Windows does, I think you gloss over the advantages of source availability. Having the source lets you patch bugs and avoid the (impressive and commendable) hacks described in the article.
It’s also worth noting certain Linux releases have extended support so you continue to get security updates without upgrading (a strategy Microsoft also uses).
Still, it is a downside of Linux and macOS compared to Windows.
Some software I code works on Windows XP through 11 without issue. Some of the tools I work on still work on Windows 2000 though I don't still test for it.
The one thing I couldn't make work right upgrading to windows 10 was the Microsoft webcam. You could almost force it but the quality became crummy. The one thing that broke in xp was my Microsoft joystick.
I think I remember reading some weirdness about legacy joysticks, because they didn't map cleanly to MS standard controller types or somesuch, so all had to have hacks in the drivers to be functional.
Which then expectedly exploded whenever MS shipped a new Windows version.
If you mean running apps made for those platforms, I wouldn't say that you have to be particularly lucky to do so. Even apps that try to write into shared registry or their own installation folder mostly work (because Windows emulates it by transparently creating writable copies).
Per https://en.wikipedia.org/wiki/Windows_8, "Windows 8 is a major release of the Windows NT operating system developed by Microsoft. It was released to manufacturing on August 1, 2012"
But possibly, per Bill Clinton, that all depends on "what the meaning of the word 'is' is"? Or I'm missing some implied sarcasm? Usually Occam's Razor would help out, but I just got downvoted twice for enumerating some historical facts on a separate thread, so who knows...
My mental model of Windows 8 is "that toc (terrible half of the cycle) windows release to 7's tic, that I had to remove from my Aunt's new laptop and found that UEFI made downgrading to Win7 a right ballache and I swear I did this 3 years ago not 10" How time flies.
And for apps where the out-of-the-box mitigations don't work, the inscrutably-named Assessment and Deployment Kit (https://learn.microsoft.com/en-us/windows-hardware/get-start...) will most likely help you out. Sure, some truly ancient apps (mostly DOS and OG-WinAPI) really won't work anymore, but those are better relegated to a VM anyway, if only for security reasons.
If you want to understand why Windows still occupies a lot of IT mindset even in Y2K22, understanding the traditional Microsoft approach to backwards compatibility (as much demonstrated deficiencies as it has...) is a necessary first step.