The future of 32-bit Linux [LWN.net]

The future of 32-bit Linux

Posted Dec 6, 2020 14:08 UTC (Sun) by glaubitz (subscriber, #96452)
In reply to: The future of 32-bit Linux by pizza
Parent article: The future of 32-bit Linux

> That only works if you have the source code to everything and/or infinite developer-hours at your disposal.

We have the first requirement fulfilled in the open source world. And you don't really need infinite developer hours, it's not as bad as you claim it is.

> Binary compatibility going back decades is the primary reason Intel and Windows are still relevant.

Windows isn't really binary compatible. You can't run many Windows 95 binaries on Windows 10 anymore. Linux has, in fact, a much better binary compatibility allowing you to run software from the 90s provided that you have the necessary shared libraries as well.

to post comments

The future of 32-bit Linux

Posted Dec 6, 2020 15:18 UTC (Sun) by pizza (subscriber, #46) [Link]

> Windows isn't really binary compatible. You can't run many Windows 95 binaries on Windows 10 anymore. Linux has, in fact, a much better binary compatibility allowing you to run software from the 90s provided that you have the necessary shared libraries as well.

"Provided you have the necessary libraries" can be a pretty massive undertaking, and is one of the points of the TFA. It's also not a new problem; commercial users of Linux have been complaining about this for over twenty years, and another point of the TFA is that commercial users are beginning to discover just how much they've been reliant upon volunteers, and if they want something differently, they're going to have to start paying to get what they want. And perhaps the main point of TFA is that "solving this in software" is exactly what's being done at the kernel level, because that's a lot smaller/simpler/cheaper than getting every random binary to get recompiled/fixed for 64-bit systems. And new software built/tested/fixed for 32-bit systems.

Meanwhile. IIRC, generally it wasn't the Win95 applications that have problems, it's the *installers* for those Win95-era applications, which relied on 16-bit Win3.1-era binaries that don't work on x86_64.

Offhand I can only think of a handful of Win95-era applications/games that simply didn't work on more modern systems, one relied on Win95 not trapping an illegal memory access, and the others relied on reserved filenames like "CON". (I'm also deliberately skipping over applications that required specific hardware/device drivers that never got ported to later versions of Windows)

But there were plenty of applications that technically ran, but were only ever tested on Win95 and therefore assumed they had full administrator access and behaved accordingly, writing files anywhere they wanted and other questionable assumptions. I should point out that this was in violation of MS's guidelines. WinXP SP2 further tightened down many other areas that were critical for changing Windows' reputation as security swiss cheese, but this "broke binary compatibility" and pissed off a lot of users.

But with regards to the latter; random decades-old Linux binaries will find themselves in the same boat when plonked down into modern distributions; assumptions they made about how things are laid out might not hold, and if they directly interfaced with kernel interfaces (eg OSS, specific /proc files, VFL1, or whatever) they might not get very far.

(In more modern times, the general attitude towards this sort of backwards compatibility has shifted towards "Just run the old system in a VM and firewall the crap out of it" -- That's what MS finally did with Win10, including XP in a sandboxed VM)