21

I am interested to re-evaluate Delphi 2010. The main issue seems to be the ASCII to Unicode conversion. Any tips or resources about this that you have found useful?


Updates

I want to keep all interested with my progress. Hope people will learn from this.

At this point, my recommendation for those that want to upgrade would be to check:

http://www.embarcadero.com/images/dm/technical-papers/delphi-in-a-unicode-world-updated.pdf
Is WideString identical to String in Delphi 2009
What is the compiler version for Delphi 2010?
http://chee-yang.blogspot.com/2008/10/delphi-2009-unicode.html

GIF issues:

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 back up 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.


Upgrade to Delphi XE

I have finally purchased Delphi XE. Delphi XE proposes some new features but, unfortunately, quite few of them are not working at all (background compilation, UML modeling, code insight, etc). Other features have been downgraded (the help and, for example).
The IDE is also not as stable and fast as Delphi 7 and the toolbar has real problems (better don't customize the IDE). There is also a nasty bug where the IDE has 100% CPU utilization (see my other posts about all these issues). I hope that in Update 2 and 3 they will fix some of the most stringent issues.

Anyway, I think I upgraded too soon because now Embarcadero announced the 64 bit compiler, so probably I will have to pay again a lot of money to upgrade to the next version of Delphi in order to get that compiler. For those that are still thinking to upgrade to Delphi XE I would recommend to trial Delphi XE HEAVILY. Conclusion:

  • Delphi XE brings LOTS of new features, but obviously you won't be using ALL of them.
  • The stability of the IDE is not better.
  • It helps you build more up-to-date applications (modern UI open/save dialog, application manifest).
  • Support for Unicode.

Upgrade to Delphi XE7

The difference between XE and XE7 was not that huge, as the upgrade from Delphi 7 to XE. The IDE is as stable as before (lots of crashes and random access violations in RTL).


Upgrade to Delphi Rio

Considering the amount of years since the last update, I could safely say that the difference between XE7 and Rio is barely visible - except for those that are interested in cross-platform apps (Mac, Android but not Linux!). For me, the (proper) cross-platform support came too late.

PROS

  • True high DPI support (Really Embarcadero? After so many years?).
  • IDE does not crash so often as it used to crash in XE7.
  • VCL themes finally (seem to) work.
  • Most stable IDE until now (still crashes if you open a project group with more than one project in it).
  • Almost full cross-platform support (you need to purchase the more expensive Architect version to get Linux). Fortunately, for me, this is a bit too late. The projects where I needed cross-platform were already started under Lazarus.
  • Upgrading the code was super easy.

CONS

  • Some HIGHLY advertised features like dark themes don't work at all!
  • The Insight still buggy: new language features (like declaring inline variables) not supported by the IDE (the code will have that wiggled underscore red lines). This issue will probably never be fixed.
  • Another super annoying IDE issue is that the compiler will still show the last hints/warnings/errors EVEN after you fixed them. Looks like the log data remains in some kind of cache.

Overall it is the most stable IDE until now, but still I wonder (especially if compared to Lazarus) if it is worth that pile of money.

Upgrade to Delphi Sydney

Sydney is quite stable. Generics are better. GetIt is almost usable. Great support for iterators. Love the new VAR that can be declared anywhere in the body of a procedure and the type inference.
If you still own an old Delphi version, I strongly recommend you to upgrade to Sydney.

Upgrade to Delphi Alexandria

Everything went south to Alexandria. The IDE crashes when I try to install libraries. Many other weird issues in the IDE. The Community was in no hurry to update the plugins and libraries to Alexandria.
I happily downgraded back to Sydney.


Conclusion over the years:
Delphi is such a nice and clean language. And the Delphi compiler speed makes any C++ compiler to look like a toy for kids.
I still feel shame when people look down on me when I say that I am a Delphi developer. Delphi as a language is extinct now. Just look for Delphi jobs in Germany and only 74 positions are listed (but most of them are mixed with C# and others). C++ has over 1500 positions! They do offer a free (even though crippled) version of Delphi now, but the damage was done. It is too late to resurrect Delphi now.

I think three main issues lead to this state:

  1. Borland abandoned Delphi (Delphi lagged behind compared with other languages).
  2. Embarcadero took over but disrespected the customers (over-buggy, over-expensive product).
  3. MAIN ISSUE: The language was not promoted (at all) over the years. No sane company will spend thousands of dollars for a license of an already dying language. And the lack of a free license TOTALLY outcast the new generations of programmers.

Therefore, we are on StackOverflow, wondering each year if worth investing money in a new Delphi license.

Update
Finally, Emba released a free (aka Community) edition and boy you can see the effects.
For the first time in years, I don't feel ashamed to say in public that I use a dying language. Still, Delphi still needs more advertising. All the young generation think that Delphi is an uncool mastodon.

Gabriel
  • 20,797
  • 27
  • 159
  • 293
  • 1
    http://stackoverflow.com/search?q=[delphi]+[unicode]+upgrade – Craig Stuntz Apr 30 '10 at 16:57
  • 1
    I'm pretty sure D7's IDE is still the most robust one until today. And it more or less works without needing to run any installation - in doubt you're able to quickly get it run on a client's PC (for debugging reasons, of course). – AmigoJack Jun 15 '21 at 14:10

7 Answers7

15

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.

Nick Hodges
  • 16,902
  • 11
  • 68
  • 130
  • 2
    +1. That's a very good description of what happened where I work, and our codebase is definitely a huge one. (We've probably got close to 5 million lines of Delphi code between several different projects.) – Mason Wheeler Apr 30 '10 at 17:29
  • @Nick -> Are you referring to the "More resources on moving to Unicode" section in that page? I will take a look. Thanks. – Gabriel Apr 30 '10 at 20:40
5

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.

Chris Thornton
  • 15,620
  • 5
  • 37
  • 62
4

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.

Ken Bourassa
  • 6,363
  • 1
  • 19
  • 28
3

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.

lkessler
  • 19,819
  • 36
  • 132
  • 203
  • While reading the Jensen white paper one should probably ignore sentences like "Once your application is running in Delphi 2009 or later, see what happens when you intentionally add a Unicode character to your database through your user interface." Or even better, don't ignore them, think about what's wrong with them. – mghie Apr 30 '10 at 23:19
  • Another gem: "it may turn out that a user entering Unicode data is no less of a problem that a user entering, say, the wrong date. Garbage in, garbage out." – mghie Apr 30 '10 at 23:22
2

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.

mmmm
  • 2,431
  • 2
  • 35
  • 56
  • WOW, WOW, WOW! I knew about all other issues but not about "The structure of dfms have changed and are not backwards compatible". Do you mean that once I have loaded and saved a project in D2010, I can't go back to D7????? – Gabriel May 01 '10 at 11:19
  • You can go back - you'll just need to refill project's options. D7 stores options in .cfg file, D2010 - in .dproj file. You want to go back - you delete .dproj and open .dpr/.dpk. – Alex May 01 '10 at 21:00
  • I haven't tried to go back, but I recall that you can't open a D2009 DFM in Delphi 7. – mmmm May 01 '10 at 21:05
  • @Mmarquee: That's wrong. You can open a D2009 DFM in D7; you just get some "property does not exist" errors, which you can tell the IDE to remove. These are for new properties available in D2009 that didn't exist in D7, and the DFM works fine after they're removed. – Ken White May 03 '10 at 12:59
  • But you can't open the same DFM and use them in both D2010 and D7. – mmmm May 03 '10 at 22:17
  • I confirm it: Delphi 2010 will ruin a Delphi 7 form. After passing a D7 project through D2010 and pressing compile but WITHOUT pressing save, decreased the size of the DFM from 117KB to 9KB! – Gabriel May 04 '10 at 18:52
1

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.

J...
  • 30,968
  • 6
  • 66
  • 143
0

View this Embarcadero webinar on how to migrate from older editions of Delphi with some stories of what to look for and how to update your code (including tools and resources to help you along the way), on this link: https://community.embarcadero.com/blogs/entry/migrating-delphi-case-studies

Al Mannarino
  • 11
  • 1
  • 4
  • Could you summarize the relevant sections from the linked resource? –  Mar 28 '18 at 21:47