
Thread beginning with comment 393291
To view parent comment, click here.
by steviant on Fri 6th Nov 2009 22:06 UTC in reply to "RE[2]: TYPO"
Member since:

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