Talk:Fat binary: Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 19:31, 13 July 2006

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Revision as of 18:31, 13 July 2006 edit Sneeper (talk \| contribs) 26 edits No edit summary ← Previous edit		Revision as of 19:31, 13 July 2006 edit undo Guy Harris (talk \| contribs) Extended confirmed users 76,225 edits →32bit vs 64bit also called fat binaries?: Yes, a fat binary has 2 or more binaries in it, from the set {PPC, PPC64, x86}. Next edit →
Line 50:		Line 50:

	--[[User:Sneeper\|Sneeper]] 18:31, 13 July 2006 (UTC)		--[[User:Sneeper\|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. [[User:Guy Harris\|Guy Harris]] 19:31, 13 July 2006 (UTC)