4 ms·
Linux can do this; binaries from the 90s work today. Something like xv (last release: 1994, although the binaries were built against Red Hat 5.2 from 1998) sti
by arp242 3y ago
Linux can do this; binaries from the 90s work today.
Something like xv (last release: 1994, although the binaries were built against Red Hat 5.2 from 1998) still work today, and the source still builds with one very minor patch last time I tried it.
The problem running the binaries is:
% ldd ./usr/X11R6/bin/xv
linux-gate.so.1 (0xf7f82000)
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7e22000)
libjpeg.so.62 => not found
libpng.so.2 => not found
libz.so.1 => /usr/lib32/libz.so.1 (0xf7e08000)
libm.so.6 => /usr/lib32/libm.so.6 (0xf7d0b000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf7a00000)
libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7cde000)
/lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xf7f84000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7cd8000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7cd1000)
And Windows has exactly the same problem, but the tradition is to ship these things with the application rather than just assume they're present on the system. And you can "fix" it by getting old versions, or even:
% ln -s /usr/lib/libjpeg.so.8 libjpeg.so.62
% ln -s /usr/lib/libpng16.so.16 libpng.so.2
You'll probably run in to trouble with PNG and JPEG files, but e.g. loading/saving GIF and whatnot works fine. Note how libc and libX* work out of the box.
tl;dr: much of the "Windows compatibility" is just binaries shipping with all or most dependencies.
Try it yourself: http://www.trilon.com/xv/downloads.html http://www.trilon.com/xv/downloads.html
- mkup 3y agoMuch of the Windows compatibility is "just" stable API for Windows controls, GUI event handling loops, 3D graphics and sound (DirectX). Linux has stable API for files and sockets (POSIX), but that's all.
- pjmlp 3y agoThis is also the biggest different between proper desktop operating systems since forever, and the fragmented Linux distributions. Available API means the whole stack, everything needed to write applications end to end, regardless of their purppose, not CLI and daemons.
- arp242 3y agoAnd I am saying you don't need to rely on any of that. You can just ship it yourself (statically link, or use LD_LIBRARY_PATH). That's what Windows applications that rely on GTK or Qt do as well, and it works fine, which works well, and it works fine for Linux too. The basics (libc, libX, etc.) are stable, and the Linux kernel is stable. And this is what Windows does too really, with MSVC and dotnet and whatnot redistributables. It's just that these things are typically included in the application if you need it. It's really not that different aside from "Python vs. Ruby"-type-differences, which are are meaningful differences, but also actually aren't all that important.
- pjmlp 3y agoNot really got the point, no wonder Linux Desktop development is as it is, and Google needed to step in.
- deleted 3y ago[deleted]
- account42 3y agoStop spreading FUD, X and OpenGL have maintained stable ABIs. There is Wayland now but even that comes with Xwayland doe maintain compat. Sound is a bit more rocky but there are compatibility shims for OSS and alsa for newer audio architectures.
- mkup 3y agoStop claiming that I'm spreading FUD and show me at least one Linux app which was compiled to the binary code in 1996 and exactly that binary code still runs under modern Linux desktop environment and has similar visual style to the rest of builtin apps. Got no counterexamples? Then it's not FUD at all, rather a pure truth.