Any hints for those that want to upgrade from Delphi 7 (and down) to Delphi 2010?

Question

Hi. After update 4 and 5 I am interested to re-evaluate Delphi 2010. This time I intend to port some of my code (small scale) to see how difficult is to do it at large scale.

The main issue seems to be the ascii to unicode conversion. Any tips or resources about this that you have found useful?

Many thanks.

---

Edit:

At this point my recomendation for other people (that want to upgrade) would be:

http://www.embarcadero.com/images/dm/technical-papers/delphi-in-a-unicode-world-updated.pdf

http://stackoverflow.com/questions/374446/is-widestring-identical-to-string-in-delphi-2009

http://stackoverflow.com/questions/1369191/what-is-the-compiler-version-for-delphi-2010

http://chee-yang.blogspot.com/2008/10/delphi-2009-unicode.html

Note that Gif (by Melander) and Png (by Martijn Saly?) images are now incorporated in Delphi 2010. You will have to use a conditional in order to use the right GIF unit:

USES Windows, SysUtils, Graphics, blabla
{$IFDEF VER150}
  , GIFImage,     {Delphi 7}
{$ELSE}  
  GIFImg          {Delphi 2010}
{$ENDIF}; 

Also you need to "fix" the PNG provided by Embarcadero: http://talkdelphi.blogspot.com/2009_03_01_archive.html

Other things that you need to know is that you really have to backup your project before opening it in Delphi 2010. Delphi 2010 will change your DFM file even if you don't press the Save button. The form will lose data and it will not compile in D7.

Answer 1

The biggest problems are with 3rd-party libraries and VCL. If they're not on D2010, it can be painful. The Unicode issue comes up if you are doing calculations with the length of strings or PChar arrays, assuming one byte per character. You can usually get away with treating everything as old-style AnsiString / AnsiChar. But then you don't get the benefits of Unicode. If you don't have anything that would be hard to do in Unicode, just do everything in Unicode and you'll be much further ahead than if you have to worry about switching back and forth.

Answer 2

We have created a web page specifically for this very issue:

http://www.embarcadero.com/rad-in-action/migration-upgrade-center

There, you can find webpages, documents, webinar replays, etc. which all cover the issue of migration.

The first thing people say is "I have a huge codebase, and migrating to Unicode will take forever" and almost without exception they discover that "forever" really is a much shorter period of time than they originally thought and that the new features of Delphi 2010 make it all worth it.

Answer 3

Converting code to unicode doesn't take that much time in itself as long as you didn't do anything "funny" with your strings. I converted close to 1m lines of code + the database in less than 2 weeks. The guys at codegear did a very good job at doing it a lot simpler.

Your code might recompile in D2010 without any changes (But with quite a few tons of hints/warnings).

The worst problem from the conversion comes from calls to Window's API that were incorrectly done. For exemple, the function GetComputerName that ask you the size of the buffer in TChars(as specified by the API). In Ansi, TChar = 1 byte, so Length = SizeOf. In Unicode, it's not true anymore. Worse, the call to the API might not fail. It will just overwrite some valid part of memory and will crash just much later.

Oh... And there is also those slight differences between Ansi and Unicode in Windows API. For exemple, the lpCommandLine of the CreateProcess is read-only in the Ansi version, but read/write in the unicode version. So using a constant as parameter worked fine in Ansi, but will crash in Kernel32.dll in Unicode.

Overall, it depends a lot on the quality of the code you are working with. Bad code might be very hard to port to D2010. Good code should be pretty easy.

and read the resources that Nick Hodges linked to, they are pretty helpful.

Answer 4

For Unicode conversion issues, your best bet to see the problems people have encountered and what others have done is to get Cary Jenson's White Paper: Delphi Unicode Migration for Mere Mortals.

Also I'd highly recommend Marco Cantu's "Delphi 2009 Handbook" that describes all the changes in the Major 2009 release that includes Unicode and Generics and more. Much of his Unicode material from that book is in his White Paper: Delphi and Unicode.

Answer 5

We have upgraded from Delphi 7 via Delphi 2007, 2009 and now 2010! The following are the biggest issues we have found.

• Threads have changed, with Resume and Suspend being deprecated.
• Unicode
• The structure of projects have changed and are not backwards compatible
• The structure of dfms have changed and are not backwards compatible

Hope this helps.

Answer 6

I agree with Chris - the biggest problem in migrating our code to 2010 was getting all of the 3rd party libraries working. A number of them needed minor source edits here and there and had to be installed from the modified source. Still, that said it wasn't more than a day or so of getting things sorted out.

The only other problem we've had moving to 2010 involved one small section of code that went buggy because of a change in the way 2010's ProcessMessages works. It was an old piece of code that probably shouldn't have been written the way it was to begin with (ProcessMessages and Sleep() inside a while loop waiting on an OPC variable change). It worked in 2007 but in 2010 it somehow devoured system messages and locked up the OPC server. For us it was a small fix, but like Ken said it will likely depend on the quality of code you are porting. 2010 seems a bit less tolerant of poor practice and ugly hacks.