Delphi 64 bits?

| | August 6, 2015

Delphi 64 bits is on its way as everybody knows (every delphi programmer at least) . Apart from what codegear says about the benefits of a 64 bits Delphi app (and codegear does not say much about), what will I benefit from having a 64 bits Delphi application? It is really a good idea to port my app to 64 bits as soon as codegear releases it?


I am just asking it because I want all opinions I can have. For now, I can say that I really need more memory available to my application because it consumes a lot of resources. I really could use more speed, if it is possible. I do not need shell extensions neither plugins.

My customers are also asking me about a x64 version of my app, but I really do not understand why they are asking for it, because they are actually lawyers who have no idea what is a 64 bits application.


I actually do not participate directly into the app development. I am part of a technology team and I create stuff that other developers in the company I work for use to really develop the final app. So, my job is to do technical stuff, and port a app to x64 is the kind of thing I do, but I need to explain why I am doing that to my superiors.

7 Responses to “Delphi 64 bits?”

  1. I have this problem with some of my clients. It largely happens because the IT departments in their respective companies have a check-list of things that need to be ‘considered’ when the company purchases new software (or approves updates, etc). From time to time these check-lists get updated to better reflect the modern IT landscape but that doesn’t always mean that the new elements make sense in the context of your own application software.

    At some point, people started saying ‘as we have 64bit Windows XP/Vista/7 etc, we need to make sure any new software is 64bit too’. As developers we know that this isn’t necessarily the case but if you try to explain this to non-technical people it usually comes over as you trying to cover-up the fact that your app isn’t actually 64bit. When you’re a small bespoke vendor in cut-throat competition with other vendors, you can’t let your work lose out because of a largely irrelevant/unimportant ‘feature’ on someone’s check-list.

    My approach thus far has been to tell clients that the software has been thoroughly tested and validated on 64bit Windows but has developed so that the same exact version can run on either 32bit or 64bit Windows. It’s perfectly true because my apps are largely Delphi 2007 based, and in the last year or so I’ve started doing all of my testing on 64bit Win7 as a first resort (and then performing a subset of tests again under 32bit XP, at key milestones).

    As an aside, both in the small business environment and (more surprisingly) the home one, I’ve seen far more 64bit Win7 installs than 32bit ones. Most new machines I’ve seen in the last 6 months seem to have come with 64bit Win7, which I find quite interesting.

    I also like The_Fox’s comment to the original question – I may have to update my splash screens accordingly. Especially if I can detect that the program is running on a 64bit version of Windows…

  2. No, keep your application 32 bit.

    “My customers are also asking me about a x64 version of my app, but I really do not understand why they are asking for it”

    What your users want is for your application to work perfectly on a 64 bit version of Windows. You should test this and tell them you have tested it and that it runs correctly on 64 bit Windows.

  3. David Heffernan on November 30, -0001 @ 12:00 AM

    One situation where 64 bit will matter is for data-parallel, multi-threaded numerical applications on many-core machines. For such an app the 32 bit address space can be constraining if the data cannot be split into small enough pieces.

    Other than that the biggest push to 64 bit is for extensions to other programs. For example shell extensions, Excel add-ins, MATLAB extensions etc.

  4. A 64-bit program has the following advantages over the same one compiled for 32-bit (x86):

    • More registers. 64-bit x86 chips have several more registers and this can, in theory (if the compiler takes advantage) result in faster code in some cases.

    • More memory. With a 32-bit program you were generally limited to either a 2GB address space or a 4GB address space in total, if you compiled with /LARGEADDRESSAWARE, which was about 3.5GB in practice due to Windows’ kernel/userspace split. A 64-bit process can address much more. This is only important if your app needs a lot of memory.

    • Ability to build plugins for 64-bit programs, like Explorer. Unless you’re using COM for a plugin, where data is marshalled, you can’t mix 32-bit and 64-bit code in the one process in Windows, such as a 64-bit EXE loading a 32-bit DLL. If you wanted to write an Explorer plugin, for example, you couldn’t have it work with the 64-bit version of Explorer with old versions of Delphi. You will be able to with the 64-bit version.

    • Delphi-specific: the compiler will use SSE/SSE2 instructions for floating point calculations, where the current 32-bit compiler only uses x87 FPU instructions (I think.) This should give a speed increase for floating-point math. You probably won’t even notice unless your app is highly FP-dependent (a game, perhaps, or a data processing application, that kind of thing.)

    The answer to your question “will I benefit from having a 64 bits Delphi application?” is highly dependent on your specific application. In general, there is unlikely to be much benefit beyond, possibly, a small speed increase. Don’t rely on 64-bit to speed up a slow application though: you will still need to make algorithmic changes for large speed boosts. 64-bit isn’t a magic bullet. Other than that, you only need to change if you’ve already encountered one of the limits imposed by 32-bit – I suspect you haven’t, or you wouldn’t be asking the question.

    If you decide to convert, you may find this thread very useful.

    But one other thing: even if you don’t need to change, you might want to, especially if your app is a personal project. You might learn stuff, your code will be higher quality when you fix 32/64-bit issues, and a project like that can be fun. You’re a programmer, after all :)

    Edit: I see you have updated your question with “I can say that I really need more memory available to my application because it consumes a lot of resources. I really could use more speed, if it is possible.”

    • What resources? Memory? 64-bit will give you a greater addressable address space, that’s it. It won’t give you more GDI handles, etc, if those count as resources. However, if you truly do need more memory, then 64-bit will be worth converting to.

    • “More speed”, if you want a big difference, is more likely to be achieved through algorithmic or threading changes than through a 64-bit compiler.

    • “My customers are also asking me about a x64 version of my app, but I really do not understand why they are asking for it, because they are actually lawyers who have no idea what is a 64 bits application.” Chances are they’ve heard that 64-bit is better or faster. In an ideal world, customers would have reality-based requirements, but this isn’t always the case. Pragmatically speaking if the customer wants something like this, it may be worth converting simply because it makes them happy: happy customers are good, and they may pay you for the new version, and it may help your company’s word-of-mouth reputation.

  5. Most programs won’t care.

    I have exactly one program I have written that I would make a 64-bit version of and that would be to increase the cache size and even then it’s only because what I think would be the best tradeoff puts the maximum memory use somewhat over 2gb.

  6. Chris Thornton on November 30, -0001 @ 12:00 AM

    If you write shell extensions, you already know why you need 64. In my case, I have a DLL that gets loaded by Windows Explorer, and it cannot, absolutely will not, load a 32-bit DLL. There ARE apps that will benefit from 64-bit, but most, IMO will not. And for things like mine, 64-bit is more of an annoyance than anything else.

    Good idea? Only if you think it’ll make you more $$$. Otherwise, the time is better spent improving quality or adding features. Unless you’re using pure native VCL controls and libraries, you’ll likely have to wait for 3rd-party support to catch up. I am still fixing and replacing libraries, related to converting to Unicode….

  7. Do you have an actual need to access large (> 4GB) of memory in your application, like video or image processing, or processing of huge amounts of data very quickly? Is your application a shell extension that needs to run on 64-bit versions of Windows? Do you have customers or clients that are complaining because a 64-bit version of your app isn’t available?

    If you had a need for an immediate update of your app to 64-bit, you’d know it already. Since you don’t, you probably have lots of time to do so – remember that 32-bit versions of most applications work fine on 64-bit Windows versions.

Leave a Reply