Delphi 2009 and backwards compatibility

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.

This entry was posted in, SmartInspect. Bookmark the permalink. Both comments and trackbacks are currently closed.


  1. Andreas Hausladen
    Posted March 23, 2009 at 19:37 | Permalink

    3 weeks for 60K ? You are slow. :-) I’ve migrated 2000K LOC (in 5 DB applications) plus 1000K old components to Delphi 2009 in less than 2 weeks. But I’m a little bit experienced in migrating ANSI to Unicode due to my work on the JCL and the JVCL (which I haven’t included in the 1000K LOC).

    Most of the time it was using PChar for buffers where PByte would have been the correct type. The migration also brought many bugs to sight because I had to touch very old code.
    The CharInSet warnings are turned off because none of our applications uses the in-operator for characters >127 and I want speed over unnecessary code bloat.

  2. Posted March 23, 2009 at 20:52 | Permalink

    Actually, it was even four weeks. :-) Not all weeks were related to Unicode, though. Half the time I was fighting some obscure bugs such as and 2000K+ sounds really impressive. :-)

  3. Posted March 23, 2009 at 23:45 | Permalink

    I have tried D2009. Besides the migration problem, I think the MainFormOnTaskBar is also a nightmare The TrayIcon does not work so happy with it.

  4. Olaf
    Posted March 24, 2009 at 12:17 | Permalink

    The main stumbling point for a lot of shops in converting their apps to Delphi 2009 and Unicode seems to be that 3rd party component vendors went out of business or do not release an update for Delphi 2009. Therefore I think that it is a major marketing and support omission from CodeGear’s side to not provide a newsgroup or forum or section in CodeCentral for people to share their conversion “success stories” and to help and learn from each other in the effort.
    I am aware that posting code is usually not possible because of licensing issues, but some sort of automated “change log” or diff result might help a lot as well.

  5. Posted March 24, 2009 at 12:17 | Permalink

    We are also using the MainFormOnTaskBar option and TTrayIcon. I haven’t seen any problems with this combination so far. Could you be a bit more specific? Thanks!

  6. Posted March 24, 2009 at 19:08 | Permalink


    I think that would have been a great idea (and probably still is). A central place where people could lookup the state of Delphi 2009 support of specific components and libraries with the option to download a diff would be very useful for companies deciding/struggling with updating to Delphi 2009.

  7. Posted March 25, 2009 at 00:03 | Permalink

    You add TTrayIcon and TApplicationEvents on your main form.

    procedure TForm1.AppliationEvents1Minimize(Sender: TObject);

    Add a popup menu on form, create an item “Restore”, and assign it to TrayIcon.

    procedure TForm1.Restore1Click(Sender: TObject);

    I minimize my application and then try to restore it by right clicking tray icon and selecting “Restore”.
    But I cannot bring my main form back to front. Do you have any idea?

    There are several test cases to be tested:
    1. Click the minimize button (the “_” button ) from right-top-edge.
    2. Select “Minimize” from system menu
    3. Click “Show desktop” button on taskbar.

    If I turn off MainFormOnTaskbar, it does not have any problem to bring the main form back.

  8. Lachlan Gemmell
    Posted March 25, 2009 at 04:10 | Permalink

    Just curious which third party components you had to port to D2009. Anything by Turbopower by any chance?

  9. Posted March 25, 2009 at 13:18 | Permalink

    If your 3rd party component toolbox is too “big”, then it has always been tricky to upgrade from one Delphi version to the next. I doubt that Unicode is the real reason if some components are still not ported.

  10. Posted March 25, 2009 at 13:20 | Permalink


    sorry, no Turbopower components. I ported several smaller components (combo boxes, group boxes, help system related, among others) and the MP hex editor.

  11. Posted March 25, 2009 at 13:24 | Permalink


    will take a look, thanks for the details. Has you already added a bug report for this?

  12. Posted March 25, 2009 at 19:36 | Permalink

    Hi Tobias, I have not submitted the issue to QC yet.

    BTW: There must be some tricky code to make it work properly. But I am too lazy to try. I think, that to make everything compiled with D2009 is just the first step of the migration. Without enough tests, we can grantee nothing. I hate migration but I like UnicodeString. Difficult to decide ^^)

  13. Posted March 26, 2009 at 16:42 | Permalink


    I could reproduce this behavior with the Console as well. I do not think it’s a critical issue, though. After all, if your application is minimized, you can easily restore it with the task bar. Or have I missed anything? We use the tray icon mainly for “closing” the Console to the tray bar and restore works fine in this case.

  14. Amjad Daraiseh
    Posted October 9, 2009 at 21:36 | Permalink

    you have to add this code to your show function

    If WindowState = wsMinimized then WindowState := wsNormal;

    it should work …