Yes, in order to increase their backwards compatibility Microsoft has, historically at least, done things like that. However, mostly they achieve backwards compatibility by just not breaking ABIs all the goddamned time.
Windows backcompat isn't perfect, true, but largely the stories of where it fails are exceptions to the rule. Where as you can't even have backward compatibility in a Linux Desktop with applications compiled for the previous version of the same distribution in many cases.
You started off by disagreeing that backwards compatibility is hard, because other platforms (like Windows or MacOS) can do it.
When given evidence that it's at huge cost and investment that they manage to do that (basically an admission from them that it is hard — you may have a different definition of "hard" than I do), you seem to suggest that either they are not doing a lot of work towards compatibility or that they are wasting all that money because they could have simply maintained backwards ABI compatibility while developing new features "easy-peasy".
Why did they choose not to take the easy way out and made it hard for themselves?
From my software development experience, maintaining API backwards compatibility is "hard" (requires significant extra effort to achieve compared to just not doing it), not to mention ABI complexities on top.
You misunderstand. I am saying that all that effort was spent chasing the long tail of compatibility, which is valuable if compatibility is one of your big selling points.
However, one need not go to such extremes to get a good amount of compatibility, just don't have a policy of breaking ABIs constantly the way Linux Desktop does.
And let me address the "policy of breaking ABIs constantly the way Linux Desktop does."
As you probably know, there is no policy, and no "Linux Desktop" either. You've got Linux distribution releases that are supported for up to 10 years (like RHEL and Ubuntu LTS) by teams a couple of orders of magnitude smaller than either of MacOS or Windows. They usually get HWE kernel updates too (hardware enablement) from newer Linux series. By definition, they maintain ABI backwards compatibility for the duration of their support. If you care about it, that's what you should use.
But it's in the nature of free software world to want to mix and match, so the idea of a singular Linux Desktop does not exist. You should treat each one of them as a separate OS, which is unfortunate, but realistic. Flatpak/snapcraft recognise that to a point (packaging up everything but the kernel, regardless of the system packages already installed).
> As you probably know, there is no policy, and no "Linux Desktop" either.
Yes, a common refrain.
> You've got Linux distribution releases that are supported for up to 10 years (like RHEL and Ubuntu LTS) by teams a couple of orders of magnitude smaller than either of MacOS or Windows.
Yes, and they're not really equivalent because they keep everything stable. An OS like Windows or MacOS keeps the platform stable and allows applications to be bleeding edge or not as desired. This way applications are typically distributed on Linux make this very difficult, hence things like Flatpak.
Regarding the team size, I can only say that if everyone worked on the same "distribution", that gap would be significantly reduced. Instead the Linux Desktop world delights in duplicating effort, so here we are.
> But it's in the nature of free software world to want to mix and match, so the idea of a singular Linux Desktop does not exist. You should treat each one of them as a separate OS, which is unfortunate, but realistic.
If that is the policy, then no one should be surprised when developers choose not to target a non-platform that doesn't exist.
Ok, I see your premise now. I am not sure I agree: do you know of a system that has seen less investment on backwards compatibility yet successfully maintains it?
Of course, not "frozen" like TeX, but seeing active feature development too.
Pretty sure HaikuOS runs software originally compiled for BeOS in 1995. They have a very small development team and they are quite active today.
...for that matter WINE is even able to make Linux compatible with Windows applications to a great extent, and they certainly aren't backed with Microsoft's wealth of resources.
Windows backcompat isn't perfect, true, but largely the stories of where it fails are exceptions to the rule. Where as you can't even have backward compatibility in a Linux Desktop with applications compiled for the previous version of the same distribution in many cases.