In my last post (http://caryjensen.blogspot.com/2009/10/share-your-unicode-migration-story.html) I asked Delphi and C++Builder developers to share their Unicode migration success stories. In doing so, I think that I may have implied that converting existing Delphi applications to RAD Studio 2009 or RAD Studio 2010 presented a challenge. This is not always the case.
The truth is, some applications can be migrated to Unicode versions of RAD Studio with little or no modification. It all depends on the techniques that you have used in your applications.
I recently presented a five-day Delphi course that covered a wide range of topics, including creating and using DLLs, multithreaded programming, component creation, and basic database development. The target environment for this class was RAD Studio 2009.
Most of my code samples for this class had been originally created with earlier versions of Delphi, some going back as far as Delphi 1 and 2. While updating this course material to Delphi 2009 I had to migrate more than 60 projects. Of those projects, only a handful of them required modifications associated with Unicode. These were almost exclusively associated with the DLL examples where PChars were being passed as parameters. All the rest simply compiled and ran properly without changes.
Granted, these projects were very limited in scope, designed specifically to demonstrate a particular feature or technique. As a result, they lack the richness that is normally associated with client applications. Still, given the many different techniques that these code samples represented, it is impressive that most required no modification to run in Delphi 2009.
Is this typical, or is it the exception? I want to hear from you. Have you moved a Delphi application to RAD Studio 2009 or 2010 with little or no modifications? If so, your story is also important.
Send me a quick email to mailto:cjensen@jensendatasystems.com with the subject line Delphi Migration. Tell me a little about the size and scope of the project, and how much effort you migration required. Other Delphi developers will be grateful.
Copyright © 2009 Cary Jensen. All Rights Reserved
The moment you interact with strings as binary data, or binary data in strings everything goes sideways fast.
ReplyDeleteSocket code (non indy), com code, strings in streams, mailslots, legacy components that do a lot of text work with chars, encryption work - all of these things get ugly when you try to cross over in to unicode land.
Basically anything low level.
And don't even get me started on the false promise of Unicode and databases... You explain to a user why his 10 character entry is too large for a 10 character database field, which can happen even if your database supports UTF16 encoding.
Plenty of bear traps still waiting to be found in unicode world as people pretend that UTF-16 can be treated like 16 bit character strings. There is a LOT of character handling code that is eventually going to choke horribly on something that is multi-byte coded.
I think Codegear makes too much ado about migration. Good unicode practices in new applications are much more interesting.
ReplyDeleteMost of the problems arise when your app needs 3rd party components which have no Unicode version (some will neve have, because the company gone bankrupt or moved out of delphi development).
ReplyDeleteSOme of them are absolutely insane to convert without the original developers, EVEN with source.
I am still waiting for a Delphi release that have working localizations tools. Those in 2010 still have big issues, and are not able to localize but trivial applications. "Global" applications have to be able to handle both contents and intrface in desired languages, and Delphi is still unable to deliver a comprehensive solution but using third party tools.
ReplyDeleteIn response to sergworks, I do think that migration is an important issue. If you want to keep up with the latest versions of Delphi, older applications must be migrated. For example, when 64-bit compilation is available, a legacy application will be able to take advantage of that only if it has been migrated.
ReplyDelete