> I think I started thinking about this idea when I read the remark "win32 is the stable Linux userland ABI". 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 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.
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. Unfortunately distros rarely keep around old libraries indefinitely. This means that distributed binaries will eventually fail to run. (get any .deb from an old Debian and try to run on a new Debian, it likely won't work. Now, get any installer from Windows and try to run.. on Wine, it will probably work)
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_. Contrast this with Linux, where glibc is known to break from time to time.
So.. 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. 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
> Windows has a _stable userland ABI_. Contrast this with Linux, where glibc is known to break from time to time.
Linux also has a stable userland ABI, it is just that unlike Windows said stable ABI does way less. 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[0], 3D graphics, audio, video[1], etc.
Also glibc is stable if a program relies on public APIs, the breakage comes from programs relying on stuff they weren't meant to use. 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.
[0] X11 on Linux is also technically stable since the protocol is compatible even with machines from the early 90s and the libraries have a stable ABI, but by itself it doesn't provide much.
[1] Codecs notwithstanding, though Microsoft's own codecs should be fine to rely on
> Windows application don't need to bundle system libraries like the libc
That might be a bad example, because Windows applications are expected to bundle their own libc (MSVCRT). I'm not sure if modern Windows even ships with a copy -- it definitely doesn't ship with copies of all the versions that applications might depend on.
Linux follows the Windows model, where the stable interface is the kernel (Linux's syscalls, Windows's ntdll). This in turn implies that libc is a non-system runtime dependency, and a Linux application that wants to be portable across more than one release of Ubuntu (or whatever) should bundle its own copy.
Complaints of Linux ABI stability is mostly a story of old-timers trying to imitate how Unix worked in the '80s and '90s, with libc baked into the OS. Younger developers are more likely to use static linking or Docker/Flatpak/Snap.
> I'm not sure if modern Windows even ships with a copy -- it definitely doesn't ship with copies of all the versions that applications might depend on.
>That might be a bad example, because Windows applications are expected to bundle their own libc (MSVCRT). I'm not sure if modern Windows even ships with a copy -- it definitely doesn't ship with copies of all the versions that applications might depend on.
It went the other way - Microsoft moved away from the "unstable C runtime" policy and introduced the Universal CRT (IIRC in 2015), officially being promoted to a Windows component, a guaranteed stable ABI, and shipped with Windows since W10.
>Linux follows the Windows model, where the stable interface is the kernel (Linux's syscalls, Windows's ntdll).
Ntdll is decidedly not guaranteed to be stable, and its direct use is explicitly discouraged by Microsoft. Win32 has always been the official and stable interface for NT-based OSes.
I've only tried this with one .deb, but I've been running a 7ish year old version of a program I don't like the new version of, so far without problems. Originally a jessie package, now on ubuntu 22.04
> Contrast this with Linux, where glibc is known to break from time to time.
glibc has a very stable ABI, i.e. older binaries compiled against older versions of it should work fine on current versions (since the breaking libc6 transition which was several decades ago), they employ symbol versioning to ensure old binaries still find the symbols with the behavior they expect.
Of course, there are other "system libraries" that change ABI/SONAMEs more often, so what you are saying still generally applies, but I'd say glibc is not one of them.
glibc have versioned symbols. A glibc library can claim itself to be compatible of multi (old) version glibc. But it seems except some long term support versions. It didn't actually claim to be compatible with every old versions? The one shipped with Debian 11 have symbol of 2.2.5 and then there's a big gap and jump outright to the range of 2.3.x
IMHO it means both Linux and Windows are obsolete. The MMURTL Operating System specifically opted for no DLL's and static linking of all applications. The operating system ABI is guaranteed to be stable.
This makes upgrading the OS a heck of a lot easier too.
> I think I started thinking about this idea when I read the remark "win32 is the stable Linux userland ABI". 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 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.
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. Unfortunately distros rarely keep around old libraries indefinitely. This means that distributed binaries will eventually fail to run. (get any .deb from an old Debian and try to run on a new Debian, it likely won't work. Now, get any installer from Windows and try to run.. on Wine, it will probably work)
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_. Contrast this with Linux, where glibc is known to break from time to time.
So.. 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. 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