Win32 is the most stable abi on the Linux desktop.
This doesn’t work for proprietary software that’s distributed as blobs and rarely updated, like say, video games. But that’s a minority of stuff on Linux. But not on windows.
Realistically, on Linux applications target specific API versions of frameworks. Like Qt 6, or GTK 3, or whatever. Then everything is compiled or dynamically linked at a per-distro level. The ABI compat can bite specifically when distros enforce strict dynamic linking. But then containerization technologies come in.
And there is a difference between API and ABI stability. For example, adding SSO to std::string in C++ broke ABI, not API. If you recompile it’s fine, everything works. If you don’t then it doesn’t.
That’s one of the biggest issues keeping Linux small on the desktop since nearly no commercial oriented company works that way.
But it looks like we will soon be able to „virtualize“ the dynamic loader so glibc has no say in this matter anymore.
> Dead wrong [...] if I want to release a binary _without relying_ on Win32
Then you are not using the Win32 ABI, are you?
That's literally the definition of it being stable. Programs written against an interface keep working despite the implementation changing. The Linux kernel also constantly changes internally but programs written against syscalls keep working, so it is stable; that fact doesn't stop being a fact just because I dislike perf_event_open(2) or whatever. This is all very basic and easy to understand.
Also, there are OS-provided shims in ntdll.dll (which, by the way, isn't a part of Win32 platform API, but a part of the NT kernel interface).