We are currently experiencing Apple’s transition from the PowerPC- to the Intel-based hardware accompanied by a corresponding software transition. Hence, users of the FB IDE might also ask what this transition means for their existing, and future, code and applications? Although specific statements about future versions of the FB IDE can’t be made yet, this document will cover general considerations of what needs to be done by the makers of FB and, by consequence, by FB coders.
In June 2005, Apple announced the transition would be completed in 2007 but in fact it will already be finished at the end of 2006. To cope with this accelerated hardware introduction, Apple has spent a lot of effort motivating and enabling software developers to rapidly create applications that run natively on Intel Macs. Apple’s essential source for all transition related questions is its “Developer Transition Resource Center”, as well as a dedicated session during this year’s WWDC that takes place in San Francisco in August 2006. Additionally, and for the first time ever, Apple has started a worldwide tour of free “Universal Application Workshops” for members of the ADC where Apple specialists provide detailed technical help for developers and lets them test their applications on their brand new hardware.
Most of the facts stated in this brief report can be found in Apple’s document “Universal Binary Programming Guidelines, Second Edition” (8 March 2006) that is also available as a PDF-file for downloaded. They are supplemented by information principally from the German edition of the Macworld journal and by the MacNN service. Comments and opinions are added in brackets.
As of now, all Mac applications are to be so-called “Universal Binaries”
A “Universal Binary” is a code package similar to a Mac OS X bundled application but containing an Intel and a PPC-binary that is, compiled code. As usual, it also contains resources, help-files and the like that are accessed by both code versions. Therefore, “Universal Binaries” are much slimmer than twice the size of the respective PPC applications.
Apple strongly discourages Intel-only applications.
The technique underlying “Universal Binaries” dates back to the first half of the 1990 when NeXT developed what was then called “FAT applications”; that is, applications that could be executed on four different platforms.
Both code portions of “Universal Binaries” must be in “Mach-O” executable format.
At the moment, there are only three compilers that generate “Mach-O” code for Intel Macs, namely ggc4 — part of Xcode 2.2 — and the brand new C(++)/FORTRAN compilers from Intel.
The PPC binary of a “Universal Binary” may be compiled for OS X 10.4.x, 10.3.9 — according to the SDK — but not for earlier OS X-versions.
Xcode 2.2 comes with a utility called “lipo” that produces a “Universal Binary” application from several “Mach-O” executables. This means that whatever compiler you use to produce code in Mach-O format for PPC and Intel, you can make “Universal Binaries”.
Intel CPUs don’t have an Altivec unit. Their vector processing unit is called SSE2 and works differently from Motorola’s Altivec. When using Apple’s “Accelerate Framework”, Xcode automatically produces the appropriate vector code whether compiling for Intel or PPC.
“Universal Binaries” must be tested on PPC and Intel Macs; that is, you need machines of both species!
“Universal Binary” applications won’t work with PPC-only plugins — but see below.
What happens with PPC-only applications on Intel Macs?
Intel Macs execute PPC applications by dynamically translating their code through a software interpreter named “Rosetta”. This is not a separate environment as “Classic” is, and the user is usually not aware of the type of application — “Universal Binary” or PPC — in use, except perhaps for the slower code execution due to “Rosetta”’s translating. However, this shouldn’t affect text editors and the like too severly.
“Rosetta’ is CFM/PEF and Mach-O compatible and it supports Altivec code. It does not run pre-Mac OS X applications, the Classic environment, applications requiring a G5 processor, nor various kinds of rather special code that cannot be produced by FB anyway. Most important: There is no way of running pre-Mac OS X applications on Intel Macs.
It is possible to force a “Universal Binary” application to run its PPC instead of its Intel binary and therefore to use “Rosetta” — this is done via "Get Info" in the Finder. This is necessary if PPC-only plugins are to be used with a “Universal Binary” application.
What does all this mean for FB and FB-coders?
If you are still distributing/selling pre-Mac OS X-only applications, then convert them to Mac OS X code as soon as possible. This process is called “Carbonization” in FB-speak.
If your applications run natively with Mac OS X, then, on Intel Macs, they will be interpreted by “Rosetta’.
Currently, FB does not generate “Universal Binaries”.
When will we see an FB release that produces “Universal Binaries”?
This requires at least two essential changes to the FB-compiler: First, it must be able to generate binaries in PPC Mach-O format ; second — and much more involved — it must be able to make corresponding binaries in Intel Mach-O format. The final integration — resulting in a “Universal Binary” application — may then be achieved by use of “lipo”.
Will an appropriate FB compiler create “Universal Binary” applications from existing FB code?
There are various operations the compiler cannot handle. Prominent examples are byte operations. As is known, the byte order for Intel processors is opposite to that for Motorola processors. For details and the discussion of further caveats, please consult “Universal Binary Programming Guidelines, Second Edition”. Apple tells us that “Cocoa developers may need to make fewer adjustments than Carbon developers whose code was ported from Mac OS 9 to Mac OS X.”
Evidently, FB developers are Carbon developers…
Herbie (28. March 2006)