Release Notes for C++Builder 64-Bit Windows
The release of C++Builder 64-Bit Windows is also Update 1 for the RAD Studio XE3 release, and XE3 Update 1 includes both the Delphi and the C++ personalities. These Release Notes contain important supplementary information that pertains specifically to the release of C++Builder 64-Bit Windows. We recommend that you read this page in its entirety. For the most current version of these release notes, see http://docwiki.embarcadero.com/RADStudio/XE3/en/Release_Notes_for_C%2B%2BBuilder_64-Bit_Windows.
- For full release notes for XE3, see the Release Notes for XE3.
- For full install notes for XE3, see the Installation Notes for XE3 (Boost Libraries free space requirements are described here.)
- For the newest version of any help topic, please rely on the RAD Studio docwiki.
- We will continue to update docwiki pages after the release and throughout the product update cycle.
- Help Updates will be released at intervals, but the docwiki always contains the latest help.
Do not install extraneous files in \bin directories
Embarcadero does not allow any unsigned third-party DLLs to be placed in the product bin directories:
A license validation error will occur.
FastReport for 64-bit Windows Available Soon
FastReport Embarcadero edition is currently available for:
- Delphi (32-bit Windows and 64-bit Windows)
- C++Builder (32-bit Windows)
The FastReport version for use with C++Builder 64-bit Windows is coming soon and will be available as a free download for C++Builder XE3 and RAD Studio XE3 registered users at http://cc.embarcadero.com/reg/rad_studio.
Specify Debug Path for Delphi Packages
If you want to debug Delphi packages that are used in a C++ 64-bit Windows application, you should first perform the following configuration steps:
- Select Tools > Options > Debugger Options > Embarcadero Debuggers .
- In the Debug symbols search path field, add a full path in this form:
- C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\lib\win64\debug
- Click OK.
Adding the Project Directory to the Include Path
Currently the IDE automatically includes the project directory in the
#include path, even though the default setting for Add the Project Dir to Include path is False (on C++ Compiler Directories and Conditionals). This behavior might change at a later date, after which you will need to set this option to True if you want the project directory automatically added to the
For more information, see #include.
Add Priority for
BCC32 and BCC64 differ in the default priority they assign to
#pragma exit (assigned if the optional priority specification is omitted).
Due to a bug in BCC32,
#pragma exit routines with no specified priority are actually assigned priority 30. So you must explicitly set an exit routine at priority 30 in BCC64 in order to match the BCC32 behavior for exit routines with no priority. For example, if you have an exit routine that you expect to be called after __ExitVCL is run, with BCC64 you must specify its priority at 30. (Note: __ExitVCL runs at priority 31.)
For more information, see #pragma exit and #pragma startup.
WebSnap Applications Might Need WebInit.cpp Added
If you create a C++ WebSnap application with a 64-bit Windows target platform, you might see linker errors such as the following:
[ilink64 Error] Error: Unresolved external '__dso_handle' referenced from E:\EMBARCADERO\RAD STUDIO\10.0\LIB\WIN64\RELEASE\WEBINIT.O [ilink64 Error] Error: Unresolved external '__cxa_atexit' referenced from E:\EMBARCADERO\RAD STUDIO\10.0\LIB\WIN64\RELEASE\WEBINIT.O
The workaround is to add the WebInit.cpp file to your project using the Project Manager. WebInit.cpp is installed in the $(BDS)\source\internet directory.
Refresh Designer if TBindSourceDB is Not Populated after Loading a Dataset
In VCL or FireMonkey applications with multiple forms and/or datamodules, an embedded dataset within a TBindSourceDB might contain stale submembers in the LiveBindings Designer if the dataset is external to the form the Designer is actively viewing. Stale members could also be due to dataset changes. The Refresh Designer context menu command allows you to work around this update issue.
Program Reset Can Cause Debugger Crash
The C++Builder 64-bit Windows debugger might crash if you do a Program Reset (Ctrl+F2) while the debugger is stopped at a data breakpoint.
A SOAP client developed in C++Builder 64-bit Windows can invoke a Server passing integers, strings and structs containing integers and strings. Dynamic arrays of strings are not yet supported.
Indy UDP Errors
C++ Indy projects that use UDP (User Datagram Protocol) might elicit compiler errors such as:
Floating-point Exceptions for External Code Such as OpenGL
Floating-point exceptions might occur when C++ 64-bit Windows code is interacting with external code, such as OpenGL, OLEDB, TWebBrowser, .NET assembly, or ActiveX controls. On the 32-bit Windows platform, you can work around these exceptions with calls to _control87. But _control87 sets the floating-point register in 32-bit Windows (that is, the FPU register), while SSE is the floating-point register in 64-bit Windows.
For any code that triggers the floating-point exceptions, you should instead use System::Math::SetExceptionMask(..), which will invoke either SetFPUExceptionMask (for 32-bit Windows) or SetSSEExceptionMask (for 64-bit Windows). You typically need to mask floating-point exceptions when interacting with external code. Exceptions should be masked and unmasked as you cross the boundaries.
- Debugging of two files with the same name is not supported.
- Support is incomplete for debugging code that throws exceptions.
- For example, exceptions are not supported in the evaluation of function calls.
- Evaluation of local static and file static variables only works within the current scope.
- Evaluation of some function calls might not work, especially with inherited Delphi types such as VCL and RTL members.
For more information, see Debugging C++Builder 64-Bit Windows Applications.