Jump to content

Talk:Fat binary

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by A876 (talk | contribs) at 09:38, 7 June 2006 (make sections; add comments). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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]

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]

Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Talk:Fat_binary&oldid=57330350"