My Account account_circle

In a recent blog post I saw on, Babnik argues that Delphi 2009 should have been compatible with older Delphi versions by still treating String as an AnsiString and introducing a parallel VCL with UnicodeStrings (think TEdit vs. TEditW). I don’t think this would have been a good idea.

I understand that there are many Delphi users who want to upgrade to Delphi 2009 to benefit from additional features but don’t care about the Unicode improvements (or already use a different technique to support Unicode such as the TNT Controls). Adding this compatibility mode would therefore be a great short-term solution for them but would result in huge technical debt for CodeGear.

For CodeGear, this would mean supporting two parallel versions of the VCL for at least the next few versions of Delphi. What a support and maintenance nightmare! Likewise, third-party vendors would have to ship two different versions of their products for Delphi 2009 and beyond. One compiled with Unicode support and one without. Again, a maintenance nightmare.

I admit that porting real-world applications to Delphi 2009 can be quite a bit of work. The just released version of SmartInspect now uses Delphi 2009 for the SmartInspect Console. Previous versions were built against Delphi 2006 and I can say that the transition wasn’t as smooth as I hoped for. Like Babniks product, the SmartInspect Console already supported Unicode by using WideStrings and the TNT Controls, so there wasn’t a need to update to Delphi 2009 just because of Unicode. But we wanted to fix a few Vista related bugs and other glitches and Delphi 2009 includes fixes for most of them. So we decided to give Delphi 2009 a try.

It turned out that converting the Console itself wasn’t that big of a problem. The warning messages of the Delphi 2009 compiler are really helpful and we got most of the Console running within about two weeks. A bit more problematic were some no longer maintained third-party controls and it took two more weeks to get the Console to a really stable state. That’s more than I expected but still okay for such a one-time conversion (the Console has about 50K LoC + forms, the unmaintained third-party controls were about 10K I guess).

In retrospect, I think it was well-worth the time and Delphi 2009 feels like a good version. The IDE is much more stable than Delphi 2006 and the language and VCL finally got some much-needed improvements. We are also happy that we could throw away the WideString and TNT related code. Using Delphi 2009 makes the Console code much cleaner. It also got a bit faster because of the performance improvements of UnicodeString compared to WideString.

So, while I can understand that not everyone wants to invest the time for the Delphi 2009 conversion, I do not think that adding this compatibility mode would have been a good decision, especially not in the long run.

How useful was this post?

Click on a star to rate it!

Stay ahead in Test Management.

Follow us on social media!

Help us improve this page!

What problem are you trying to solve?