241–250 of 459 posts
People always talk about this “I can run a 20 year .exe file” situation but when I tell you that I have never, in 30+ years, EVER had a need to run a 20+ year executable, it just makes me go… yeah, and? Sure I believe backwards compatibility is a nice to have feature, but I have never, nor do I think I will ever, have a need to run 20-year-old software.
Can't we freeze the functionality of libc? Why does it need to be updated so frequently?
And even if we make changes to its implementation, why do we need to bump the version number if the underlying API is still the same?
> Thesis: We should create a distro of Linux that runs Windows binaries by default via Wine. On Debian you're one package away: sudo apt install wine-binfmt Otherwise you're still pretty close: echo 'none /proc/sys/fs/binfmt_misc binfmt_misc defaults 0 0' >> /etc/fstab mount -a echo ':DOSWin:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register
> While the Linux syscalls themselves are very stable and reliable, the c library on top of them is not. Practically all of userland is based on libc, and therefore by proxy Linux itself has a binary compatibility problem. People who primarily use Linux often forget that Windows has the exact same problem. In the case of Windows libc is distributed as part of the Visual C++ runtime. Each version of Visual Studio has…
Earlier quoted context omitted.
There are few issues: 1. GNU libc is an exception in the world of compatibility. 2. You can't just dump a bunch of GTK libraries next to the binary and expect it to work. These libraries often expect very specific file system layouts.
In 2005 the hot new Windows technology was .NET Framework 1.1 or 2.0. You can't just dump Framework 1.1's libraries next to the binary and expect it to work either, it needs to be installed properly.
.NET 1.x tho, yeah.
> 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 that on a modern Linux, is that assumption wrong?
ABI stability for Windows system DLLs is also only one aspect, historically Microsoft has put a ton of effort into preserving backward compatibility for popular applications even if they depend on bugs in Windows that had been fixed in later Windows versions.
I expect that Windows is full of application specific hacks under the hood to make specific old applications work.
E.g. 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, even if it means "bug-by-bug-compatibility" with older versions.
Barely - most bigger programs did not adhere to all standards, but got custom fixes under the hood in follow-up windows versions.
Also, around 2001 was the big architectural change for desktop from DOS to NT, so this might seem like cherry-picking the timeframe selected.
Earlier quoted context omitted.
> wondering what really needed improved Maybe not much? A few months ago, I ran out of power (my mistake, I use full screen apps to avoid the distraction, so I didn't realize I was unplugged) After plugging in and restarting Linux then the ancient version of Word I was using, I got a pleasant surprise: the "autosaved" version of the document I was editing, with nothing lost! As for llm, Excel 2010 may not have been m…
So you're saying you're using Word 2010 and have no problem with files created recently? I find it surprising that modern word .docx is compatible with 15 year old Word
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…
> Shipping binary files is just plain bad in every way. Aren't .class and .jar files "binaries"? > Java already solved this problem, for the most part Maybe, just maybe, there are some drawbacks that mean that in fact it's not solved. Otherwise perhaps Java would've completely obsoleted C, C++. Some of us design applications which can't tolerate the worst case GC pauses, for example. Some of us design applications wh…
First of all, I should like to point out that such people are overwhelmingly deluded and come to this belief without ever actually having tested the hypothesis. But at any rate, the idea of a JAR file doesn't require garbage collection. We can already see this with things such as Wasm, though it doesn't quite achieve what I would want.