Show: Delphi C++
Display Preferences

64-bit Cross-Platform Application Development for Windows

From RAD Studio XE3
Jump to: navigation, search

Go Up to Cross-Platform Applications Index


Both Delphi and C++Builder support the development of 64-bit Windows applications on either a Win64 development system or a native Win32 development system. Both also support Mac OS X application development.

Contents

FMX-VCL-RTL Support 64-bit Windows Application Development

The three libraries in RAD Studio support Win32 and Win64 as follows:

  • The FireMonkey library (FMX) supports all the Supported Target Platforms.
  • The VCL and the RTL have been modified to work with 64-bit applications in the same way they work with 32-bit applications. This means that if you are using only the VCL and RTL, you can expect to use the same source code for both Win64 and Win32 platforms.

Separate Executable Needed for 32-bit Windows and 64-bit Windows

If you are using visual components, you need to compile two separate applications and configure each of them with a different target platform—for example, one application for Win32 and one application for Win64. You then have an .EXE for Win32 and another .EXE for Win64, with each one configured to have the appropriate Target platform in the Project Manager. Components, packages, and libraries that you need to use at design time must exist as Win32 versions as well as 64-bit versions.

Configuring a 64-bit Windows Cross-Platform Application in the IDE

To target the 64-bit Windows platform, you must add (or activate if already added) the 64-bit Windows platform to the Target Platforms node in the Project Manager:

ActiveWindows64Platform.png

If you are using a remote Win64 target system for running, debugging, and deploying your 64-bit Windows application (and your development system is Win32), you should create a remote profile in the IDE and assign it to your target platform.

If you are using a Win64 development system, using a remote profile is optional and is not required.

64-bit Windows Applications Use the Familiar Windows API

If you have worked with the Windows API for 32-bit Windows application development, you should be familiar with many of the Windows API that are available to you for 64-bit Windows application development.

Running, Debugging, and Deploying Require Win64

In RAD Studio, Win64 application development is by definition cross-platform development, because the IDE is a Win32 application. This means that when you run an application that has the target platform 64-bit Windows, you are essentially deploying the application to the Win64 platform. Thus, at run time your development system needs to either be 64-bit Windows or be connected to a Win64 system.

There are two scenarios for running, debugging, and deploying a 64-bit Windows application, depending on whether your development PC is running a 64-bit Windows or a 32-bit Windows operating system.

Using a 64-bit Windows Development System

If your development PC is a 64-bit machine that is running 64-bit Windows, you can run, debug, and deploy on your development PC, just as you would debug a 32-bit Windows application, without using the Platform Assistant or a remote profile. Althoug using the Platform Assistant and a remote profile is optional for 64-bit Windows development systems, doing so enables you to use the Deployment Manager for deploying your application.

Using a 32-bit Windows Development System

In order to run, debug, or deploy a 64-bit Windows application using the IDE on a Win32 Windows development system, you must:

For more details about using the Platform Assistant and remote profiles, see Steps in Creating Cross-Platform Applications.

You can connect to a 64-bit Windows PC using either a standard Ethernet LAN or Remote Desktop Connection. For more information, see Connecting Your 32-bit PC to a Win64 PC.

Note: If Windows Firewall is enabled on the Win64 target, you might receive a Windows Firewall message when paserver first connects to the Win64 target. Click Allow Access (and leave "Private networks" selected under "Allow paserver.exe to communicate under these networks").

Debugging a 64-bit Windows Application

In general, debugging a 64-bit Windows application in RAD Studio is very similar to debugging a 32-bit Windows application. That is, there are few differences. You will see differences in some of the CPU windows, such as FPU View.

  • If you are using a 64-bit Windows development system, you can run and debug your 64-bit Windows applications on your development system, and you do not need to connect to a separate target system.
  • If you are using a 32-bit Windows development system, RAD Studio needs to deploy the 64-bit Windows application in order for you to debug it. That is, you need to ensure a live connection to a 64-bit Windows system at run time.

For more information, see Debugging Cross-Platform Applications.

Deploying a 64-bit Windows Application

See Deploying Cross-Platform Applications.

Considerations for 64-bit Applications

64-bit Windows Components, Packages, and Libraries Require 32-bit Design-Time Versions

If you are creating 64-bit Windows components, packages, or libraries, you need to have 32-bit Windows design-time versions of these if you want to use these components, packages, and libraries in the IDE during application development. This requirement exists because the IDE is a 32-bit Windows program.

For example, if you are using the New Component wizard, you need to start by creating a 32-bit Windows version of your component. Later you compile your component again, as a Win64 component, by setting the Target Platform to be 64-bit Windows (in the Project Manager). RAD Studio saves output files (such as .bpl and .dcp) in platform-specific directories located inside your project output directory.

Generating and Importing 64-bit Type Libraries

A 64-bit Windows application can use a 32-bit Windows type library (as some 64-bit MS Office applications do).

When the current target platform is 64-bit Windows, the IDE now passes "-E64" to GenTLB.exe. The result is a type library whose SYSKIND is SYS_WIN64 (compared to SYSKIND=SYS_WIN32 for a 32-bit Windows type library).

When you are importing a 64-bit Windows type library that depends on another type library that is registered only in the 64-bit Windows keys of the registry, you should use the 64-bit Windows version of TLIBIMP.EXE, found in:

$(bds)\bin64\tlibimp.exe

For C++Builder, see Migrating C++ Code from #import to TLIBIMP.EXE.

Making Your Components Available at Design Time and Run Time

Following are the two ways the IDE decides whether or not a component is available for Win32/Win64/OSX32. (Here "available" means appearing on the palette, and checked by the IDE. The IDE does not do any compile-time checking other than verifying the existence of component unit.) Both methods described here rely on data embedded in the Win32 run-time (or design+run-time) package that implements the components. The IDE cannot load Win64 and OSX32 packages in the IDE, so the IDE must defer to the Win32 package for information.

  • The RAD Studio build system automatically embeds an RC_DATA resource in the Win32 package binary named PLATFORMTARGETS, which is a bitmask of the pidXXX constants in System.Classes.pas and reflects the package project's targeted platforms. The IDE reads this when the package is loaded and uses it to decide, for example, whether or not to disable the component(s) in the palette when an unsupported platform is active.
Targeting multiple platforms with a component package implies a contract between the component developer and the IDE. The IDE assumes that if a component package project targets multiple platforms and the developer distributes the Win32 run-time package to customers (and all the associated compilable and linkable files), the developer will also distribute all the necessary compilable, linkable, and run-time bits for the other targeted platforms as well.
  • Individual components can use the ComponentPlatformsAttribute class attribute to override the data in PLATFORMTARGETS, using a bitmask of the same constants in the Classes unit. For example:
type
  [ComponentPlatformsAttribute(pidWin32 or pidWin64)] // not supported on OSX
  TMyComponent = class(TComponent)
  private
    ...
  end;
Use of the ComponentPlatformsAttribute attribute implies the same contract as described in the first bullet above.

Windows Programming

  • Windows API calls must be 64-bit versions.
    • Try blocks are supported in 64-bit Windows programs.
    • You cannot mix 32-bit and 64-bit Windows code in the same process.
  • DLLs, components, libraries, and packages require that you compile or install separate 32-bit Windows (design-time) and 64-bit Windows (run-time) versions if you want to use the Form Designer.
  • 64-bit Windows is needed for OS extensions, shell extensions.
  • The size of LRESULT, WPARAM, and LPARAM all expand to 64 bits, so message handlers will have to be checked for inappropriate casts.

Assembly Programming

  • Most of the registers of a 64-bit Windows CPU are twice as wide as those in a 32-bit Windows CPU. Yet the size of the instruction register (IR) is the same for 32-bit Windows and 64-bit Windows processors.
  • You can use Inline Assembler for 64-bit Windows code with some limitations:
    • No mixing of assembly code in a block of Pascal or C++. Functions must be written completely in assembly, in Pascal, or in C++.
    • Limit direct Stack Pointer (RSP) changes.
  • For Delphi, use new pseudo-ops:
    • .SAVENV
    • .PUSHNV
    • .PARAMS
    • .NOFRAME

For an example of inline assembly, see Inline Assembly with BCC64 (C++).

For more information, see:

64-bit Windows Topics

See Also

Personal tools
Previous Versions
In other languages