64-bit Cross-Platform Application Development for Windows
Go Up to Cross-Platform Applications Index
Delphi supports the development of 64-bit Windows applications on either a native Win32 development system or a Win64 development system. (C++Builder supports Win32 and Mac OS X applications, but does not support Win64 applications.)
VCL-FMX-RTL Support 64-bit Windows Application Development
All three libraries support both Win32 and Win64:
- The FMX (FireMonkey) library 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.
If you are using visual components, you will need to compile two separate applications and configure each of them with a different target platform—one for Win32 and one for Win64. You will 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 Cross-Platform Application in the IDE
If you are using a remote Win64 target system for running, debugging, and deploying your 64-bit 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 application development, you should be familiar with many of the Windows API that are available to you for 64-bit application development.
Running, Debugging, and Deploying Require Win64
Win64 application development in RAD Studio 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 or a 32-bit operating system.
Using a 64-bit Development System
If your development PC is a 64-bit machine 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 and a remote profile. However, using the Platform Assistant and a remote profile is optional for Win64 development systems, and enables you to use the Deployment Manager for deploying your application.
Using a 32-bit Development System
In order to run, debug, or deploy a 64-bit Windows application using the IDE on a Win32 development system, you must:
- Install and run the Platform Assistant on the 64-bit target system.
- Create a remote profile on the Win32 development system that describes the 64-bit target system.
- Ensure a live connection to the 64-bit Windows target platform. (Use Test Connection on the Tools > Options > Remote Profiles page.)
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 PC using either a standard Ethernet LAN or Remote Desktop Connection. For more information, see Connecting Your 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 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 32-development system, RAD Studio must deploy a 64-bit application in order to debug it. That is, you need to ensure a live connection to a 64-bit system at run time. If you are using a 64-bit development system, you can run and debug on your development system, and you do not need to connect to a separate target system.
For more information, see Debugging Cross-Platform Applications.
Deploying a 64-Bit Application
If you are using the Platform Assistant and a remote profile, you can use the Deployment Manager to deploy your 64-bit applications. If you are using a 64-bit development system and you want to use the Deployment Manager, you must create a remote profile that describes the target system for deployment. See Deploying Cross-Platform Applications.
Considerations for 64-bit Applications
64-bit Components, Packages, and Libraries Require 32-bit Design-Time Versions
If you are creating 64-bit components, packages, or libraries, you need to have 32-bit 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 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 application can use a 32-bit 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 type library).
When you are importing a 64-bit type library that depends on another type library that is registered only in the 64-bit keys of the registry, you should use the 64-bit version of TLIBIMP.EXE, found in:
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 Classes. For example:
type [ComponentPlatformsAttribute(pidWin32 or pidWin64)] // not supported on OSX TMyComponent = class(TComponent) private ... end;
- Use of this attribute implies the same contract as described in the first bullet above.
- Windows API calls must be 64-bit versions.
- Try blocks are supported in 64-bit programs.
- You cannot mix 32-bit and 64-bit code in the same process.
- DLLs, components, libraries, and packages require that you compile or install separate 32-bit (design-time) and 64-bit (run-time) versions if you want to use the Form Designer.
- 64-bit 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.
- Most of the registers of a 64-bit CPU are twice as wide as those in a 32-bit CPU. Yet the size of the instruction register (IR) is the same for 32-bit and for 64-bit processors.
- You can use Inline Assembler for 64-bit code with some limitations:
- No mixing of assembly and Pascal code in a block. Functions must be written completely in assembly or Pascal.
- Limit direct Stack Pointer (RSP) changes.
- Use new pseudo-ops:
For more information, see:
64-bit Applications Topics
- Connecting Your PC to a Win64 PC
- 64-bit Windows "Hello World" Application
- 64-bit Data Types Compared to 32-bit Data Types
- Converting 32-bit Delphi Applications to 64-bit Windows
- Differences between Windows and Other Platforms
- Developing Cross-Platform Applications
- Compiling and Building Cross-Platform Applications
- Debugging Cross-Platform Applications
- DCC64.EXE, the Delphi 64-bit Command Line Compiler
- 64-bit Programming in Assembly
- Differences between Win32 and Win64 - FAQ
- Matt Pietriek's Getting Started with 64-Bit
- Detailed info on PE file formats from Matt Pietriek
- Tiny C Runtime Library:
- Just Enough Assembly Language to Get By (2 parts):
- Microsoft PE Section names