Linked by Thom Holwerda on Thu 5th Nov 2009 23:05 UTC
Linux As we all know, Mac OS X has support for what is called 'fat binaries'. These are binaries that can carry code for for instance multiple architectures - in the case of the Mac, PowerPC and x86. Ryan Gordon was working on an implementation of fat binaries for Linux - but due to the conduct of the Linux maintainers, Gordon has halted the effort.
Thread beginning with comment 393216
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: TYPO
by memson on Fri 6th Nov 2009 10:56 UTC in reply to "RE: TYPO"
memson
Member since:
2006-01-01

That might be correct for NeXT, but Mac OS has also had FAT binaries since the days of 68000 to PPC conversion and they were implemented as this guy did - resources with in a single file. If you look at how NeXT solved this problem, it is a separate physical binary with in the .app folder hierarchy that represents the application. This is obviously conceptually similar, but not the same. From what I read, the guy had actually created a single binary file with a method for loading the correct binary section for the architecture/ABI being used. This is more like what Classic MacOS did - though people might wave the "resource" fork being at me, I guess. If you play the resource fork card, then this isn't the same at all and this guy probably was barking up an odd tree. To me it seems like the same idea though.

Reply Parent Score: 2

RE[3]: TYPO
by steviant on Fri 6th Nov 2009 22:06 in reply to "RE[2]: TYPO"
steviant Member since:
2006-01-11

That might be correct for NeXT, but Mac OS has also had FAT binaries since the days of 68000 to PPC conversion and they were implemented as this guy did - resources with in a single file. If you look at how NeXT solved this problem, it is a separate physical binary with in the .app folder hierarchy that represents the application. This is obviously conceptually similar, but not the same. From what I read, the guy had actually created a single binary file with a method for loading the correct binary section for the architecture/ABI being used. This is more like what Classic MacOS did - though people might wave the "resource" fork being at me, I guess. If you play the resource fork card, then this isn't the same at all and this guy probably was barking up an odd tree. To me it seems like the same idea though.


Fat-binaries ala legacy MacOS have always been part of NeXT's multi architecture strategy, applications that shipped with support for NextStep X86 and NextStep 68K would generally have used fat binaries, rather than separate binaries in the package.

Presumably they did this to allow interoperability between NS variants at the "Unix level" as well as the more generic "frameworks level".

Having the ability to package multiple copies of binaries and resources was important for allowing the NextStep (later OpenStep) frameworks to run on any OS, so that for example they could deliver executables in ELF format, or Windows PE format as well as their own Mach-O binaries in one package.

Reply Parent Score: 1

RE[3]: TYPO
by Lunix on Fri 6th Nov 2009 22:41 in reply to "RE[2]: TYPO"
Lunix Member since:
2009-10-14

68k/ppc fat binaries were implemented by storing the 68k code in the resource fork (as had always been done) and the ppc code in the data fork.

In OS X (and OpenStep), a mach-o file can contain multiple architectures. One binary, multiple architectures. eg:

file /Applications/SubEthaEdit.app/Contents/MacOS/SubEthaEdit (Bundle executable)
/Applications/SubEthaEdit.app/Contents/MacOS/SubEthaEdit: Mach-O universal binary with 2 architectures
/Applications/SubEthaEdit.app/Contents/MacOS/SubEthaEdit (for architecture ppc)Mach-O executable ppc
/Applications/SubEthaEdit.app/Contents/MacOS/SubEthaEdit (for architecture i386): Mach-O executable i386


$ file `which ls` (unix executable)
/bin/ls: Mach-O universal binary with 2 architectures
/bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/ls (for architecture i386): Mach-O executable i386

Reply Parent Score: 1