C++Builder 64-bit Windows Differences

From RAD Studio
Jump to: navigation, search

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.

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:

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
  #error Not a supported platform

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:

#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 #includes.

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.


class PACKAGE TTest : public System::TObject {
  int FProp;
  __property int Prop = {read=FProp, write=FProp};
  __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