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