64-bit VCL in Delphi XE2

Note: This is all pre-release information, which I’ve been given permission to share. It’s all subject to change without notice until Delphi XE2 actually ships, and while I’ve been given permission to share this information with you, this is not an official statement from Embarcadero and should not be considered binding in any way.

There’s so much exciting stuff in Delphi XE2, it’s hard to keep track of it all. By now everyone has heard that it’s got a cross-compiler for Mac OS X, and that with the FireMonkey framework, you can write applications that can be compiled for Windows, OS X, and even iOS. In all the excitement over FireMonkey and Mac/iPhone support, I think one really big new item hasn’t gotten as much attention as it should: the 64-bit Windows Compiler.

The 64-bit compiler has been a long-awaited Delphi feature, and it’s finally here. It’s implemented as a separate compiler from the 32-bit compiler. The command line compiler is a distinct executable from the 32-bit command line compiler (as opposed to just being a compiler switch to turn on 64-bit).

64-bit Windows platform in the Delphi XE2 project manager

In Delphi XE2, each project has one or more “Target Platforms.” These platforms could be 32-bit Windows, 64-bit Windows, OS X, or iOS, depending on the framework being used. 64-bit Windows is available both with the new FireMonkey framework and with the venerable VCL. That means that in order to turn a 32-bit Windows application from Delphi XE (or earlier) into a 64-bit application, all you have to do is add the 64-bit Windows platform to the project. It’s really that simple.

There are, of course, a couple of things that may cause some trouble when migrating a 32-bit application to 64-bit:

  • Windows API calls must be 64-bit versions (the VCL and RTL do this for you, but if you’re writing direct API code yourself, you’ll want to make sure you’re calling 64-bit functions).
  • You can use inline assembler, but you can’t mix assembler and Pascal code in the same block.
  • In the 64-bit environment, all pointers are 8 bytes, whereas in Win32, pointers are 4 bytes. This means any code that assumes that a pointer is 4 bytes will need to be rethought (a little more on this below).
  • Some other data types (such as Extended, procedure of object, and typed file blocks) are different sizes. Just stop assuming anything other than sizeof(SomeType) as the size of a particular type, and you’ll be in good shape.
Now, a few things that HAVEN’T changed, that you might be wondering about:
  • All of the integer types except NativeInt are the same size in 64-bit and 32-bit. Integer is still 4 bytes, In64 is still 8 bytes, etc…. NativeInt is the only integer type that changes: A 32-bit NativeInt is 4 bytes, and a 64-bit NativeInt is 8 bytes.
  • Single, Double, Real48, Comp, and Currency floating point types are all the same as in 32-bit. There’s a new Extended80 type that is the same size in both environments (10 bytes, the same size as Extended in the 32-bit environment).
  • The MaxInt and MaxLongInt constants remain the same, at 0x7FFFFFFF.

Another important thing to understand is that the Delphi IDE itself is still a 32-bit Windows application. This may have some impact on the way you write 64-bit code:

  • Design time packages need to be 32-bit. This means that any components, packages, or libraries that will need to be loaded into the IDE must have 32-bit versions.

Now, let’s talk about the debugger: In a nutshell, it works. If you’re running on a 64-bit machine, the [32-bit] IDE will happily debug your 64-bit application. Breakpoints work, watches and evaluations work, even the CPU window works:

Delphi XE2 debugger showing a 64-bit CPU window


If you’re not using a 64-bit machine, but are writing a 64-bit application using a 32-bit machine (why are you doing that?), the debugger will still work remotely. Using the included “Platform Assistant” running on a 64-bit machine, you can run the IDE on a 32-bit machine and remotely run and debug the 64-bit application (this, incidentally, is the same mechanism by which OS X debugging works).

A final thought: The Delphi community has been clamoring for a 64-bit compiler for years, and Embarcadero has really delivered. 64-bit Delphi is available with both VCL and FireMonkey. Changes to existing code are minimal. The debugger is top-notch and the IDE integration is amazing. Personally, I think Embarcadero has gotten 64-bit Delphi right in a very big way.

Want to see more RAD Studio XE2? Check out the RAD Studio World Tour in a city near you.

Delphi XE2 looks awesome. Make it (and whatever version you’re using now) even more awesome with Castalia For Delphi, my collection of IDE enhancements that will change the way read and write code forever.

14 Responses to 64-bit VCL in Delphi XE2

  1. nospam August 30, 2011 at 4:12 am #

    “Integer is still 4 bytes”

    That’s worrying.

    Correct me if I’m wrong, but haven’t all versions of Turbo Pascal up to the last Delphi explicitly warned that INTEGER is the native OS size?

    Now we suddenly have NativeInt. When was that introduced, or is it new in XE2?

    • Andreas Hausladen August 30, 2011 at 10:44 am #

      We already had this discussion. C# has a 3 bit int, (Visual) C++ has a 32bit int, Java has a 32bit int, Delphi 64 has a 32bit Integer. Where is the problem, except that everybody who used Integer in records that are stored to disk or used for communication, will have no problem.
      And the change from 16bit to 32bit was a long time ago. I looks like many seems to have forgotten what happened when Integer became 32 bit and all 16 bit code, that assumed SizeOf(Integer) = 4 was broken.

    • LDS August 30, 2011 at 11:09 am #

      The old rule was Integer/Cardinal should match the platform size, bue everything changed when MS chose the LLP model for 64 bit instead of the LP model other platform chose. LLP means (in C) long -> 32, long long -> 64, pointer -> 64, while LP uses long -> long long -> 64, pointer -> 64. Thereby in Windows most parameters/structures using LONG/ULONG expect a 32 bit value.

      But MacOSX use the LP model, what is Integer/Cardinal on it? Will they be mapped to LONG/ULONG or to INT/UINT which are 32 bit too? Or is the MacOSX compiler 32 bit only?

      • Michael Thuma August 30, 2011 at 11:47 am #

        OS/X 64bit has a 64bit Long. Windows has a 32bit Long. SPARC has a 64bit int.

        • LDS August 31, 2011 at 5:16 am #

          Exactly. Both Linux and MacOSX use 64 bit longs. What will be the Integer/Cardinal size on that platforms?

    • Michael Thuma August 30, 2011 at 11:38 am #

      It’s the native OS Size. This is the 64-bit model used by Intel.

  2. A. Bouchez August 30, 2011 at 7:22 am #

    What’s strange in the CPU view is that the RTL symbols are missing in the disassembled view: I suspect there is a call @UStrAsg mad, but it is not displayed as such.
    This is reducing a lot the usability of the asm view, IMHO.

  3. Alex August 30, 2011 at 7:34 am #

    Thks for info. Useful.

  4. Ron Grove August 30, 2011 at 10:37 am #

    @nospam – I know NativeInt has been there at least since D2007, though I’ve read it only became reliable in D2009. I’ll have to take others word on that since I haven’t bothered with it up to now myself. I’m on a 64 bit Windows 7 computer and in D2007 I created NativeInt and Integer variables and did SizeOf on them. I get 8 and 4 respectively.

    • LDS August 30, 2011 at 11:03 am #

      Exactly: on D2007 NativeInt should return 4, not 8, because D2007 only creates 32 bit executable regardless on what platform you run them. NativeInt must be the size of Integer for the platform an executable is compiled for, not the platform it is run on.

  5. Alex August 31, 2011 at 6:09 am #

    Pls make post: how Win API calls, that require 32bit arg – address, will behave? I can’t cast (…, Longint(@Some),…) or can i? I worrying.

  6. Nick September 2, 2011 at 3:38 pm #

    I have been waiting for this for years … mostly because I need to write applications that address large memory space.

    I just wrote a simple console application that would address about 3GB, compiled to target platform = 64bit Windows, tested the exe on my 64bit Windows7 machine, and got the message “not a valid Win32 application”.

    Works find when I reduce the memory to 2GB.

    What gives????


  1. Delphi XE2 Starter - Seite 3 - Delphi-PRAXiS - August 31, 2011

    […] […]

  2. Delphi XE2: 64bit, 3d GUI, MacOs, iOS en meer! | 4DotNet Developers Blog - September 2, 2011

    […] 64bit compiler […]

For programmers, by a programmer

Hi. My name is Jacob, and I'm the creator of Castalia.

I starting programming in 1986, learning Lightspeed Pascal on a Mac Classic. Today, I'm a professional programmer, teacher, and entrepreneur.

I have a Master's Degree in Computer Science, and I still love Pascal and Delphi.

I believe that writing code is the heart and soul of software development, and I love helping programmers write code more effectively.