Talk:Fat binary

source distribution is universal

I've pulled the pointless section on FreeBSD not needing Fat binaries, for loads of reasons.

It's not the only source-based system.

It HAS got binary apps, and there's even pkg_add for it

ELF doesn't even support Fat binaries, but we don't mention every other ELF-based system (Linux, every other BSD, BeOS, etc)

I could go on, but there's no need, really.

--Kiand 17:36, 4 Jun 2005 (UTC)

---

i notice that the current intro mentions source distribution generically. it's true that source distribution makes a program more portable, even to unknown processors, but it's more of an abstract notion than an easy recipe. source code for a large app usually doesn't just port over. often it takes a lot of work to adapt it to the new environment and new compiler. Whiner01 09:38, 7 June 2006 (UTC)

installer

about using an installer to chose the suitable binary: how is the installer supposed to execute? --anon, undated

---

a logical quesion. if there are two install programs, you could accidentally launch the PowerPC install, which would run emulated and install the PowerPC version without blinking. that would not be good. in a dual release that does not use fat binaries at all, they would have to make the main install program a PowerPC program so that it will will run on either platform. the updated install program would have to detect emulation and then decide for you which version to install (or offer you a choice, if it's polite). if it is runing on the new x86 architecture and is about to install the x86 version, it could continue in the PowerPC installer to finish the x86 installation, or it could launch an x86 installer program that will do the same.

even if they never install the application as fat binaries, they could be cute and use a fat-binary program as the installer. assuming the two codes are compiled from the same source, the source code would have to be written to detect emulation and then offer you a choice or decide for you.

as mentioned elsewhere, the installer need not be an executable. if the package file contains only data or directives that are not in machine code, then it can easily be platform independent. the PowerPC installer would ignore the sections in the package that refer to x86 options and follow only the PowerPC-relevant information, resulting in an install for the PowerPC. the x86 installer would understand all sections of the file, including the new x86 options, so it would install appropriately for the x86 architecture. Whiner01 09:38, 7 June 2006 (UTC)

That wouldn't work with OS X drag-install applications, where there is no installer, although if a dmg can have a script associated with it that's run before the Finder opens up the window for it, the script could remove one of the bundles and rename the other bundle to have the appropriate name. Guy Harris 17:58, 7 June 2006 (UTC)

installer

The Installer part has to go... doesn't make any sense. --anon, undated

---

It does have to go. Only Windows has this obsession with installers being self-executable; on most other platforms you have an installer app that uses platform-independent files. BeOS's SoftwareValet supports this, and I presume Apple's .pkg system does too. --Kiand 16:34, 23 February 2006 (UTC)

---

some Windows drivers and apps actually do install by launching an .inf file, which contains only text data. Or by launching advpack.dll on the .inf file. Then there's .msi (Microsoft Installer) files, which are probably not executable either. Whiner01 09:38, 7 June 2006 (UTC)

out of synch

a weird possibility: the existence of two executable parts creates the possibility for them to get out of synch. like an HTML e-mail with an alternate text version, nothing enforces that the two have to say or do the same thing, even though they are supposed to. the two codes could do very different things. on a computer with one architecture, the code for the other architecture could get corrupted and no one would notice. in fact, the other code could be used as a data space or a hiding place. since the two executable parts are not simple translations of each other, there is no simple utility to compare the parts to make sure that they match. the only way to revalidate a file would be to compare it to a backup copy of the same file. or keep a checksum of the original and re-verify it.

User Guy Harris, in his recent edit, mentioned that OS X has a command, "lipo" which, presumably from its name, "removes the fat" from a fat binary file -- removes from it the unused executable code for the other processor. discarding the unused sections eliminates the wondering about what might be there, as well as freeing up the space they took. Whiner01 09:38, 7 June 2006 (UTC)

32bit vs 64bit also called fat binaries?

Apple's seems to refer to binaries that include 32-bit and 64-bit code as Fat Binaries. From http://www.apple.com/macosx/features/64bit/:

Tiger simplifies software distribution with support for fat binaries, applications that contain both 32-bit and 64-bit binaries within a single file. Using fat binaries, network administrators distribute a single version of an application to all users regardless of their system capabilities. Once installed on a user’s system, the fat binary automatically selects the appropriate code for the system without user intervention. This greatly simplifies administration, installation and distribution of applications.

Should this be mentioned in the article?

--Sneeper 18:31, 13 July 2006 (UTC)

Yes. It's the same mechanism. The Mach-O header for a binary has "CPU type" and "CPU subtype" fields, indicating what the binary requires, and a "fat" binary has multiple binaries in it with different headers. The CPU type distinguishes 32-bit PowerPC from 64-bit PowerPC from x86; a Universal binary is a fat binary with x86 and 32-bit PPC binaries, but a fat binary could also have 32-bit PPC and 64-bit PPC binaries, and could even have had it before the first x86 Macs came out. Such a binary would probably be a command-line app, given that those are the only 64-bit binaries supported (none of the Apple frameworks are 32-bit/64-bit fat, they're all 32-bit-only). It would even be possible to have a 3-way fat binary, with PPC, PPC64, and x86. Guy Harris 19:31, 13 July 2006 (UTC)

Agreed. Dual-mode (32/64) binaries are becoming more and more relevant now. --Synetech (talk) 23:57, 28 February 2009 (UTC)

Mach-O File Format doesn't support Fat Binaries

According to [1] The Mach-O File Format doesn't support Fat Binaries. A Fat Binary contains a Header (struct fat_header) and nfat_arch's fat_arch structures (struct fat_arch). The structures describes the size and offsets of the Mach-O files in the archive.

References:

[1] Apple Computer, Inc. "Universal Binaries and 32-bit/64-Bit PowerPC Binaries". Mac OS X ABI Mach-O File Format Reference. http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/index.html. Retrieved on 02.11.2006

NeXT Four-architecture FAT Binaries?

I never used NeXT, but in this blog posting (see entry for Friday June 03) someone who did claims:

NeXTSTEP used to support FAT binary for four architectures - Motorola 68k, Intel x86, HP PA and Sun SPARC (NIHS). And it worked pretty well. Gcc compiler for NeXTSTEP had an option to produce objects for all four targets at the same time, and linker and runtime loader all supported this very well. A single executable file can contain object codes for four different architectures, and many applications were distributed for all four (NIHS), or at least for 68k and x86 (NI).

If this can be verified it would be very interesting to see some more detail.

Dan Shearer 16:36, 16 August 2007 (UTC)

That's what's described in the "NeXTSTEP Multi-Architecture Binaries" section of the article. Guy Harris 17:48, 16 August 2007 (UTC)

When the article says "both on NeXT's Motorola 68k-based hardware and on Intel IA-32-based PC's running NeXTSTEP, with a single

binary file for both platforms" I think it should say whatever the accurate words are to indicate that 4 architectures were

supported in production rather than just 2, as stated. Many people are familiar with 2-architecture fat binaries in various places

but this example of 4 architectures is I am sure very little-known.

81.187.51.64 13:50, 17 August 2007 (UTC)

Right after that the article says "It was later used to allow OPENSTEP applications to run on PCs and the various RISC platforms OPENSTEP supported." That's the "four architectures" part; it doesn't explicitly say "four architectures", it leaves that up to the NEXTSTEP page, which says "The last version, 3.3, was released in early 1995, by which time it ran not only on Motorola 68000 family processors, but also IBM PC compatible x86, Sun SPARC, and HP PA-RISC." Guy Harris 16:10, 17 August 2007 (UTC)

Mechanism for Family-Mode Applications?

Back in the OS/2 1.2 days we had family mode applications. I have no idea what the executable file format was nor the execution mechanism, but I know that if you threw the right compiler switch you got a "family mode" application, a single binary that worked on both DOS and OS/2, and later both MS and IBM OS/2, and all relevant DOSs. I'm assuming it was a FAT binary. Anyone know where facts can be found?

Dan Shearer 16:41, 16 August 2007 (UTC)

That sounds more like compiling the program into some kind of DOS compatibility mode than a fat binary. It's still the same cpu architecture... and as far as I know, OS/2 could run most DOS programs, right? Unsound (talk) 10:45, 16 June 2008 (UTC)

VMS / Alpha

This article seems to be Mac-centric; should mention VMS / Dec Alpha dual mode executables, among other things... AnonMoos (talk) 09:54, 26 October 2008 (UTC)

DOS / Windows Dual-EXEs

How about a mention of the little-used trick of combining DOS and Windows versions of a program so that it can run under either environment. It’s been a while, so I don’t recall off hand the method other than it limited the DOS version to 64K because it would be in the header and required a check-jump combo. --Synetech (talk) 23:57, 28 February 2009 (UTC)

I think it's worth mentioning, since even Microsoft used it at least once: earlier versions of regedit.exe could run both under DOS and Windows 95. There was some also some magic happening with scandisk.exe, though it seemed a different case. --Azarien (talk) 13:06, 21 October 2010 (UTC)