251–260 of 459 posts
What's up with all this "My 20 year old software still works!!!". Who actually runs unmaintained abandonware? I would rather prefer OS devs not wasting time maintaining legacy cruft and evolve with the times.
https://store.steampowered.com/app/7620/Railroad_Tycoon_II_P...
I return to that game for a few quick sessions every couple of months.
> In Linux, you can make system calls directly... > In Windows, you do not make system calls directly, Instead, you dynamically link to libraries that make the system calls for you. Isn't the actual problem the glibc shared library since the Linux syscall interface is stable? (as promised by "don't break user space") - e.g. I would expect that I can take a 20 years old Linux binary which only does syscalls and run th…
Yes
> I would expect that I can take a 20 years old Linux binary which only does syscalls and run that on a modern Linux, is that assumption wrong?
You’re right. But those apps are simple enough that we could probably compile them quicker than they actually run.
> I expect that Windows is full of application specific hacks under the hood to make specific old applications work.
Yes [0]!
> just using WINE as the desktop Linux API won't be enough, you'll also have to extend the "don't break user space" promise from the kernel to the desktop runtime environment
Yes, but. Windows is the user space and kernel for the most part. So the windows back compat extends to both the desktop runtime and the kernel.
You might argue it’s a false equivalence, and you’re technically correct. But that doesn’t change the fact that my application doesn’t work on Linux but it does on windows.
Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to compile software into dubious blobs and ship those to users. You could get rid of an awful lot of malware and massively simplify software distribution if you were to distribute a platform agnostic intermediary representation of source code that preserves enough s…
> dubious blobs I think you are just suggesting to replace binary blobs with other binary blobs e.g. CLR/.NET assemblies/executables or WebAssembly files. Or do it the JavaScript way: distribute compressed minified (kinda compiled) source code and the runtime JIT compiles it at runtime (e.g. V8 engine Turbofan compiler).
Earlier quoted context omitted.
> Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an older Debian/Fedora that ships the needed libraries to the packaging repositories and running apt/dnf should work in theory, although unfortunately might not in practice due to the general incompetence of programmers and distribution maintainers. Got it. So e…
> So everything is properly designed but somehow there's a lot of general incompetence preventing it from working. But it is working, actually: * If you update your distro with binaries from apt, yum, zypper etc. - they work. * If you download statically-linked binaries - they work. * If you download Snaps/Flatpak, they work. > it means that you have to build on the oldest bistro you can find so that the built binari…
Even statically linked code tends to be dynamically linked against glibc. You’ve basically said “it works but only if you use the package manager in your OS”. In other words, it’s broken and hostile for commercial 3p binary distribution which explains the state of commercial 3p binary ecosystem on Linux (there’s more to it than just that, but being actively hostile to making it easy to distribute software to your platform is a compounding factor).
I really dislike snaps/flat pack as they’re distro specific and overkill if I’m statically linking and my only dynamic dependency is glibc.
Earlier quoted context omitted.
> Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an older Debian/Fedora that ships the needed libraries to the packaging repositories and running apt/dnf should work in theory, although unfortunately might not in practice due to the general incompetence of programmers and distribution maintainers. Got it. So e…
Windows toolchain (even gnu) just provides old libraries to link with. This should work the same on linux, and AFAIK zig does just that.
Earlier quoted context omitted.
> that's not what applications are coded against anymore Not sure I follow. Sure, most modern programs are not using old-school WinAPI with GDI, but the stuff they added later is also rather stable. For example, the Chromium-based browser I’m looking at uses Direct3D 11 for graphics. It implements a few abstraction layers on top (ANGLE, Skia) but these are parts of the browser not the OS. I view all that modern stuff…
I agree. On Linux (and Mac really), new APIs replace old ones and old binaries stop working. On Windows, new layers are applied over the old. There is DirectX 9-12. New binaries may use 12 but the ones still using 9 are perfectly happy. Things like .NET work the same. You can have multiple apps installed relying on different .NET versions.
I've read the article and the comments with interest. I just have a question: if Windows ABI is so stable that 20-year-old programs are guaranteed to run, why are there computers with Win95 or NT that nobody dares touching lest some specific software stops working? I see plenty of these in industrial environments, but also in public libraries, corporate databases, etc.
Relatedly, at a previous job we ran an absolutely ancient piece of software that was critical to our dev workflow. The machine had an issue of some sort, so someone imaged the hard drive, booted it as a VM and we resumed business as usual. Last I heard it was still running untouched, and unmaintained.
Earlier quoted context omitted.
> Also glibc (contrary to the author's false claims) and properly designed libraries are backwards compatible, so in principle just adding the debs/rpms from an older Debian/Fedora that ships the needed libraries to the packaging repositories and running apt/dnf should work in theory, although unfortunately might not in practice due to the general incompetence of programmers and distribution maintainers. Got it. So e…
Windows toolchain (even gnu) just provides old libraries to link with. This should work the same on linux, and AFAIK zig does just that.
> In Linux, you can make system calls directly... > In Windows, you do not make system calls directly, Instead, you dynamically link to libraries that make the system calls for you. Isn't the actual problem the glibc shared library since the Linux syscall interface is stable? (as promised by "don't break user space") - e.g. I would expect that I can take a 20 years old Linux binary which only does syscalls and run th…
> Isn't the actual problem glibc since the Linux syscall interface is stable? Yes > I would expect that I can take a 20 years old Linux binary which only does syscalls and run that on a modern Linux, is that assumption wrong? You’re right. But those apps are simple enough that we could probably compile them quicker than they actually run. > I expect that Windows is full of application specific hacks under the hood to…
Just wanted to point out that ABI stability alone probably isn't the reason why Windows is so backward compatible, there's most likely a lot of 'boring' QA and maintenance work going on under the hood to make it work.
Also FWIW some of the early D3D9 games I worked on no longer run on out of the box on Windows (mostly because of problems related to switching into fullscreen), I guess those games were not popular enough to justify a backward compatibility workaround in modern Windows versions ;)
Earlier quoted context omitted.
> So everything is properly designed but somehow there's a lot of general incompetence preventing it from working. But it is working, actually: * If you update your distro with binaries from apt, yum, zypper etc. - they work. * If you download statically-linked binaries - they work. * If you download Snaps/Flatpak, they work. > it means that you have to build on the oldest bistro you can find so that the built binari…
> Only if you want to distribute a dynamically-linked binary Even statically linked code tends to be dynamically linked against glibc. You’ve basically said “it works but only if you use the package manager in your OS”. In other words, it’s broken and hostile for commercial 3p binary distribution which explains the state of commercial 3p binary ecosystem on Linux (there’s more to it than just that, but being actively…
As for being overkill, surely you can see the advantage of having a single uniform distribution format from the end user's perspective? Which, sure, might be overkill for your case (although app isolation isn't just about dependencies), but the important thing is that it is a working solution that you can use, and users only need to know how to install and manage them.