64-bit Windows Application Development
Both Object Pascal and Appmethod C++ support the development of 64-bit Windows applications on either a Win64 development system or a native Win32 development system.
- 1 FMX-RTL Support 64-bit Windows Application Development
- 2 Separate Executable Needed for 32-bit Windows and 64-bit Windows
- 3 Configuring a 64-bit Windows Application in the IDE
- 4 Running, Debugging, and Deploying Require Win64
- 5 Considerations for 64-bit Applications
- 6 64-bit Windows Topics
- 7 See Also
FMX-RTL Support 64-bit Windows Application Development
The two libraries in Appmethod support Win32 and Win64 as follows:
- The FireMonkey library (FMX) supports all the Supported Target Platforms.
- The RTL has been modified to work with 64-bit applications in the same way it works with 32-bit applications. This means that if you are using only the 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 Application in the IDE
If you are using a 32-bit Windows development PC, you can run, debug and deploy applications built for 64-bit Windows platform using a remote 64-bit Windows system: create a connection profile in the IDE that defines how to connect to the target 64-bit Windows system, and assign this connection profile to the 64-bit Windows target platform in the Project Manager.
If you are using a 64-bit Windows development PC, using a connection 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 Appmethod, 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 connection profile. Although using the Platform Assistant and a connection 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:
- Install and run the Platform Assistant on the 64-bit Windows target system.
- Create a connection profile on the Win32 development system that describes the connection to PAServer on the 64-bit Windows target system.
- Assign this connection profile to the 64-bit Windows target platform in the Project Manager.
For more details about using the Platform Assistant and connection profiles, see Steps in Creating Multi-Device 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 Appmethod 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.
- For C++ 64-bit Windows debugging, a few debugger features are not available. For more information, see debugger notes in Debugging Appmethod C++ 64-Bit Windows Applications.
- 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, Appmethod 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 Multi-Device Applications.
Deploying a 64-bit Windows Application
- If you are using the Platform Assistant and a connection profile, you can use the Deployment Manager to deploy your 64-bit Windows applications.
- If you are using a 64-bit Windows development system and you want to use the Deployment Manager, you must create a connection profile that describes the target system for deployment.
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). Appmethod 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:
C:\Program Files (x86)\Embarcadero\Studio\17.0\bin64\tlibimp.exe
For Appmethod C++, 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 each platform. (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 packages built for platforms other than Win32 in the IDE, so the IDE must defer to the Win32 package for information.
- The Appmethod 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 resource when the package is loaded and uses the resource data 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)] // Only supported on Win32 and Win64 TMyComponent = class(TComponent) private ... end;
- Use of the ComponentPlatformsAttribute 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 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.
- 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 Object Pascal or C++. Functions must be written completely in assembly, in Object Pascal, or in C++.
- Limit direct Stack Pointer (RSP) changes.
- For Object Pascal, use new pseudo-ops:
For more information, see:
64-bit Windows Topics
- Prepare Your Development Environment (only if your development system is Win32):
- Write and Run Your Win64 Application:
- 64-bit Windows "Hello World" Application (Object Pascal and C++)
- 64-bit Windows Data Types Compared to 32-bit Windows Data Types
- Converting 32-bit Object Pascal Applications to 64-bit Windows
- Appmethod C++ 64-bit Windows Application Development
- Differences between Windows and Mac OS X
- Developing Multi-Device Applications
- Compiling and Building Multi-Device Applications
- Debugging Multi-Device Applications
- DCC64.EXE, the Object Pascal 64-bit Command Line Compiler
- 64-bit Programming in Assembly
- Differences between Win32 and Win64 - FAQ
- Matt Pietriek's Getting Started with 64-Bit
- Raymon Chen's blog post on x64 calling convention
- MSDN x64 Software Conventions
- Low level info on prolog / eplilog
- MSDN Exception Handling (x64)
- Info about x64 not supporting FPU
- Debugging optimized x64 code
- Detailed information about the MSVC x64 command prompts
- 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
- C-Compiler Packing Issues
- Windows Data Alignment on IPF, x86, and x64 (from 2006, fairly technical and long)