5.1 Merge window part 1

Posted Mar 18, 2019 4:37 UTC (Mon) by dvdeug (subscriber, #10998)
In reply to: 5.1 Merge window part 1 by anton
Parent article: 5.1 Merge window part 1

ELF support came to Linux in 1995 (e.g. Slackware 3.0), the same year as Windows 95 (the first 32-bit consumer Windows) was released. And modern Windows doesn't support 16-bit programs, so Linux without a.out support offers support as far back as Windows does, about 24 years. It's a lot easier to run an old Linux in a VM, but there's more support for emulating old Windows programs.

In any case, proprietary code has been rare on Linux, and definitely pre-1995. Besides bragging rights, what do you gain from having a.out support in Linux?

to post comments

5.1 Merge window part 1

Posted Mar 18, 2019 16:55 UTC (Mon) by deater (subscriber, #11746) [Link] (2 responses)

> In any case, proprietary code has been rare on Linux, and
> definitely pre-1995.

Not necessarily true. A lot of software back then depended on the Motif gui library, so even nominally free software ended up being statically linked against that.

I know I had an a.out "xmcd" binary that I used for many many years after the ELF transition, though I do admit I no longer run a.out files on a regular basis (though I do regularly run binary-only software written in the 1980s, just not on Linux).

5.1 Merge window part 1

Posted Mar 19, 2019 8:33 UTC (Tue) by dvdeug (subscriber, #10998) [Link] (1 responses)

Wow, https://www.amb.org/xmcd/ is still up and that page is a blast from the past. Last change was in 2004, so you might be able to compile a new version, but I don't know how well it would work with PulseAudio.

Hopefully current virtual machines would handle the need for running Motif-linked binaries. It seems unlikely a GUI program would need the blistering speed of native hardware, and the more complex library-wise you get, the more headaches you get trying to install that on a modern system.

5.1 Merge window part 1

Posted Mar 26, 2019 13:12 UTC (Tue) by nix (subscriber, #2304) [Link]

The painful part might be actually accessing a CD drive from inside the VM. Even with various forms of USB and ATA passthrough, in my experience it's still a toss-up whether that sort of thing works or causes an obscure and ridiculous error or even crashes the host (not with USB, but ATA/PCI passthrough is evil).

5.1 Merge window part 1

Posted Mar 19, 2019 9:32 UTC (Tue) by anton (subscriber, #25547) [Link] (9 responses)

32-bit Windows programs were supported since Windows NT (release 1993), and Win32s for Windows 3.1 (beta 1992). And Windows 10 (the most modern Windows) actually does support 16-bit applications in its 32-bit variant. Anyway, the issue is about running 32-bit binaries, just a different format.

I have 5 OMAGIC, 9 ZMAGIC, and 14 QMAGIC binaries in my /usr/local/bin. One of the QMAGIC binaries is from a program that I have in source but that does not compile with current gcc (unfortunately, gcc maintainers like to break existing programs in newer gcc versions; of course they justify it by claiming that the programs were broken before, but that does not change the fact that they don't compile programs that they used to compile in earlier versions). I have not checked the others whether they can be compiled.

So what do I gain? I can run old binaries, without needing to recompile them, which may not be possible, and in any case, requires some effort.

There is value in being able to run old software: We can better study and compare it if we can run it. And the basis of all that is a willingness to support it.

If the Linux kernel maintainers retract their support for old software, why should those who you point to as alternative not retract support, too. E.g., you claim we can run old Linux kernels in a VM, and old binaries in that. But why should VM maintainers support old Linux kernels? Do you guarantee that they won't change their VM a few years down the road in a way that supports only modern kernels that don't have a.out support if you get your way?

5.1 Merge window part 1

Posted Mar 19, 2019 10:00 UTC (Tue) by edeloget (subscriber, #88392) [Link] (4 responses)

> But why should VM maintainers support old Linux kernels?
> Do you guarantee that they won't change their VM a few years
> down the road in a way that supports only modern kernels
> that don't have a.out support if you get your way?

Wouldn't that be antithetical to the purpose of a virtual machine, which is to provide a kind of emulation layer for the hardware? A VM that can only run a selected list of OS is of no use, and they cannot assume what you'll feed to them.

5.1 Merge window part 1

Posted Mar 19, 2019 12:44 UTC (Tue) by anton (subscriber, #25547) [Link] (3 responses)

I am not an expert on the business of VMs, but I imagine that, just like some here don't consider it the purpose of the kernel to run old binaries, VM maintainers might also consider it not their purpose to run old OSs: They could (and probably do) decide to emulate hardware that is too recent for OSs above a certain age.

5.1 Merge window part 1

Posted Mar 19, 2019 19:08 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Nobody stops you from using an old version of QEMU. It should be fine for the next 25-30 years or so - before Linux developers remove ELF in favor of something newer like TROLL.

5.1 Merge window part 1

Posted Mar 21, 2019 21:47 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I feel like options such as ENT (executable notation table) or HOBBIT (handy object bundles built in tandem) would be better.

5.1 Merge window part 1

Posted Mar 19, 2019 23:41 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

Given that SIMH exists, and includes emulations for computers that are older than the first operating systems, I am not overly worried on this score :)

5.1 Merge window part 1

Posted Mar 19, 2019 21:24 UTC (Tue) by dvdeug (subscriber, #10998) [Link] (3 responses)

I thought about Windows NT, but I forgot about Win32s. But by that standard, Linux wins hands-down; it can run applications written for Unix in 1977, provided they were written in Bourne Shell. The question is running the applications that people want to run on the modern systems they're running, and the last 16-bit Windows programs came out quite a bit after the last Linux a.out programs.

Most versions of Linux can't run ix86 binaries; only those compiled for ix86 or AMD64 can. Had Intel had their way, we'd be running Itanium without direct support for ix86 binaries. Perhaps in five or ten years, we'll be running ARM64 without direct support for ix86 or AMD64 binaries.

We can better study something in its home environment, not by running it on a modern system where various things might not work (audio, modern resolutions, USB).

Out of the box, Retropie supports the ZX-Spectrum, the TI-99, the MSX, the Atari ST, the Coco, the Colecovision, the Amstrad CPC, Amiga, SAM Coupé, the Macintosh, MS-DOS and the Commodore 64, along with dozens of other, usually more gaming focused, systems. It seems unlikely emulating x86, one of the most common computer hardware platforms of all time, will be a big problem for the foreseeable future.

You're demanding that Linux accept your solution for your obscure problem; there's not that many people who ran Linux before 1996, and many of those have given up all their old binaries from the time. If you were volunteering as a maintainer, you'd have more say in if this feature stays; if you were looking for solutions to a problem, people will be more willing to help. But to demand that a feature that doesn't fully work (i.e. core dumps were broken) be the only possible solution to your problem isn't helpful.

5.1 Merge window part 1

Posted Mar 21, 2019 17:57 UTC (Thu) by anton (subscriber, #25547) [Link] (2 responses)

Most versions of Linux can't run ix86 binaries; only those compiled for ix86 or AMD64 can.

That's beside the point. This is not about running binaries for one architecture on other architectures, this is about removing support for a binary format, i.e., a pure software issue.

[But anyway, the statement is wrong. IA-32 binaries could be run on Linux-Alpha. Someone reported running an ARM binary of Gforth on an Intel-based Android tablet; and I expect that Android also has emulation the other way round.]

We can better study something in its home environment, not by running it on a modern system where various things might not work (audio, modern resolutions, USB).

I study and compare things in many different environments. One thing that I study is how the various versions of the software perform on hardware, both on old hardware and new hardware. And to do that, I need to run the old software on new hardware, with (necessarily) new kernels. Retropie won't help me with that. And fortunately, audio, resolutions, and USB are no problems for the stuff I do.

You're demanding that Linux accept your solution for your obscure problem

I just object to removing a feature from the kernel that I use.

If you were volunteering as a maintainer, you'd have more say in if this feature stays

Did anybody ask for a maintainer? In any case, are you suggesting that, when Linus Torvalds says "Breaking user programs simply isn't acceptable", he means "Breaking maintainer programs simply is not acceptable, but breaking non-maintainer programs is"?

But to demand that a feature that doesn't fully work (i.e. core dumps were broken) be the only possible solution to your problem isn't helpful.

The feature works better now than with the proposed change; that's why I object to the change.

Someone suggested a userspace loader for a.out binaries. When that works with little overhead, it will be acceptable for me, too, but somebody has to write it, while the kernel support exists, and works better than the current state (non-existence) of the userspace loader.

5.1 Merge window part 1

Posted Mar 21, 2019 19:53 UTC (Thu) by excors (subscriber, #95769) [Link]

> Someone reported running an ARM binary of Gforth on an Intel-based Android tablet; and I expect that Android also has emulation the other way round.

Intel developed an ARM-to-x86 binary translator (Houdini) for their Android BSP, for compatibility with popular apps that contain ARM-only native code; I suspect that's why it worked. I doubt anyone has done it the other way round, because there are approximately zero Android apps with Intel-only native code.

5.1 Merge window part 1

Posted Mar 22, 2019 0:42 UTC (Fri) by dvdeug (subscriber, #10998) [Link]

Then Windows is moot? Cross-Linux compatibility versus Windows was certainly was part of the original discussion.

At this point, I question the relevance of any numbers you get comparing these a.out binaries to modern systems. You're comparing a program compiled for the original Pentium with GCC 2.7 (at the latest) and libc4 to a different program natively running on a recent version of AMD64 using modern versions of GCC and GNU libc. Where the faults lay for speedups and slowdowns is going to be very hard to tell. In any case, for the near future, you can run a Linux 5.0 kernel in an virtual machine if you want to compare things.

I'm not Linus, but I'm certainly more worried about some of the lost filesystem support making file recovery quite complex than I am about forcing a.out binaries to be run via qemu or a userspace loader, if anyone cares to write one. Supporting ancient binaries is much better and easier handled by emulators than trying to maintain a 25-year old environment mixed in with a modern one.