

The biggest annoyance (not only with glibc but most libraries) is that you have to build your program on a system with the oldest libraries you plan on supporting (this is not a requirement on Windows) but with VMs, etc this should not be much of a problem in practice. You can make very advanced programs with the stable APIs Windows provide, since they feature not only simple console stuff, I/O, etc but also user interfaces with widgets, 3D graphics, audio, video, etc.Īlso glibc is stable if a program relies on public APIs, the breakage comes from programs relying on stuff they weren't meant to use. Linux also has a stable userland ABI, it is just that unlike Windows said stable ABI does way less. Contrast this with Linux, where glibc is known to break from time to time. Would you prefer this binary to be a Linux binary, or a Windows binary? Since Linux can run Windows programs just fine (or sometimes, better than Windows) with Wine, win32 might as well be the stable userland that Linux is missing suppose you have a binary to run but doesn't have all of its libraries - the binary expects that system libraries are to be found at their well known places. So, if you want stability, you need to use one of those package formats that bundle the application and all its libraries (like Snap, AppImage and Flatpak), that looks awfully like Windows installers :t except that Windows application don't need to bundle system libraries like the libc, because Windows extends their stability guarantees to dlls like user32.dll - that is, Windows has a _stable userland ABI_.

Now, get any installer from Windows and try to run. deb from an old Debian and try to run on a new Debian, it likely won't work. This means that distributed binaries will eventually fail to run.

Unfortunately distros rarely keep around old libraries indefinitely. Traditionally, Linux binaries aren't distributed with their libraries it's expected that the distro will place the libraries in the right version and in the correct place.

I think the point is that the Linux kernel ABI is super stable, but the Linux userland ABI (meaning, the system libraries your program uses) has breaking changes. That is, Linux churns so much that a given program written today won't work in a year meanwhile, programs written in the Windows 95 32-bit era are guaranteed to never change again. I think I started thinking about this idea when I read the remark "win32 is the stable Linux userland ABI".
