Why is creating a 64bit Delphi so hard?

21
votes

The Internet is full of developers requesting a 64bit Delphi, and users of Delphi software requesting 64 versions.

  • delphi 32bit : 1.470.000 pages
  • delphi 64bit : 2.540.000 pages :-)

That's why I've been wondering why Embarcadero still doesn't offer such a version.

If it was easy to do, I'm sure it would've been done a long time ago already. So what exactly are the technical difficulties that Embarcedero need to overcome?

  • Is it the compiler, the RTL/VCL, or the IDE/Debugger?
  • Why is the switch from 32bit to 64bit more complicated than it was for Borland to switch from 16bit to 32bit?
  • Did the FPC team face similar problems when they added 64bit support?
  • Am I overseeing something important when I think that creating a 64bit Delphi should be easier than Kylix or Delphi.Net?
8
delphicompiler-construction64-bit
To the people that try to close this question: I'm not trying to start a political discussion or something. I'm interested in the technical problems that Embarcadero is facing. – Wouter van Nifterick
it probably would help if you made this a CW. There most likely is not one correct answer to this question. (I did not vote to close btw). – Lieven Keersmaekers
Even though I agree that a 64 bit delphi would be most welcome, I think the logical reason for more pages from a search for 64bit delphi over 32bit delphi, is the explicit addition of the 32bit word. Why would people write pages about 32bit delphi and not just delphi in 2010. A more fair comparison would be delphi 64bit compared against all pages refering to delphi, that is not about 64bit. – Tommy Andersen
@TommyA: you're completely right of course.. The number of pages was not really meant to be serious though (see TSmiley instance). Everybody knows that Google pagecounts mean shit, right? Create a programming language called "extreme" or "sloppy" to get on top of the Tiobe index :-) – Wouter van Nifterick
This strikes me as something that should be in an email sent to CodeGear... – Shog9

8 Answers

13
votes

For things I had read in forums, I think the main delay was that the compiler for 32-bits could not be adapted to 64-bits easily at all, so they had to write a new compiler with a structure that allows porting it to new platforms easily. That delay is pretty easy to understand in that field.

And the first thing the new compiler had to do is to support the current 32-bit Windows before targeting it for 64-bit, so that extra-delay is also easy to understand.

Now, in the road to the 64-bit support, Embarcadero decided to target 32-bit MacOSx, and that decision is something that some people don't understand at all. Personally I think it's a good marketing decision for the Embarcadero business point of view (wait, I'm not saying 64-bit support is less important, read carefully, I'm not talking about importance but about commerciality). That is a very controversial extra delay in the road to 64-bits (besides Embarcadero says that they have teams working in parallel, in the facts there is a delay, at least for versioning issues -marketing again-).

Also is good to have in mind FPC is not a commercial product, so they can add/remove features more easily than Delphi.

6
votes

If it weren't for the limitation on shell extensions (I have one that loads into Windows Explorer), I'd probably never care about 64. But due to this limitation, I need it, and I need it now. So I'll probably have to develop that part in Free Pascal. It's a pity, as aside from this, there are few apps that would actually benefit from 64. IMO, most users are either drinking the coolaid, or are angry about having been duped into buying something that sounded great but turned into a headache. I know a guy who is happy to run Win7/64 so he has enough RAM to run a full copy of XP in a VM, which he wouldn't need if he'd gotten Win7/32 like I told him too. :-<
I think everyone has been duped by the HW manufacturers, particularly the RAM dealers who would otherwise have a very soft market.
Anyway, back to the question at hand... I'm caught between a rock and a hard place. My customers are placing demands on me, due to an architecture decision from M$ (not allowing 32-bit DLLs in Windows Explorer) and perception issues (64-bit must be twice as good as 32, or maybe 32 has to run on the "penalty core" or something). So I'm being driven by a largely "artificial" motivation. And therefore, I must project that onto Embarcadero. But in the end, the need for 64-bit support in Delphi is IMO, mostly based on BS. But they're going to have to respond to it, as will I.

5
votes

I guess the closest I've seen to an "answer" to your question from Embarcadero's point of view is summarised in this article on the future of the Delphi compiler by Nick Hodges.

5
votes

The real issues are not technical. Borland/CodeGear first, then Embarcadero, show they do not like to mantain more than one Windows version of Delphi. They delayed the Unicode switch until they could drop Ansi OS support wholly. Actually they would need to support both a Win32 compiler/library and a 64 bit compiler/library because there are a mix of 32 and 64 bit Windows OS used. I believe they are trying to delay it as much as possible to avoid to mantain the 32 bit ones as much as they could. Delphi compiler became pretty old and difficul to mantain, but they decide to rewrite it aiming at non-Windows OSes, and I am sure the driver was to port some Embarcadero database tools to non-Windows 32 bit platforms, ignoring Delphi customers' actual needs, and delaying again the 64 bit compiler and library in a cross-platform attempt made again trying to cut corners to deliver it quickly, and thereby doomed to fail once more. Stubbornly, they do not want to switch to a two year release cycle because they want fresh cash each year, notwithstanding it becomes increasingly difficult to release real well done improvements in a so short cycle - and it took almost four years to fix issues introduced with Delphi 2005 changes. In turn they have to put developers to work on bringing in "minor" improvements to justify upgrades, instead of working on 64 bit stuff fully.

5
votes

I have heard that they wanted a complete rewrite of the compiler without losing the backward compatibility. Considering that there is no full syntax description of the language (I have asked, but they haven't so I made my own available to the general public). I can Imagine that the documentation is not as complete as they wanted it. So they are probably trying to reverse engineer their own code.

I'm a strong supporter of Delphi, and I think 2009 and 2010 are great releases (comparable with the rock solid #7). But the lack of 64 bit support is going to kill them in the end.

Back to the question, the biggest problem should be the compiler. The switch from 16 to 32 bit was easier because there was less legacy (delphi 2 was 32 bit and the Object Pascal language was a lot simpeler than it is now.) I'm not sure about Free pascal. Maybe their code was easy to port. Maybe they lost some backward compatibility. To be sure, you can ask them.

4
votes

I know you are asking for the technical issues but I guess the marketing department might be the biggest issue... I am sure they get far more excited from the prospect of new markets that bring new customers an thus manage to shift priorities. A problem (in my opinion) is the bad track record: we have seen kylix and delphi.net in the past that were both ehm kylixed. I can imagine that new customers will wait and see if it's around to stay and that in turn might decide embarcadero to leave it prematurely.

That said: there are certainly some issues and design considerations for x64 and I just hope that the Embarcadero team will share it's thoughts about them and discuss with the community (to prevent rants as we've had about the unicode change).

2
votes

There already is a 64-bit Delphi (Object Pascal). It's called Free Pascal. So while I have no doubt it's hard, it's not "so hard" that it's not feasible. Of course, I can't speculate about Embarcedero.

2
votes

Allen Bauer from Embarcadero also said recently that they had to implement exception support completely differently for 64-bit "due to differences in the exception ABI on Win64".