Why is creating a 64bit Delphi so hard?

views:

725

answers:

+18 Q:

Why is creating a 64bit Delphi so hard?

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?

+1 A:

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.

Matthew Flaschen 2010-06-26 03:45:45

Building something from scratch and converting something into something else - is complete different thing. The main problem with Delphi is that internals of the compiler is not prepared for such change, as other already mentioned.

Alexander 2010-06-27 09:24:26

Free Pascal is not 100% compatible with your existing Delphi code. Nor is the LCL 100% compatible with your VCL forms.

Warren P 2010-06-30 20:07:25

I find it strange that FreePascal must be 100% compatible to be used instead of Delphi. But on the other hand people are more likely to port their Delphi code to C/C++. What needs more work?

ChristianWimmer 2010-07-04 17:14:10

+11 A:

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.

someone 2010-06-26 04:01:29

I strongly disagree about the MacOS being more important. The problem is that they are focusing on new customers rather than current customers. By not making 64bit job #1 they are telling customers "you can't trust us to keep up". This was a very bad move on their part.

Loren Pechtel 2010-06-26 04:35:41

Exactly: they are focusing in new customers (is the first step into a whole new market in fact). Why? Well, new customers always give more money than existing ones heh. And more money is what Embarcadero wanted when buying CodeGear to the old Borland. So, seems that in their strategy going MacOSx is more profitable in the short term. Of course this is my pure speculation, but I think it fits the reality very well. If you ask me, I think they should put public a 64-bit compiler of Delphi available for the current customers, without an IDE in the meanwhile, even without the VCL. Its a hot topic.

someone 2010-06-26 07:34:24

You know how many customers you have for sure - and you should try to keep them -, you do not know how many new ones you will gain. Remember they are not rolling out a full native IDE and library for MacOSX: they built a cross-compiler (which requires a Windows license to run the IDE) and a Qt-based library that will build apps with a MacOSX look and feel, but not fully native applications. Let's see how many new customers that approach will gain, especially after the Kylix failure still spotting reputation. And how many they will lose delaying 64 bit over and over.

ldsandon 2010-06-26 14:58:58

Yes, but with gaining new market I doesn't mean MacOSx native developers, they have their tools in their platform and won't migrate easily. I more mean to open a new market with RAD capabilities in a platform that is growing, that should attract a lot of native developers working in -for example- Visual-C++. Of course the Qt approach may be is not the best, but is a good start at least, and that allows you to have the almost the same code for both platforms. The key for Embarcadero is to grow as a player in the native development market, that said Wayne Williams in an interview at least.

someone 2010-06-26 21:54:36

No, there was no difficulty with porting the existing compiler to 64-bit, there was a CHOICE to rewrite the compiler in such a way as to support multiple back-end compilers - specifically Mac and Linux as well as 64-bit x86.

Deltics 2010-06-26 23:25:21

@someone: Windows native developers have their tools too (VC++), that means that Delphi shouldn't be a Windows native tool? Why it should attract VC++ developers willing to code for MacOS? If Embarcadero wants to grow in the native development market, it has to deliver state-of-the-art native solutions, not cobbled up ones. Hampering the actual Windows product while trying to target new markets is stupid: why people should buy a tool that can't keep pace even on its original platform? This way the only customers can be actual Delphi customer trying to target MacOS, IMHO very few new ones

ldsandon 2010-06-27 12:10:35

+7 A:

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.

Chris Thornton 2010-06-26 04:08:36

Typical conversation at work: `Coworker:` "Why do you want me to build a 32bits version of my c++ dll?! The server OS and all the software on it is 64bit." `Me:` "uh.. well.. you know.. I use Delphi.. it doesn't support 64bit, so if our software needs to interact, your stuff needs to be 32bits too". `Coworker:` "dude, wtf?"

Wouter van Nifterick 2010-06-26 04:27:57

Shell extensions is not the only reason that 64-bit is needed, there are apps that need to address > 2GB of ram, such as ours. We had no choice but to rewrite parts of our application in fpc.

Alan Clark 2010-06-26 05:20:20

The need for 64 bit Delphi is a very technical one indeed for the company where I work. We routinely load 90GB+ models in memory and we currently have to turn down clients with larger data models because we cannot support it in a 32bit Delphi app. We need the extra addressing space that 64bit offers.

Marjan Venema 2010-06-26 08:18:39

Alan/Marjan: you can already address 3 GB in 32bit if you set the large address aware flag (it's not as much as in x64 of course but at least it's a 50% increase).

Remko 2010-06-26 08:41:31

"due to an architecture decision from M$ (not allowing 32-bit DLLs in Windows Explorer)" - it's not MS decision - x64 architecture does not allow this.

el.pescado 2010-06-26 10:16:51

I'm astonished. 8 up votes and no down votes at the time of writing when you completely ignored the question and just gave your personal opinions on 64 bit software in general?

mghie 2010-06-26 13:41:14

Amazing how the talk about 64bit, seems to be about RAM only. I know it's one of the big factors, but let us not forget all the other advantages of the amd64 technology. Yes pointers take double the amount of memory (as from 16 to 32bit), and you likely do not need more than 3Gb for your software. But since the amount of registers in the processor is doubled (giving 3 times as many to work with), and the addition of several instruction wise improvements which this comment is too short to hold, I think it would be fair to assume that there are several good reasons for a user to work with 64bit.

TommyA 2010-06-26 14:19:09

@Chris Thornton: There's no downside to 64bit, it runs 32bit apps entirely natively. There's no need to buy 32bit, since all modern desktop/laptop CPUs are 64bit and all 32bit apps work fine in 32bit emulation. There's no reason NOT to get 64bit. Plus, then I'd only be able to use about half my RAM. Plus, the way you talk about M$, I think that you have NFI what you're talking about.@Remko: That flag doesn't always work- it can introduce kernel-mode instability and failure. The existence of the 3GB flag is not a guarantee that it actually works.

DeadMG 2010-06-26 15:03:57

In a 64-bit Delphi the standard integer type would be 64-bit, right? That is one good thing. I have encountered situations in which I need to use 64-bit integers simply because 4294967296 is a too small upper bound. 18446744073709551615 is much better.

Andreas Rejbrand 2010-06-26 15:06:15

@DeadMG - are you running the 64-bit version of IE, or are you running 32-bit IE? If you're running 32, why?

Chris Thornton 2010-06-26 17:04:15

@DeadMG: you first write " 64bit, it runs 32bit apps entirely natively" then "all 32bit apps work fine in 32bit emulation". The truth AFAIK is WOW64 translates 32 bit calls into 64 bit ones, thereby 32 bits are not run "entirely natively". WOW64 is efficient, but some would like to start to code really "natively". @Rejbrand: Windows uses the LLP64 model, where C long type will be still 32 bit long, it looks Delphi will follow with something alike and Cardinal/Integer will be 32 bit still. Use Int64 if you need a larger integer.

ldsandon 2010-06-26 17:19:58

@Andreas Rejbrand - no, most likely, integer would be 32-bit. But NativeInt would become 64-bit, since SizeOf(NativeInt) = SizeOf(Pointer).

PhiS 2010-06-26 17:25:49

@Chris Thoron: I run Chrome. @Idsandon: They're close enough. There's no safety or real performance difference or coding difference required. You get a 32bit app and under x64, it works identically. There's "native", and there's, "I want to code in machine language".

DeadMG 2010-06-26 18:02:50

@Remko on 64-bit windows, large address aware applications get the full 4g, not just 3g.

glob 2010-06-27 04:08:30

@DeadMG: large address aware or 3GB switch will not make the kernel instable, it will however divide the kernel space in another and limits certain memory pools eg (non)paged pool in favour of user mode space. Regarding the size of integer or cardinal: (T)Handles are an issue in the current state since in C they are pointer (which will become 64 bits) and in Delphi a cardinal, which most likely will remain 32 bits. So a change is required here.

Remko 2010-06-27 09:08:00

+4 A:

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).

Remko 2010-06-26 07:58:48

+5 A:

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.

PhiS 2010-06-26 09:55:21

Yep, that's the one. Though it promised a 64-bit preview compiler for mid-2009 - that is the one that is now promised for mid-2011...

Oliver Giesen 2010-06-26 11:07:51

Its late 2012 now. Our customers are waiting for a 64-bit version for some years now. And we seriously considering porting all software to C++.

Gamecat 2010-06-26 19:09:30

@GameCat: and I think there lies the issue, the tradeoff is: is embarcadero gaining more customer by introducing new platforms or loosing more because of not (fully) supporting the existing one!

Remko 2010-06-27 10:57:41

this is the price of using Delphi. anybody who could port everything to C++, should just do so. But that's insane. Any decent programmer with 20 "person-years" of source code in ObjectPascal going into even ONE of their major projects, is not going to leave behind Delphi/Pascal, without setting themselves back at least several years of work. Free Pascal is not a useful option for most people, either.

Warren P 2010-06-30 20:06:32

+2 A:

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".

Rob McDonell 2010-06-26 12:02:50

+5 A:

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.

ldsandon 2010-06-26 14:53:11

+5 A:

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.

Gamecat 2010-06-26 19:18:40

Unfortunately I can only give you one up-vote for this. Showing customers that you can't depend on them is absolutely horrible for business. I would be quite reluctant to do a long-term project in Delphi at this point even though I think it's an excellent language.

Loren Pechtel 2010-06-26 19:25:35

ansaurus

tags:

views:

answers:

Why is creating a 64bit Delphi so hard?

related questions