This might not have been viable 25 years ago when KDE and GNOME were in their infancy, but WINE has come a very long way since then. Standardizing on Win32 would eliminate the churn of dealing with Qt and GTK major version revisions.
What makes it so hard to write a GUI toolkit that is long-term (say for 25 years) backwards compatible. If Microsoft is capable of doing this, why can't open-source developers?
The problem, though, is that because the Linux desktop is made up of disparate parts from separate teams that have separate, often competing visions for their roles in the Linux ecosystem, often major changes are made with little regard to how they affect the system as a whole. This is the essence of the lack of control over the entire software stack. Thus, the developers of X11/Wayland, Qt, GTK, and other infrastructure can make breaking changes, and application developers relying on those subsystems have to either adapt or lobby for forks. Thus, the churn.
By comparison, Microsoft is in full control over Windows, and Apple is in full control over macOS. Even the BSDs are in full control over their base systems (for example, OpenBSD isn't just a kernel; the OpenBSD team also has control over the command-line tools that make up the base system), though I'm not aware of any BSD (besides macOS) that is in full control over GUI environments. It's not to say there is no churn in these environments; indeed, macOS does not prioritize backwards compatibility like Windows does and thus there's some churn macOS developers need to deal with in order to keep up with the latest releases. But there seems to be a lot of churn at the GUI level in the Linux desktop ecosystem.
No, but window managers who use Xt, Xaw or Motif are ok.
That's one of the attractions of Go, and to a lesser extent Rust; it's way less work than C to get a portable binary.
I think 90% of the problems I've encountered are due to glibc. They could easily fix all of them by adding a GCC flag that would allow you to compile against old glibc versions.
They'll never do that though because they are ideologically opposed to it.
Source software is the way to go (compiled specifically for one version of thé targeted OS, you sont have many issue)
Distribution opaque binaries are indeed not the best way, even if you can do it easily with static linking
But that's a casual consumer viewpoint. It's valid to buy them if they solve your problems in the here-and-now. (I used one for a year at work and it was a bad experience, but a lot of that was having x86 libraries I had to use, so... Bad choice for here-and-now.)
If the requirements are still accurate, it will run on XP with 512MB RAM.
Rosetta is giving Apple a competitive advantage by being able to run x86-64 binaries in VMs (Linux or maybe even Windows) at near-native speeds. This enables doing cool things like running MS SQL Server in a Docker container - which enables developing on a full local .NET stack on a Mac.
What's the competitive advantage here?
But that’s more feature parity with x86 Windows machines, not an advantage.
And architecture aside, at one point I had to install an old version of iWork (I thin it was '09) to update a file so the latest iWork could read it. They had code on hand that could read those older files, but decided not to integrate it. They don't prioritize backwards compatibility.