Views
Personal tools

64 Bit

From X-Plane SDK

Jump to: navigation, search


This document describes the general status of 64-bit plugin support.

A 'how to' for moving a plugin to 64-bits can be found here.

Current status:

  • X-Plane 10.20 is in beta and ships with 32-bit and 64-bit apps that can run plugins.
  • The SDK 2.1.1 is out and contains 64-bit ready headers and libs for Windows.
  • The sample projects and sample code are not yet updated.

Contents

Background

X-Plane through version 10.0 is a 32-bit application; similarly all plugins use the 32-bit ABIs of their host platform.

However, Laminar Research is planning a patch to X-Plane that will feature both 32 and 64-bit executables. The 32-bit executables will continue for users who only have 32-bit operating systems (e.g. Windows XP) or 32-bit CPUs; the 64-bit executable will allow X-Plane to use more than 2-4 GB of virtual memory, which in turn will enable more add-ons, higher texture resolution, and world domination.

X-Plane plugins and the XPLM execute in-process (inside X-Plane's process), and therefore they must be the same ABI as X-Plane itself. Thus when X-Plane is 64 bit, all of its plugins must be 64-bit too.

The plan is to allow authors to ship "fat" plugins with both 32 and 64-bit binaries for multiple operating systems. The XPLM (running in 32 or 64 bits depending on which version of X-Plane is running) can then pick the right plugin binary.

Making the API 64-bit Safe

The X-Plane 1.0 and 2.0 APIs contain use of the C type "long". This type isn't 64-bit safe because its size varies by compiler when targeting 64 bits.

The X-Plane SDK 2.1 API addressd this by replacing all use of long with either int or intptr_t, depending on whether the integer type needs to be sized to fit a ptr by cast or not. This change does not affect 32-bit plugins but ensures that 64-bit plugins will compile properly on all compilers.

  • All counting APis remain "int", even in 64-bits. So for example, we will not be able to have more than 2^31 plugins installed, even on a 64-bit API.
  • Widget params and properties are meant to be pointer or integer storage, so they are now intptr_t for pointer safety.

When you adopt the SDK 2.1.0 or 2.1.1, you will need to change the declaration of your dataref callbacks and widget callbacks to not use long. As a general rule, do not use 'long' in plugins, since its treatment is inconsistent between compilers.

Making Your Code 64-bit Safe

While you are fixing type changes, you may want to examine possible 64-bit problems in your code. The main ones we have found so far while working with the XPLM and X-Plane are:

  • Pointers jammed into integral data types and vice versa. If you must do this, use intptr_t for the underlying int.
  • Assumptions about the size and padding of structures that contain pointers. In X-Plane, when we need to know that a structure really is as big as we think it is, we use a macro to catch mistakes at compile time like this:
compile_assert(sizeof(my_struct) == 8);

The macro is implemented like this:

#define UNIQUE_NAME                     MAKE_NAME(__LINE__)
#define MAKE_NAME(line)                 MAKE_NAME2(line)
#define MAKE_NAME2(line)                constraint_ ## line
#define compile_assert(x) typedef struct { int compile_assert_failed[(x) ? 1 : -1]; } UNIQUE_NAME;

The actual error it gives is a little cryptic, but this macro can validate that sizes are as expected.

For plugins, pay careful attention to the use of widget parameters and properties - the widgets API uses intptr_t to allow for struct passing, and some messages _do_ pass structs!

Fat Plugins and 64 Bits

The X-Plane 2.0 API introduced the concept of a "fat" plugin - that is, 3 binaries for 3 platforms in a single folder with resources. The goal of fat plugins was to make deployment simpler: a fat plugin can simply be dropped into place (or can remain inside a scenery pack or airplane) without modification, eliminating the need for an installer.

For 64 bits, the fat plugin format will be enhanced to allow for both 32 and 64 bit binaries - bringing the total binary count up to 6 (!). The current planned format is:

my_fat_plugin
 32
  win.xpl
  mac.xpl
  lin.xpl
 64
  win.xpl
  mac.xpl
  lin.xpl

Legacy fat plugins like this will still work:

my_fat_plugin
 win.xpl
 mac.xpl
 lin.xpl
Why is there a '32' folder? The 32 and 64 bit plugins must be in separate directories to allow Windows plugins to link to DLLs that have naming conflicts, like this.
my_fat_plugin
 32
  win.xpl
  mac.xpl
  lin.xpl
  helper_a.dll
  helper_b.dll
 64
  win.xpl
  mac.xpl
  lin.xpl
  helper_a.dll
  helper_b.dll
in this example, helper B needs to link to helper A, and the 32 and 64 bit versions have the same names. Thus they must be kept separate. If the plugin author renames helper A to helper_a_64.dll then helper_b.dll will not find it.
By having a 32 folder, the plugin is in the same _relative_ location to resources in 32 or 64 bits, avoiding special-case code.

Mac Developers: the plugin system will support either a "fat" binary (mac.xpl) in the usual place or ABI-specific binaries in the 32 and 64 folders; use whichever technique is easiest for your development environment.

Deployment

You can start making your plugins 64-bit ready now using the 2.1.1 SDK and test them on the X-Plane 10.20 betas.

Navigation
TOOLBOX
LANGUAGES
Toolbox