[FR] [IT]


Universal Binaries

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.
[ Actually, “Universal Binaries” may contain many more binaries, such as the up-coming Intel 64-bit or — for special non-GUI applications — PPC 64-bit code.]

Apple strongly discourages Intel-only applications.
[ Although only a recommendation, this is mainly due to the fact that Apple doesn’t want to confuse a user who transfers software from an Intel to a PPC Mac, it appears possible that Apple may, in the long run, wish to switch processors as it pleases. Please remember that Apple’s transition to Intel was essentially due to the fact that no adequate PPC CPUs were available for laptops! ]

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.
[ Currently, FB still uses the CFM/PEF format and it compiles for PPC only.]

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.
[ By the way, Intel’s code is said to be (slightly) better than that produced by the ggc4 although Apple has suggested and partly carried through many improvements to the gcc. — Xcode 2.3 will soon be available. ]

The PPC binary of a “Universal Binary” may be compiled for OS X 10.4.x, 10.3.9 [ or perhaps even 10.2.8 ] — according to the SDK — but not for earlier OS X-versions.

Xcode 2.2 comes with a utility called “lipo” [also a NEXTStep heritage] 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”.
[ At the moment, the only alternatives to ggc4 are the aforementioned Intel compilers; Absoft is expected to present (at least) another FORTRAN compiler soon.]

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.
[ Mac OS X 10.4.x still supports the Classic environment on PPC Macs but ships without MacOS 9.2.x. It is to be expected that this will change with Mac OS X 10.5.x; That is, no more Classic environment with Mac OS X 10.5.x: not for Intel Macs, but not for PPC either! ]

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.
[ Originally, and in Apple-speak, “Carbonized” code meant code that runs with MacOS 8.6-9.2.x and Mac OS X. FB does not ensure that this is valid if you do a “Carbon”-compilation, but no doubt, it will produce nice Mac OS X-only applications and that’s the concern here.]

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 [something that has long been overdue]; 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?

Definitely not!
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)


Herbie Gluender

Germany, 29/03/2006
  © 2000 Pix&Mix  
  All Rights Reserved

  FutureBASIC is a registered trademark of Staz Software, Inc and is used with permission.