> The current situation is a good compromise between compatibility and bloat.
By this logic, any operating system has perfect backwards compatibility, since you just have to fix whatever's broken ... even when the compatibility shims come from 3rd parties! Linux has perfect backwards compatibility, you just have to download this patched Gtk+ binary from this guy, etc.
Whatever the excuse is, they have dropped their backwards compatibility story. It was part of their official, published ABI, and now it isn't. All the excuses are as bogus as they are on any operating system. Apple also claims they drop backwards compatibility to avoid "bloat", but it is just that, an excuse.
And "bloat" is quite a bogus excuse, too, since it could for example offer to auto-download the required components like it does for previous .NET framework releases. Or even put an updated version on their download site (e.g. as with winhelp). Or just made it a Windows-independent redistributable (e.g. CRTs). One could have an argument if this was the case. (Apple did auto-downloads at some point). Yet here they just didn't care and 3rd parties like Wine had to come in fill the holes.
Not to mention this is not what people have in mind when they think "bloat"; after all, Wine manages to provide all these APIs and sizes at significantly less than a barebones Windows installation.
>By this logic, any operating system has perfect backwards compatibility, since you just have to fix whatever's broken
The issue with your logic is you only see things as black or white while, while backwards compatibility is various shades of gray, depending on factors that are mostly beyond Microsoft's control.
Modern Windows cannot account for all possible APIs, DLLs and hacks/workarounds that were used by every developer 20+ years ago, including non standard libraries and APIs, so of course you might need to download some missing DDLs regardless. Even if you use Wine, you could still have to do that to run Red Alert 2 or other such apps. That doesn't mean backwards compatibility does not exist, it means it's not a guaranteed 100% success rate out of the box, depending mostly on what libraries, APIs and hacks the original app developer employed.
And the excuses are not bullshit, but are a matter of money and return on investment and ratio of bloat plus freedom the app developers took at the time which isn't available on Modern windows for security reasons (Windows till and including XP was unsecure as f*ck, I don't think you want to have all those functions the developers of the time exploited, for better or worse, exposed in your modern installation of Windows just for 100% backwards compatibility).
Microsoft can't be expected to ship every single outdated and insecure 20+ year old DLL and undocumented API with every copy of Windows, which is a non issue as the last fifteen F-500 cooperate sys-admins in the world who still need to run 20+ year old corporate apps on modern windows will definitely have the knowhow to copy some DLLs they trust to C:/System32 so their crusty corporates app will work. It's not too hard, to copy some files, is it?
The 32 bit C++ executables I wrote in highschool for windows 95, still run right now on Windows 11 out of the box without any patches or issues. So backswords compatibility exists on windows live and well against your opinion that it doesn't. End of story.
> Modern Windows cannot account for all possible APIs, DLLs and hacks/workarounds that were used by every developer 20+ years ago, including non standard libraries and APIs,
> Microsoft can't be expected to ship every single outdated and insecure 20+ year old DLL and undocumented API with every copy of Windows,
This is not the point. The point is software using the _official API_ of that operating system. It's not about software which was using undocumented or 3rd party libraries. That's a strawman.
> And the excuses are not bullshit
They may not be bullshit, but they are literally valid for every operating system. I don't care what the argument is when my complain is that Windows is becoming worse in backwards compatibility than literally Wine itself.
> The 32 bit C++ executables I wrote in highschool for windows 95, still run right now on Windows 11 out of the box without any patches or issues. So backswords compatibility exists on windows live and well against your opinion that it doesn't. End of story.
And you started your argument about "black and white" vs "shades of gray"....
"My C++ executables run" is quite the low bar. I can also run my a.out executables from the 90s in Linux, and I'm assuming a similar level of compatibility with macOS . The Tcl files from my thesis in the 90s still work without a problem, too, even the GUI...
But I complained loudly when my Loki games stopped working on my Linux DE, and I complain loudly when my 2000s games stop working on Windows 8/10, and trying to justify this by saying "Security! Bloat! Tradeoffs" is as absurd on Windows as it is for a Linux desktop.
By this logic, any operating system has perfect backwards compatibility, since you just have to fix whatever's broken ... even when the compatibility shims come from 3rd parties! Linux has perfect backwards compatibility, you just have to download this patched Gtk+ binary from this guy, etc.
Whatever the excuse is, they have dropped their backwards compatibility story. It was part of their official, published ABI, and now it isn't. All the excuses are as bogus as they are on any operating system. Apple also claims they drop backwards compatibility to avoid "bloat", but it is just that, an excuse.
And "bloat" is quite a bogus excuse, too, since it could for example offer to auto-download the required components like it does for previous .NET framework releases. Or even put an updated version on their download site (e.g. as with winhelp). Or just made it a Windows-independent redistributable (e.g. CRTs). One could have an argument if this was the case. (Apple did auto-downloads at some point). Yet here they just didn't care and 3rd parties like Wine had to come in fill the holes.
Not to mention this is not what people have in mind when they think "bloat"; after all, Wine manages to provide all these APIs and sizes at significantly less than a barebones Windows installation.