We have large commercial app that we want to convert from Delphi 6 to 2010. Approx 10 3rd party component sets, all with source code... I have heard warnings about Unicode with 2010 - Does anyone have experience and or suggestions?
There are many resources available that you can read and that you will assist in the migration from Delphi 6 to Delphi 2009/2010 (Unicode).
You can use these articles as a guide.
Unicode Migration Statistics Tool (This utility will hopefully assist you in collecting useful statistics
on how hard (or not) it would be to migrate your older applications to
Unicode.)
Delphi 2009 and Unicode
Delphi 2009 strings explained by example
Upgrading a major project to Delphi 2009
Delphi and Unicode
Dr. Bob Delphi 2009 Unicode
Delphi 2009 - Unicode in Type Libraries
On Strings and Unicode in Delphi 2009
Delphi in a Unicode World Part I: What is Unicode, Why do you need it, and How do you work with it in Delphi?
Delphi in a Unicode World Part II: New RTL Features and Classes to Support Unicode
Delphi in a Unicode World Part III: Unicodifying Your Code
CodeRage 4 : Using Unicode and Other Encodings in your Programs
Bye.
You'll find some useful answers in these StackOverflow questions:
Move project from Delphi 3 to Delphi 2010
When and Why Should I Use TStringBuilder?
Convert function to delphi 2009/2010 (unicode)
Unicode problems with Delphi 2009 / 2010 and windows API calls
Also, for what it is worth, I purchased Marco Cantu's Delphi 2009 Handbook. It was all I needed to make a relatively smooth converstion from Delphi 4 to Delphi 2009 in only a few weeks.
I do, however, recommend that you ensure your 3rd party packages have a Delphi 2009 upgrade, or you may have some real difficulties. Converting your own code is one thing. Converting someone else's is another.
I use two 3rd party packages, both with source code. Both had upgrades available, and the developer of one of them wrote that he had a lot of trouble upgrading his very complex component to the Unicode of Delphi 2009. It took him a few months, but he completed it. And as a result, I had little trouble with my implementation of his component when I did my upgrade.
i've been in the same circumstance recently. you mostly need to pay attention to the "edges" of the app. INI files, file I/O, log files, etc. win API calls from delphi work since they've now connected the unicode API calls instead. check each 3rd party component set to make sure they're at least ready for Delphi 2009...better yet 2010. even my use of databases simply wasn't an issue...nearly everything worked right away. it just wasn't a big deal. anything that relies on the size of a character should be reviewed.
really the transition of most concern is 2007_or_earlier --> 2009_or_later.
there are plenty of discussions/blog entries about it. you could read, read, read...or you could get started & see what happens. (i did some of both). i'm sure there are "stack overflow" issues discussing your question. i'm not pretending to give a detailed description of what could happen.
it's simply not as scary as it sounds.
Approx 10 3rd party component sets, all with source code.
One thing I'd add is if the component doesn't support Delphi 2009/2010, don't try to upgrade it by hacking the code.
Following is what I posted on How do the new string types work in Delphi 2009/2010?:
See Delphi and Unicode, a white paper written by Marco Cantù and I guess
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), written by Joel.
One pitfall is that the default Win32 API call has been mapped to use the W (wide string) version instead of the A (ANSI) version, for example ShellExecuteA If your code is doing tricky pointer code assuming internal layout of AnsiString, it will break. A fallback is to substitute PChar with PAnsiChar, Char with AnsiChar, string with AnsiString, and append A at the end of Win32 API call for that portion of code. After the code actually compiles and runs normally, you could refactor your code to use string (UnicodeString).
I must add this article from Carey Jensen to others mentioned. It is labeled: "Delphi Unicode Migration for Mere Mortals: Stories and Advice from the Front Lines" (in english).
http://www.danysoft.com/free/delphiunicodemigration.pdf
As you can see in the title of it, you will find many experiences and hints and tips. I think it is the answer to your question. After carefully read it, you will sure knows what to do next. :)
Found in: http://www.danysoft.com/productos/migrar-aplicaciones-a-delphi-xe-o-cbuilder-xe.html
Another point to take care of, is the usage of Variant types with strings and the VarType function testing for strings: one needs to use varUString instead of varString.
Assuming AValue is of type Variant and has being assigned a Unicode string value, the following won't work:
if VarType(AValue) = varString then ...
and needs to be changed to
if VarType(AValue) = varUString then ...
Related
There is a code base in delphi 2006 with no development for last many years. If the development needs to be activated what are the options.
Continue developing in 2006. (Not sure of IDE support etc.)
Migrate to Delphi XE2. (Not sure of what it takes)
Recode it in Java.
It seems the second option is more viable but what it would involve to do that? I read some things on Unicode support and also not sure of graphics library support.
Just to put thing in perspective, I am a Java programmer all along with experience on C/C++. However I am trying to understand it more from the perspective of what is the least resistance path to go to market strategy.
Thanks in advance.
I cannot say anything about recoding it in Java. Depending on whatever the code base does, it might be a good option, given that you say you are experienced with Java (and, I assume, not with Delphi).
Regarding Upgrading to Delphi XE2:
Check whether any 3rd party components have been used.
If not, you will probably be able to upgrade to Delphi XE2 with very few changes.
If yes, check whether the source code of these components is already available.
If not, you will have to buy new licenses of these components (and this time take the license that includes the source code!) if you want to upgrade to Delphi XE2. If you are really unlucky, the company who developed these components has gone belly up. Then you are either stuck with Delphi 2006 or you will have to find a replacement for these components.
If you already got the component's source code, you might still want to check whether to upgrade them to Delphi XE2. It might save you some headaches. Upgrading well written components is not a problem for an experienced Delphi developer (I have done so countless times over the years), but might prove nearly impossible for somebody who doesn't know the possible pitfalls.
The only breaking change between Delphi 2006 and XE2 (actually it happened between Delphi 2007 and Delphi 2009) is the switch to Unicode strings. Switching an existing code base might be painless or a real pain in the lower back, depending on how well written it is to begin with and how it (ab)used strings.
Another option you have not yet mentioned, might be upgrading to Delphi 2007, which basically was more of a bugfix to Delphi 2006 than a real release in its own right. If I remember correctly Delphi 2006 packages worked with Delphi 2007 without even recompiling.
A year ago I moved from 2006 to XE (not XE2). This was quite painless. The biggest thing was unicode. But even that was relatively easy (in my specific case probably). Most is handled by Delphi in a correct way. Biggest problems were the import components, especially when character strings were used as byte strings, which in my field (music, midi) is the norm. There is a white paper on strings conversion on Embarcadero.
I only use components with source available. If you don't, you might have have to repurchase the licenses.
It is a long jump taking 2006 to 2011/2012!
But it is possible if you consider that:
You have to convert String variables using the new conversions methods ;
You have to check all the versions between 2006 and xe/xe2 to know how the libraries have changed, bacause some have been spplited, others merged, and a few deleted ;
You have to buy/download the upgrade (if any) of your 3rd party components.
If you do that 3 things, the applications will compile just fine.
It's always easier to upgrade the IDE than rewriting the code, if there's any complexity in code beyond trivial cases like "Hello, World".
Big road blocks in Delphi 2006 might be: old components without source code, unicode issues, possible use of obsolete technologies (BDE mainly), and possible some low level hacking, like using undocumented features.
You get old versions of Delphi free when you buy XE2 licence. However Delphi 2006 is not there. Delphi 2007 is almost same (but better). It may even be possible to use D2006 binary packages with Delphi 2007.
When rewriting, first task for you is to find out what the software actually does. Line by line. Then you need to duplicate that in Java, hopefully in Java style, and then you need to verify against the old software that the functionality is actually there, duplicated.
So, you can choose between complete rewrite or something between recompile and partial rewrite, if there's problem with old components.
Read also this, old but good text: Things You Should Never Do, Part 1
That said, you need business reason for rewrite, and someone willing to pay for it.
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?
Many thanks.
Edit:
At this point my recommendation for those that want to upgrade would be:
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 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.
UPDATE 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.
UPDATE 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).
UPDATE Delphi Rio
Considering the amount ot 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!).
PROS
True high DPI support (really Embarcadero? After so many years?).
IDE does not crashes 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 worth that pile of money.
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 ashamed 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! Borland and Embarcadero helped a lot to kill Pascal. They do offer a free (even though crippled) version of Delphi now, but the damage was done. It is to late to resurrect Delphi now.
I think three main issues lead to this state:
Borland abandoned Delphi (Delphi lagged behind compared with other languages).
Embarcadero took over but disrespected the customers (over-buggy, over-expensive product).
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 am the user of Delphi (a dying language).
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.
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.
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.
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.
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.
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.
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
I've just received an assignment to upgrade an old Delphi 3 project that I wrote in 1999 to a newer version and add features (I previously discussed this in related questions here and here). I was assuming that the appropriate route would be to first upgrade my development environment to Delphi 2010 and then port the application.
I'm now considering whether to upgrade the application to my existing copy of Delphi 2007 instead in order to avoid the Unicode complications. The application runs at a single company in the United States and is tightly bound to requirements of a single state, so it would not benefit from Unicode support.
My question is: would the additional hassle of dealing with Unicode issues outweigh the benefit of using the most recent version of Delphi? You may assume that I have no experience with Unicode.
why "upgrade" to a version that is not the latest, it just guarantees an earlier "next upgrade".
I'm very very happy with Delphi 2010, I recommend porting to that version unless you use a 3rd party lib that is not available for D2010
You should try it (the upgrade) on a D2010 trial, and give yourself a day or so to get a feel for the type of complications that result. Generally, if you didn't use a lot of PChar for pointer arithmetic, and you didn't use sub-ranges of strings, e.g. Code[1] := 'A', and so on, there should be few or no upgrade issues. Aside from the unicode upgrade, the D2010 IDE is much nicer to use, and seems faster than D2007.
D2007 may be easier to upgrade, because you it will not require changes of your code to work probably with Unicode, and if your code doesn't require a lot of PChar and others ANSI dedicated functions, it may work in Delphi2010 without a lot of work.
But if you have time and resources to upgrade to Delphi 2010, it will be better options, because sooner or later version from Delphi 2009 and later will be the standard versions.
Also the IDE productivity is higher in D2010, beside new language additions like generics, anonymous methods and others which make your code better, if you going to rewrite some sections of it.
They have done such a good job implementing Unicode in Delphi 2009 that most programs that do not do tricks with characters and bytes convert over with no problem.
The caveat is as long as you are not using any 3rd party packages. If you are, you should upgrade those. If they don't have upgrades and you don't have their source code, then you might be better off not going to Delphi 2010.
But I would make the jump if at all possible. I did and I'm glad I did.
"That depends"
It depends on the number of 3rd party controls and the current state of those controls. (Are they still on the market with updates for 2007 and 2010?)
It depends on code size and code quality. If you have a large, loosely managed code base it will be a harder path to 2010.
It also depends (largely) on project input/outputs... are you reading from files/databases/communications? How will they react to Unicode, or can you easily narrow down all of those touch points to ensure proper handling?
One other major dependancy is the life of the application... "Going Unicode" now might serve you better if you are going to support this application over the long term as eventually they'll stop selling 2007 and you'll be forced into it.
I own 2009 and have built minor applications/utilities with it, but the main work is still in 2007, 2006, D7, and D5 depending on project.
See here. It can confuse the things when coming to D2010.
I have a few Delphi 6 third party components which I need to add to Delphi 2010 to begin my migration. Is it possible? The interface seem a lot different and I can't seem to find a way to do this?
This help...
My components: DBGridEasy, TSerial, Varian Async32.
Thanks a lot.
As has been mentioned this is not straightforward. But you do have options.
Check with Vendor and get update
if you have source you can try to update yourself.
I don't agree that it is neccesarily too complicated to upgrade. Delphi 2009 did add (finally - about a decade after it should have) very good Unicode support into the heart of delphi, but this was done down to the level of almost every built in function.
We upgraded a large (700,000 lines) project in only a couple of days. There is info on the net on what to do, there are a number of functions you need to replace if you use them (such as any funcion with Ansi in the title). Its worth a try at least.
If you dont have the source I'm afraid you have no choice but to contact the vendor, there is nothing you can do since the binary format for each Delphi version is differnt.
I don't know for sure about those particular components, but it probably won't work even if you have the source for them because there were many changes between those versions, such as the string type changing. You would be better off finding out if the vendor has updated them.
The biggest change between Delphi 6 and Delphi 2010 is the changing of the default strings to Unicode in Delphi 2009.
I highly recommend against using any pre-Delphi 2009 component with your upgrade. They will not know about Unicode and you will run into problems.
First, you should see if the new version of Delphi already has the functionality you want built in. Many things have been upgraded over the years. You may find you don't need some of your old components at all.
For the ones you still need, try to find an upgrade, or some other similar component that is ready for Delphi 2009. There are many grids around. I am not familiar with Serial or Async programs to recommend one.
This might already help you: Varian Async was acquired by TMS, the same component is now known as TMS Async32
I have a rather large (freeware) project written with Delphi 2007 which is using both the TntUnicodeControls and the TntLXControls library and I'm planning to move to Delphi 2009.
Unfortunately I'm using those libraries everywhere in my project:
Replacement for VCL controls to provide Unicode capability
Win32 API wrappers (mostly for comparing strings)
The feature enhancements of TntLXForms, TntLXRegistry, ...
Third-party components which use TntControls. (VirtualTrees, SpTBXLib, updates for D2009 are available)
Do you have any experience and/or suggestions in porting such a project to Delphi 2009. Is it advisable to first switch to the (commercial) TMS Unicode controls?
Install GExperts; there is "Replace component" IDE addin that can help converting TTntXXX to TXXXX controls. Try for once, and if it's ok just check "Replace evrywhere in project".
SpTbx and VirtualTrees can only be recompiled - they both support D2009.
If you used WinAPI wrappers just to call Unicode API-s they should work in D2009 also.
That leaves you with TntLX controls (TntLXForms, TntLXRegistry, ...). Since they are unsupported, may be it is good time to change them anyway.
I can help with some of this, as I'm porting a C++Builder application that uses TNT from 2007 to 2009. The switch to Unicode in D2009 is overdue and welcome. However, it's unfortunate that the transition is probably easier for those who have NOT needed unicode in the past, and probably still don't. If, like me, you needed Unicode and used Troy Wolbrink's great TNT control to provide it, you have a rather more complex job...
The good news is that there's a new version of TNTControls from TMS Software which supports D2009. I haven't looked at this, but expect it is just a 'facade' layer over the native VCL components to ease portability. I'd consider that if your other libraries can be rebuilt to use it.
However, you may be better going back to native VCL controls, and the reason is string types. TNT control have always used WideString to pass Unicode strings back and forth, and you may well have WideString use scattered through your own code. This will work, but it's not ideal as WideString should really just be used for COM interop as it 'wraps' the COM BSTR type. Native unicode strings in D2009 are reference-counted and should be significantly faster.
If you do decide to replace TNT components with native VCL ones, you can use GExperts "Replace Components" command - or, maybe easier, do a search and replace in your .DFM and .PAS files (which you DO have in text form, don't you) to replace TTNT with T.
I recommend the following resources:
Marco Cantu's Delphi 2009 Handbook Chapter 3 (Porting to unicode)
http://www.marcocantu.com/dh2009/
Nick Hodges' articles (Delphi in a Unicode World)
http://blogs.codegear.com/nickhodges/2008/11/20/39149
I think either way it's going to be a lot of work. Probably more so than if you hadn't done all the work to make it unicode compatible before. I personally would forget about the tms Unicode controls, and go back to the vcl. It will save more pain in the future. (nothing against those controls, mind you.)
Also remember, that D2009's string, is not the same thing as D2007's Widestring which you have undoubtedly used in your app. So all instances of Widestring, which you so diligently changed from string (which was AnsiString), need to go back again to string(which is now unicodestring).