C++Builder 64-bit Windows Differences
Go Up to C++Builder 64-bit Windows Application Development
See Differences Between bcc64 and Previous-Generation C++ Compilers for an overview of the differences between BCC64 and its immediate predecessor, BCC32. BCC64 is the latest in a long line of compilers entwined in the minutiae-laden history of C/C++ development since DOS and 16-bit Windows.
For specific steps to port your existing 32-bit C++ projects to 64-bit Windows, see Upgrading Existing C++ Projects to 64-bit Windows.
Contents
Differences Between 64-bit Windows and 64-bit Windows (Modern) Applications
In the following sections, you can review the principal differences between 4-bit Windows and 64-bit Windows (Modern) Applications.
Linker/RTL
The new linker/RTL of the latest C++ Builder platform uses init records for the initialization of units on Windows, mirroring the approach used for mobile. As with mobile, where the same init records are employed, some units are referenced with {$HPPEMIT LINKUNIT}
, as seen in Vcl.Styles. Without this method, initialization would fail, which would render dynamic loading of VCL *.vsf
styles inoperable.
RTL
Consider that When using 64-bit Windows (Modern) Applications you cannot change the memory manager since the Delphi code linked in uses the MM provided by C++, which is from the UCRT.
Keywords
Keep in mind that the __import
and __export
keywords are not present. Instead them, use __declspec(dllimport)
and __declspec(dllexport)
.
Data Migration
64-bit Windows (Modern) Applications export RTTI data or global variables marked with the Package attribute or when they are explicitly marked with __declspec(dllexport)
, regardless of whether the output is an application or a DLL.
Conversion Functions
The conversion functions are provided with the `_` names like `_itoa`. This is a common convention for functions that live in standard headers like `stdlib.h`. We previously provided both historically.
Differences Between 32-bit Windows and 64-bit Windows Applications
Moving to 64-bit development is a widely covered topic on the Internet, especially as it relates to C++ and Windows. For more information, see the following topics:
- 64-bit Windows Application Development
- 64-bit Windows Data Types Compared to 32-bit Windows Data Types
Two basic concepts are stressed here.
size_t versus unsigned
size_t
is defined as an unsigned integral type, passed to malloc
and the result of sizeof
, with enough bits to represent the size of the largest possible object in the memory/data model. In Win32 and Win64, this is the same size as a pointer. (These modern Windows memory models are flat. In contrast, in the segmented Large memory model of DOS, pointers were 32-bit, while the largest object was 64KB. So size_t
could be 16-bit.)
In Win32's "ILP32" data model, int
(and long
) and pointers are 32-bit. You could use unsigned int
in place of size_t
, although it is not portable.
Win64 is an "LLP64" data model: long long
and pointers are 64-bit, while int
(and long
) are still 32-bit. Therefore, you must use size_t
.
_WIN32 Is Defined For Win64
_WIN32 is defined (as the integer 1) for both Win32 and Win64 targets. This allows programs to target (modern) Windows in general, among other platforms.
_WIN64 is defined only for Win64 targets; because _WIN32 is also defined, check _WIN64 first, something like this:
#if _WIN64
// 64-bit Windows
#elif _WIN32
// 32-bit Windows
#elif __APPLE__
// OS X
#else
#error Not a supported platform
#endif
OLE_HANDLE Is 32-bit Long Even on 64-bit Windows
On Win64, the size of HANDLE types has changed to 64-bits - except for OLE_HANDLE, which is now a 32-bit Long even in Win64. This means that you need to change any code that assumed OLE_HANDLE and other HANDLE types are interchangeable. See also http://stackoverflow.com/questions/401812/what-is-the-proper-way-to-cast-from-an-ole-handle-to-an-hicon.
Compiler Differences
BCC64 is based on the Clang compiler front-end. See:
- Clang-enhanced C++ Compilers
- Differences Between Clang-enhanced C++ Compilers and Previous-Generation C++ Compilers
- BCC64, the C++ 64-bit Windows Compiler
#include
windows.h
Your 64-bit Windows C++ applications should always contain:
#include <windows.h>
With BCC32, including windows.h is not required, but BCC64 requires windows.h and as any other Clang-enhanced C++ compiler it is more strict about #include
s.
Producing 64-bit Packages Is Now Supported
BCC64 produces 64-bit Windows packages (.bpl
files), beginning in the XE6 release. You can also do static linking to a 64-bit Windows package, and you can consume packages using C++Builder 64-bit Windows.
Note that C++Builder does not produce dylibs for the Mac, or packages for the iOS and Android platforms. For these platforms, static libraries can be used.
Differences between Win32 and Win64 packages
For Win64, the compiler exports code elements marked as PACKAGE if they are defined in the current translation unit. For classes, if one non member is defined, the class is exported. If no definition is seen, the compiler will treat the code element as imported. This behavior is different from Win32.
You must use PACKAGE for both Win32 and Win64, but Win64 exports only if there is a definition present. This requirement applies to variables, functions and classes that are meant to be exposed to consumers of the package.
Example:
class PACKAGE TTest : public System::TObject {
private:
int FProp;
__property int Prop = {read=FProp, write=FProp};
public:
__fastcall TTest(void);
__fastcall virtual ~TTest(void);
};
PACKAGE bool GoodieFlag;
PACKAGE void __fastcall SuperFunc(const System::UnicodeString S);
For general information, see Building Packages.
Requirements for Win64 packages
- For exporting a component class from a package, you must ensure at least one non-inline member for each component (this is done for you by the File > New Component wizard).
- If you previously set the Package output directory to produce a Win32 package, make sure to change the path for your Win64 project on the Tools > Options > Environment Options > C++ Options > Paths and Directories (C++) page, so that your Win32 package is not overwritten. If you override the Package output directory, you can verify that the Final output directory is correctly set on Project > Options > C++ (Shared Options). That is, the Final output directory should be different for Win32 and Win64.
Debugger Features
See Debugging C++Builder 64-Bit Windows Applications.
See Also
- BCC64, the C++ 64-bit Windows Compiler
- Differences Between Clang-enhanced C++ Compilers and Previous-Generation C++ Compilers
- Clang-enhanced C++ Compilers