On 2021/02/16 14:25, John Paul Adrian Glaubitz wrote:
I can take programs in Win from 10-20 years ago and they still work on a current day win because the OS loads library updates by version.
That's actually not true. Microsoft fixed a lot of bugs in their ABI over the time and dropped support for various older ABIs when they switched to 64 bit Windows or rewrote fundamental subsystems such as the graphics or sound stack, so that a lot of older programs don't work anymore.
I have MANY programs on my machine from Win XP days and probably a few from before and they still run. You are talking about programs that did their own thing w/the underlying HW -- many graphics programs didn't use the DirectX interfaces or opengl, but ones that did still run. Problems with old programs that were tied to hardware access are not a software-library-versioning problem, so please don't confuse the issue.
I think there even used to be a WINE on Windows port to address this issue and allow older Windows applications on newer versions of Windows.
Win7 came with a WindowsXP mode for the few programs that wouldn't work on newer version -- mostly ones that did thing using the 16-bit API that WinXP supported from Win95/98 days. I did say 10-20 years ago, not 25 years ago -- but those were because of changing HW, not because new library versions were incompatible.
Unix did the same -- but move to linux, and vendors got lazy and stopped using the correct versions to link with. Why? And how can this be fixed?
Actually, you can run 30-year-old binaries on a current version of Linux as long as you provide the necessary shared libraries or the application is statically linked since the Linux kernel guarantees to never break any userspace code.
--- Actually you are bullshitting us. There was no linux 30 years ago this month and V1.0 didn't come out until 1994. I'm pretty sure it wasn't binary compatible. Even when the linux kernel doesn't break user space code, glibc will refuse to run on older kernels. Old apps need to keep around the old libs. But then you are saying what I said in saying that users need to provide the libraries -- it's not handled by the OS and that makes running older programs unviable as package managers like rpm, remove older versions of libraries when you upgrade, making it very difficult to support older progs that worked w/older libs. That said -- most linux progs don't link to shareable object libraries even using the major number. Some do, but when did you see someone linking with glibc-1 vs. glibc-2. As for glibc compat, theoretically under semantic versioning, glibc 2.1 should be compat with glibc 2.33 -- so again, I ask: Why are all the apps in TW being rebuilt w/new glibc vs. being replaced as those apps are updated?