About a month ago Ben Grasset wrote an e-mail to the FPC-development list about the difficulties users may have to get the correct version of Free Pascal for their system from the Free Pascal website. And he is right, there is a lot to be improved in this regard. But in our defence, it is not that simple to build installers and releases for all the platforms FPC supports. Most applications out there only exist for one, two, maybe three platforms. That’s easy, but offering an application on as many platforms as the Free Pascal compiler is much harder.
But Ben is not right about anything, he states:
For example, to this day there is *still* no natively-64-bit Windows download for FPC, for absolutely no reason. You instead either get silently linked to the 32-to-64-bit cross compiler on Sourceforge, or linked to pages that *explicitly* provide straight-up misinformation in saying “There is no native compiler available for x86_64 Win64. You have to use a cross compiler”.
It is true that there is no native 64-bit compiler for Windows available on the website. But there is a reason for that. While it is technically possible to compile a native x86_64 Win64 compiler, this self-build native compiler does not support all the functionality the fpc compiler normally provides.
So, what is missing? When an application uses floating-point calculations, sometimes the compiler has to do some floating-point calculations at compile time. For example to calculate the value of constants. These calculations should be done exactly the same way as they would be done on the target the compiler is compiling for. When you compile for i8086 or i386 this means that the calculations has to be done with 80-bit precision. The culprit is that Microsoft decided not to guarantee the working of 80-bit floating point calculations on Win64. This basically means that a native 64-bit Free Pascal compiler can not cross compile to i8086 or i386. Or, maybe it can, but the behavior of the application might differ from the same application built by a Free Pascal compiler running on a different system! This seriously breaks the ‘write once, compile everywhere’ paradigm of the Free Pascal team. Imagine that a developer reports that his 32-bit application starts to behave differently after a recompile. We would always have to ask if one of the two builds was done on a 64-bit Windows system, while the other one was not? No developer would understand that. It’s a support nightmare.
Question is: is this important enough to withhold a native Win64-release? Before I continue, let’s note that this does not mean that it is impossible to build native 64-bit applications for Windows with Free Pascal. The compiler itself is a 32-bit application but is fully functional. Theoretically you could argue that you could hit a memory-limit during compilation. But due to the low memory usage (compared to other compilers) of the Free Pascal compiler, it is practically impossible to hit that limit.
…this does not mean that it is impossible to build native 64-bit applications for Windows with Free Pascal…
So, in short: the 32-bit windows compiler can do anything the 64-bit compiler can do, but not the other way around. Then why would anyone want to use the 64-bit compiler?
Still it is clear that a lot of users do insist on a 64-bit compiler on Windows. Some suppliers even distribute one, like Lazarus and FPCUpDeluxe. It seems that they don’t care, or simply not know why there is no official 64-bit Windows version of the compiler. It does add to the confusion, though.
Back to the start: how can we make it easier for users to get Free Pascal running on their system? At this moment, a developer has to install two Free Pascal packages on his Windows machine to be able to compile 64-bit applications. The upcoming release 3.2.2 will have one installer that will install both compilers at the same time. A developer might not even notice that he is cross-compiling to Win64. Hopefully this resolves the issue for most developers.
And those who really can not live with that: help the Free Pascal team to develop software-based floating-point calculations support. That will solve the issue once and for all. (After all, it is also not possible to cross-compile from, say, an arm-system to i8086 or i386 for the very same reason)