From X-Plane SDK
Revision as of 23:47, 19 April 2009 by Admin (Talk | contribs) (1 revision)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This page was imported from the previous wiki engine. It needs a review and cleanup of formatting. Please see this page for more information.
X-Plane plugins and x86 Macintosh Hardware

This tech-note explains issues relating to X-Plane plugins on the new upcoming Intel-based Macinoshes.

! Background

X-Plane plugins are DLLs (DLLs/dylibs/shared objects/shlbs...DLLs have many names on many operating systems, but the principle is the same; for the context of this technote, DLL refers to the abstract idea of dynamically linked code objects, not a specific operating system construct).

Current Macintoshes use PowerPC CPUs; code always is written in the PowerPC instruction set.

OS X supports two executable formats/ABIs (technically it has two executable formats, with separate DLL constructs and two ABIs; they are never mixed and matched, e.g. CFM code is always in a shlb and Mach-O code is always in a dylib, so we will just refer to them as CFM and Mach-O, or as ABIs). CFM is supported on OS 9 and OS X. Mach-O is supported on OS X.

! Universal Binaries

Apple's basic strategy for the migration from PowerPC to Intel hardware is "universal binaries". A universal binary is a Mach-O code container with two versions of the DLL, one using the PPC instruction set and one in the x86 instruction set. When the system needs to load an application or an application needs to load a code library, it loads the appropriate version of the DLL based on the current instruction set.

(In other words, a universal binary is both x86 and PowerPC code; the system picks the one it needs.)

Since all current Macintosh applications are PowerPC only, Apple provides an emulator, Rosetta, that emulates PowerPC code on an x86 Macintosh. Emulation is done on a per-process basis; even witth emulation, all loaded DLLs must use the same instruction set.

! Current CFM/Mach-O Support

The current implementation of plugins works cross-ABI on OS X; you can write a plugin as a CFM shlb or a Mach-O dylib/bundle and the plugin manager will run it. For the most part, your plugin cannot tell and does not care whether the sim and XPLM are CFM, Mach-O, or some strange mix of the two.

! Limitations for x86 Mac Plugins

The main limitation of the X-Plane plugin system for Macintosh will be: no CFM plugins on an x86 machine running X-Plane natively. This is a pretty simple restriction: there is simply no way to package your CFM plugin with x86 instructions; Apple is only providing universal binaries for Mach-O code. This is not surprising either; CFM has been considered legacy, and is mainly used for OS 9 compatibility.

The problem is this: under Apple's universal-binaries system, all code must be either PPC or x86; instruction sets cannot be mixed and matched.* Therefore in order for a user to use X-Plane natively (as an x86 app), all plugins must be x86 as well.

What will happen if your plugin is installed in an x86 native copy of X-Plane for Macintosh and it is not a universal/x86 Mach-O binary? Basically it will be ignored and will not load.

Therefore there are two possibilities for a user: - Use X-Plane in x86 mode but only use universal/x86 Mach-O plugins. - Use X-Plane under Rosetta (with corresponding performance loss).

! Recommendations

Basically to do to support x86 Macintosh hardware, move your plugin to Mach-O and then compile it as a universal binary.