Hacker News Reader

Comment by dark-star | Hacker News Reader

This article is full of inaccuracies. For example

> Linux churns so much that a given program written today won't work in a year

I don't think that's true. It's more like "programs written 20 years ago (against glibc 1.x) don't work on recent Linux anymore"

> programs written in the Windows 95 32-bit era are guaranteed to never change again

Yeah, well, programs written for Linux 20 years ago also never change again. That's the whole point of closed-source binary-only programs...

> [windows executables are an] accumulation of cruft over literally decades.

Linux ELF file formats also contain ancient bits and pieces that are not used anymore. And the a.out "cruft" has only been finally removed this week

View on HN

The full quote is

> 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

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

  > 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.

They actually did end up fixing this with Windows 10. https://learn.microsoft.com/en-us/cpp/windows/universal-crt-... I think what finally pushed them in that direction was wanting to be in control of security updates for libc.

> Linux follows the Windows model, where the stable interface is the kernel (Linux's syscalls, Windows's ntdll).

ntdll isn't stable. They remove entypoints with just about every major release.

Interesting! Is there a modern equivalent of kernel32, then?

I haven't done low-level Windows programming since before the 64-bit transition, but I thought they kept the model of a DLL wrapper with a stable ABI.

The modern version of kernel32/user32 is still kernel32/user32. That's the lowest point in the system exposing a mostly stable API.

>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.

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.

It's absolutely true. It's not true of the kernel. But if you depend on any .so files provided by your distro, then you can reasonably assume that once the version of your distro goes EOL you're going to running your app in a docker container later (unless you continually maintain all the breakages). That's why I always make static binaries. Since if you only link the kernel, then you're good. WIN32 is also pretty stable. Always has been compared to the Linux userspace. You have to go back 20 years (like the OP) before unmaintained WIN32 apps start falling apart.

> > programs written in the Windows 95 32-bit era are guaranteed to never change again

> Yeah, well, programs written for Linux 20 years ago also never change again. That's the whole point of closed-source binary-only programs...

This sentence is poorly phrased, but from the context it looks like they meant: programs written in the Windows 95 32-bit era are guaranteed to continue running without ever changing again

It's one of the costs of closed source; binary compatible becomes really important.

It'd be interesting if a company like Adobe open sourced everything at the 20 year mark.

Hobbyists and enthusiasts would love them for it.

> programs written in the Windows 95 32-bit era are guaranteed to continue running without ever changing again

This needs the caveat of how well written those programs were: even with all the compatibility features modern Windows have, some programs did abuse the underlying APIs and had memory issues.

Also some programs at the time used "thunking" to mix 16bit and 32bit code (via DLLs) or simply used some DOS-based programs for some tasks even though the "main" program was 32bit, so those wont work with 64bit Windows. AFAIK Borland C++ 5 is a case of an application doing both, even though the main IDE is 32bit (and works in modern Windows), some of the helper stuff relies on DOS and Win16 code that doesn't work.

I have run into something similar with really old MinGW compiled applications. Old MinGW used to start allocating the heap at an non-recommended, but technically working address. After Windows 7, however, MSFT enforced memory safety rules a bit more firmly, making this address non-valid and breaking the program. Visual Studio provides a tool to rebase the heap allocation address, so that old 15+ year old program works again in Win10. I chose another address, admittedly one that might fall into the same category as before, but all of us at work hope to be off this old program by the time that happens again. Or we'll just virtualize it again.

> I don't think that's true. It's more like "programs written 20 years ago (against glibc 1.x) don't work on recent Linux anymore"

Technically Linux-the-kernel can run programms written 20 (and more) years just fine, it is the libraries that are the problem. However FWIW some libraries, like OpenGL, xlib and glibc do provide backwards compatibility - assuming no blatant abuse is done.

I made this test[0] in 2018 by compiling some binaries with a toolkit of mine in some ancient RedHat Linux from 1997 and they were working perfectly fine in 2018 Debian since it didn't rely on libraries that change their APIs/ABIs every time there is a new fashion. I haven't repeated it recently but i'm pretty sure a similar test with binaries from 1997 that only rely on libraries with stable ABIs will still work on my current openSUSE Tumbleweed installation, showing that more than two decades of backwards compatibility could be possible.

[0] https://i.imgur.com/YxGNB7h.png

As a last resort nothing prevents one to run old apps on an old chrooted distro though (I believe a container would do ok as well).

Presuming good faith, one could argue that copying over a dynamically linked binary from an older system will likely not "just work" on a newer install.

Yes I can make it work as well, but that could likely have been the experience described

Reply on news.ycombinator.com