Question

There is a code base in delphi 2006 with no development for last many years. If the development needs to be activated what are the options.

  • Continue developing in 2006. (Not sure of IDE support etc.)
  • Migrate to Delphi XE2. (Not sure of what it takes)
  • Recode it in Java.

It seems the second option is more viable but what it would involve to do that? I read some things on Unicode support and also not sure of graphics library support.

Just to put thing in perspective, I am a Java programmer all along with experience on C/C++. However I am trying to understand it more from the perspective of what is the least resistance path to go to market strategy.

Thanks in advance.

Was it helpful?

Solution

I cannot say anything about recoding it in Java. Depending on whatever the code base does, it might be a good option, given that you say you are experienced with Java (and, I assume, not with Delphi).

Regarding Upgrading to Delphi XE2:

Check whether any 3rd party components have been used.

If not, you will probably be able to upgrade to Delphi XE2 with very few changes.

If yes, check whether the source code of these components is already available.

If not, you will have to buy new licenses of these components (and this time take the license that includes the source code!) if you want to upgrade to Delphi XE2. If you are really unlucky, the company who developed these components has gone belly up. Then you are either stuck with Delphi 2006 or you will have to find a replacement for these components.

If you already got the component's source code, you might still want to check whether to upgrade them to Delphi XE2. It might save you some headaches. Upgrading well written components is not a problem for an experienced Delphi developer (I have done so countless times over the years), but might prove nearly impossible for somebody who doesn't know the possible pitfalls.

The only breaking change between Delphi 2006 and XE2 (actually it happened between Delphi 2007 and Delphi 2009) is the switch to Unicode strings. Switching an existing code base might be painless or a real pain in the lower back, depending on how well written it is to begin with and how it (ab)used strings.

Another option you have not yet mentioned, might be upgrading to Delphi 2007, which basically was more of a bugfix to Delphi 2006 than a real release in its own right. If I remember correctly Delphi 2006 packages worked with Delphi 2007 without even recompiling.

OTHER TIPS

A year ago I moved from 2006 to XE (not XE2). This was quite painless. The biggest thing was unicode. But even that was relatively easy (in my specific case probably). Most is handled by Delphi in a correct way. Biggest problems were the import components, especially when character strings were used as byte strings, which in my field (music, midi) is the norm. There is a white paper on strings conversion on Embarcadero.

I only use components with source available. If you don't, you might have have to repurchase the licenses.

It is a long jump taking 2006 to 2011/2012!

But it is possible if you consider that:

  • You have to convert String variables using the new conversions methods ;
  • You have to check all the versions between 2006 and xe/xe2 to know how the libraries have changed, bacause some have been spplited, others merged, and a few deleted ;
  • You have to buy/download the upgrade (if any) of your 3rd party components.

If you do that 3 things, the applications will compile just fine.

It's always easier to upgrade the IDE than rewriting the code, if there's any complexity in code beyond trivial cases like "Hello, World".

Big road blocks in Delphi 2006 might be: old components without source code, unicode issues, possible use of obsolete technologies (BDE mainly), and possible some low level hacking, like using undocumented features.

You get old versions of Delphi free when you buy XE2 licence. However Delphi 2006 is not there. Delphi 2007 is almost same (but better). It may even be possible to use D2006 binary packages with Delphi 2007.

When rewriting, first task for you is to find out what the software actually does. Line by line. Then you need to duplicate that in Java, hopefully in Java style, and then you need to verify against the old software that the functionality is actually there, duplicated.

So, you can choose between complete rewrite or something between recompile and partial rewrite, if there's problem with old components.

Read also this, old but good text: Things You Should Never Do, Part 1

That said, you need business reason for rewrite, and someone willing to pay for it.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top