Fat binary

From Wikipedia, the free encyclopedia

A fat binary (or multiarchitecture binary) is a computer program that is native to multiple instruction set architectures (ISA) and thus can be run on multiple processor types. The usual method of implementation is to include a version of the machine code for each ISA, resulting in a file larger than a normal one-architecture binary, thus the name.

Fat binary support is not commonplace among operating systems; there are several alternatives to solve the same problem, such as the use of an installer program to choose an architecture-specific binary at install time, distributing software in source code form and compiling it in-place, or the use of a virtual machine and Just In Time compilation.

1 Examples
- 1.1 Apple's Fat Binary
- 1.2 NeXT's/Apple's Multi-Architecture Binaries
2 References

[edit] Examples

[edit] Apple's Fat Binary

A fat binary scheme smoothed the Apple Macintosh's transition, beginning in 1994, from 68k microprocessors to PowerPC microprocessors. Many applications for the old platform ran transparently on the new platform under an evolving emulation scheme, but emulated code generally runs slower than native code. Applications released as "fat binary" took up more space, but they ran at full speed on either platform. They achieved this by packaging both a 68000-compiled version and a PowerPC-compiled version of the same program into their executable files. The older 68k code (CFM-68K or classic 68K) continued to be stored in the resource fork, while the newer PowerPC code was contained in the data fork, in PEF format.^[1])

Fat Binaries were larger than programs supporting only the PowerPC or 68k, which led to the creation of a number of utilities that would strip out the non-needed version. In the era of small hard drives, when 80 MB hard drives were a common size, these utilities were sometimes useful as program code was generally a large percentage of overall drive usage.

[edit] NeXT's/Apple's Multi-Architecture Binaries

[edit] NeXTSTEP Multi-Architecture Binaries

Fat binaries were a feature of NeXT's NeXTSTEP/OPENSTEP operating system, starting with NeXTSTEP 3.1; in NeXTSTEP, they were called "Multi-Architecture Binaries". Multi-Architecture Binaries were originally intended to allow software to be compiled to run both on NeXT's Motorola 68k-based hardware and on Intel IA-32-based PCs running NeXTSTEP, with a single binary file for both platforms. It was later used to allow OPENSTEP applications to run on PCs and the various RISC platforms OPENSTEP supported. Multi-Architecture Binary files are in a special archive format, in which a single file stores one or more Mach-O subfiles for each architecture supported by the Multi-Architecture Binary. Every Multi-Architecture Binary starts with a structure (struct fat_header) containing two unsigned integers. The first integer (magic) is used as a magic number to identify this file as a Fat Binary. The second integer (nfat_arch) defines how many Mach-O Files the archive contains (how many different versions of the same program for different architectures). After this header, there are nfat_arch fat_arch structures (struct fat_arch). This structure defines the offset (from the start of the file) at which to find the file, the alignment, the size and the CPU type and subtype the Mach-O binary (within the archive) is targeted at.

The version of the GNU Compiler Collection shipped with the Developer Tools was able to cross-compile source code for the different architectures on which NeXTStep was able to run. For example it was possible to choose the target architectures with multiple '-arch' options (with the architecture as argument). This was a convenient way to distribute a program for NeXTStep running on different architectures.

It was also possible to create libraries (e.g. using libtool) with different targeted object files.

[edit] Mach-O and Mac OS X

Apple Computer acquired NeXT in 1996 and continued to work with the OPENSTEP code. Mach-O became the native object file format in Apple's free Darwin operating system (2000) and Apple's Mac OS X (2001), and NeXT's Multi-Architecture Binaries continued to be supported by the operating system. Under Mac OS X, Multi-Architecture Binaries can be used to support multiple variants of an architecture, for instance to have different versions of 32-bit code optimized for the PowerPC G3, PowerPC G4, and PowerPC 970 generations of processors. It can also be used to support multiple architectures, such as 32-bit and 64-bit PowerPC or, as mentioned in the next section, PowerPC and x86^[2].

[edit] Apple's Universal binary

In 2005, Apple announced another transition, from PowerPC processors to Intel x86 processors. Apple promotes the distribution of new applications that support both PowerPC and x86 natively by using executable files in Multi-Architecture Binary format. Apple calls such programs "Universal applications" and calls the file format "Universal binary," perhaps to distinguish this new transition from the previous transition and other uses of Multi-Architecture Binary format.

Universal binary format is not necessary for forward migration of pre-existing native PowerPC applications, for this role Apple supplies Rosetta, a PPC emulator. However, Rosetta has a fairly steep performance overhead, so developers are encouraged to offer both PPC and Intel binaries, using Universal binaries. The obvious cost of Universal binary is that every installed executable file is larger, but in the years since the release of the PPC, hard drive space has greatly outstripped executable size; while a Universal binary might be double the size of a single-platform version of the same application, generally resources dwarf the code size, which becomes a minor issue. In fact, often a universal binary version of an application is smaller than 2 different version of an application (one each for PowerPC and Intel) because the resources have to be duplicated. Nevertheless, Mac OS X does include the lipo command-line application to remove versions from the Multi-Architecture Binary image.

As indicated in the previous section, Apple includes code in the Xcode development environment to allow applications to be delivered in both 32-bit and 64-bit versions. This is useful on both the Intel and PowerPC platform, both of which have shipped both 32 and 64-bit versions of the CPUs. Universal binaries created with this in mind can contain up to four versions of the executable code (32-bit PowerPC, 32-bit x86, 64-bit PowerPC, and 64-bit x86).