A question I got repeatedly the last couple days was, now that AARM (Apple ARM) is a thing, is the ultimate ARM-Intel-PowerPC Universal Binary possible? You bet it is! In fact, Apple already documents that you could have a five-way binary, i.e., ARM64, 32-bit PowerPC, 64-bit PowerPC, i386 and x86_64. Just build them separately and lipo them together.
You’ll be able to eventually build a binary that contains code for every Mac hardware and software platform starting from Classic all the way up to macOS Big Sur, and from m68k all the way up to ARM.
I doubt anyone will use it, but that doesn’t make it any less cool.
Meh, there’s nothing technically impressive about it to me.
I think intermediate bytecode is more useful in addressing interoperability in a holistic way. JVM, MSIL, LLVM-IR, ART, etc. These don’t really make news anymore, but they’re incredibly useful for architecture independent software.
Indeed. Apple does already support app-store binaries in LLVM bitcode, that they compile and optimize for the recipient’s processor. I can’t remember, but think that this is even compulsory for some platforms: watch perhaps?
Back in the 32bit days, when DOS was still behind the covers of Windows, you could use djgpp to create binaries that would run on Linux as well as Windows. I know, because I built some.
How did that work, as Windows would use PE and Linux ELF binaries?
I don`t know how technically those kind of binaries worked, but I remember that on Linux Game Tome there was regularly new version of installer, that was able to make installer for Windows, Linux and Mac in 1 single executable.
It was BitRock Installer. It seems that it still exist under other name: https://installbuilder.com/
Hm, maybe my memory don`t serve me well. It may be, that it wasn`t single executable 😀
Somehow you can specify an internal format inside of a EXE. I have some Linux native .exe’s that are elf inside instead of PE. Or someone was being cute and gave it a different extension and lied to me.
I guess it was not with PE binaries and possibly not even 32-bit. A utility I know of that works like that is bootlace.com from GRUB4DOS.
Hi,
I guess I must be getting old, strange that nobody answered this. @chriscox is referring to COFF binaries. Linux once used the a.out format and then COFF and finally around 1999 ELF became the standard executable format. In fact the Microsoft PE format is actually an extended version of the COFF format.
> You’ll be able to eventually build a binary that contains code for every Mac hardware and software platform starting from Classic all the way up to macOS Big Sur, and from m68k all the way up to ARM.
I don’t think this is possible, although perhaps somebody more knowledgeable and creative than me can see how. The reason ppc/x86/arm is possible is because they are all different formats within a Mach-O binary. Versions prior to OS X (ie., anything m68k) didn’t use Mach-O, they used CFM. There was a (different) cute trick when OS X was released where a CFM binary could use carbonlib and run natively on OS 9 (since it’s CFM) and the OS X loader was able to recognize it and execute it natively. But that’s (to the best of my knowledge) incompatible with a Universal binary which needed to be Mach-O, so there was never a binary that could be natively x86 and natively ppc/OS 9.
NeXTstep offered “Fat Binaries” (aka multiarchitecture binary) starting in 1993 for 68k, IA-32 then adding PA-RISC and SPARC. This consisted of different Mach-O subfiles. So this looks like an evolution of that approach.
This is exactly the source of macOS’ fat binary support. NeXTstep lives on!
you may be able to build such a binary, but it will likely not load on low memory system at all.
Unless you use XIP, then maybe.
Can xCode in 2020 still compile for PPC? Whatever version number xCode is now.. After SJ Apple seems to have been seduced by “sometimes-inconsistent version number mania”, so we have the iphone x alongside the iphone 8, with the iphone 8 *and* x (“10”) using an A11 chip and iOS 11 (I think I copied all that right from Wikipedia..). At least the chip number matches the OS number – is that consistent? At least for macOS they use the internal code names as public identifiers – which are easier to remember than numbers. (Or are the internal code names even stranger?)
30 years ago we had multi-platform disks that worked on both Amiga and AtariST (or Amiga and PC). Blew my mind at the time …
https://en.wikipedia.org/wiki/Dual_format