Migration to Delphi XE5

In early October 2013 I decided to migrate the HeidiSQL sources to the brand new Delphi XE5 IDE/compiler. So I first installed the trial version on a virtual machine to see if I have show stoppers, code which won't ever work with XE5. The installation process was quite lengthy, took ~2hours and at least one additional hour to generate help files. But to my luck there were no show stoppers. So, I took the money from donations I got so far and bought Delphi XE5. Of course I had to install again on my non-virtual computer, and I had a gutt feeling this time the installation took even longer - sigh.

Migration now had three main tasks for me:
1. update project package files
2. fix a few compiler errors
3. rewrite the whole build process on heidisql.com

The build process was previously based on a mixture of batch files in the "extra" directory of the HeidiSQL sources and a PHP script writing binaries into a MariaDB database from where downloads are served. I decided to remove the batch files as these used the quite uncommon syntax of extended DOS shell commands, including for-loops, variables and parameter parsing.

So now I have a pure 200-liner of a PHP script which:
* does a Subversion update
* calls the Delphi command line compiler
* pulls and compiles translation files from Transifex, using tx.exe and msgfmt.exe
* patches the compiled executable with the madExcept handler using madExceptPatch.exe
* creates the installer with InnoSetup, using ISCC.exe
* and finally writes the executable, the installer and a build log to the database which serves downloads.

All went well, I now have a more maintainable build process, and the first heidisql.exe has just been built (r4592). You will probably notice the increased size of the nightly builds, which are roughly 1.2M bigger than previously. Well, nothing to worry about.

Earlier versions of HeidiSQL were compressed with UPX, a nice .exe compressor. But as I began to use the madExcept handler, it could no longer find the right callstack details, so I had to remove that compression.

Now that I moved to XE5 and removed the external GraphicEx library, I am just two code glitches away from a 64bit build of HeidiSQL. Well, I guess noone cares, as the 32bit version works on 64bit Windows, but not vice versa.

Anyone out there preferring a 64bit version of HeidiSQL over the 32bit version?

In fact, I have never need to use a 64bit DB-Manager. I think 32bit is more stable and it is enough.

I'm using a 64-bit Windows version at work if that's what you ask. But I'm basically an end user and I don't have the faintest idea of why software vendors are so reluctant to upgrade. When Windows moved from 16 to 32 bits, apps divided in two groups: abandoned an upgraded. But I guess this is not the same situation.

To sum up: are there any drawbacks, apart from the obvious ones (i.e., compiling everything twice)?

There are no drawbacks on a 64 bit build, apart from some glitches which the compiler complains about and I have to work around. But a 64 bit version does not run on a 32 bit Windows, while the 32 bit one works on both Windows versions. And, a 64bit build won't run significantly faster than the normal 32bit build. So, it looks like just more effort for compiling everything twice. On the other hand, I guess at some point in the future the 32bit applications will die out as Windows marks these as deprecated or whatever. But that's far in the future I guess.

I was just googling around for out-of-memory issues in HeidiSQL, and found quite some of such reports, in various situations. Some of them are due to the memory hungry SynEdit editor, others are due to importing large files. Many users nowadays have more than 2gb of RAM installes, so potentially use them if the application would allow so. So, I'm beginning to think it's reasonable to serve a 64bit build.