6 ms·

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

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

jart 4y ago
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.
quietbritishjim 4y ago
> > 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
- kristopolous 4y ago
  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.
- badsectoracula 4y ago
  > 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.
  - glowingly 4y ago
    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.
kristopolous 4y ago
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
badsectoracula 4y ago
> 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 https://i.imgur.com/YxGNB7h.png
- prmoustache 4y ago
  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).
nextaccountic 4y ago
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
- badsectoracula 4y ago
  > 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

jart 4y ago

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.

quietbritishjim 4y ago

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

kristopolous 4y ago
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.
badsectoracula 4y ago
> 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.
- glowingly 4y ago
  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.

kristopolous 4y ago

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

badsectoracula 4y ago

> 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 https://i.imgur.com/YxGNB7h.png

prmoustache 4y ago
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).

nextaccountic 4y ago

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

badsectoracula 4y ago
> 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