Re: osX86 and frameworks
Re: osX86 and frameworks
- Subject: Re: osX86 and frameworks
- From: email@hidden
- Date: Tue, 07 Jun 2005 15:36:50 +0000
While this is true, these bundles are slightly superior because it is relatively simple to merge/strip executables from OS X bundles, as well as do versioning in frameworks.
While the 68k->PPC transition was done using the CODE resource vs. Data Fork code fragment to determine how to boot the binary, that isn't ideal in the long term (it was a kludge, essentially). It is possible to dump each executable into a separate fork, but then you have to also bring code for starting execution up to date on OS X by making a lot more stuff fork-aware, and this gets tricky when dealing with non-NTFS or non-HFS filesystems, as you then have to update those to handle forks as well. Apple tends to avoid doing full-scale re-writes like that in short order, as we have seen with how many steps is being taken to get the filesystem up to date with modern features.
While something like Rosetta is likely just as much work to pull off, bundles have already provided the bits needed to pull off this transition for years, and could be expanded to other arches in the future with ease. Unfortunately, it is hard to determine where Apple would go from x86 that would break binary compatibility again, since both AMD64 and x86-64 are striving for backwards compatibility with i386 code.
> On 2005-06-07 00:17, email@hidden said:
>
> >Well, the good news is that Frameworks, kernel extensions, and apps can
> >all be built as universal binaries. This is due to the bundle format
> >Apple adopted for OS X back when it debuted as the Public Beta.
>
> Its not really 'due to the bundle format', it could be (and was) done
> with the resource fork concept also. Happily, it'll work with bundles too.
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng email@hidden
> Rogue Research www.rogue-research.com
> Mac Software Developer Montréal, Québec, Canada
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden