Move project from Delphi 3 to Delphi 2010

5
votes

I've been asked to re-open a project I wrote in 1998/99 in Delphi 3 and which has been running stably since then. I have the Delphi 3 code base on an aging Windows 98 machine which exists only to keep this project alive. Obviously, I'd like to bring the source code base into the 21st century before undertaking any major revisions.

I note happily that Delphi 2010 (I'm currently on 2007) claims to be able to import projects from Delphi 2 on. Does anyone have any experience importing large projects from Delphi 3? Can I expect this to be an easy transition, or a difficult one?

In addition the original project makes use of third party components including DBISAM, WPTools, and TMS Planner. I note that all of these are still available for the latest release of Delphi. Assuming I first install the new versions into Delphi 2010 can I expect the parts of my application that use these components to be translated as well? I know that at least WPTools has changed some of its component structures and interfaces since the version used in the original application and obviously I'll have some recoding to do there, but will the failure of those parts of the program prevent my code base from being upgraded at all?

7
delphimigrationdelphi-2010
You should really evaluate first whether a recompilation with Delphi 2010 will really bring the app "into the 21st century". A modern app uses recent controls and (Vista-style) dialogs and thus looks totally different, supports visual styles, works with limited user accounts, properly supports Unicode (that's much more than getting it to compile with Delphi 2009+), has no hard-coded paths, ... Maybe there's so much to be changed and fixed that a rewrite with Delphi 2010 is a better proposition? – mghie
@mghie Maybe his plans is bring the codebase to D2010 to unify the development environment and getting used to it before adventuring on a rewrite or heavy changes. – Fabricio Araujo
I'll have some rewriting to do in any event since the original codebase (I wrote it myself) isn't great. Still, I want to know that I can get a working version of the program in relatively short order, from there I'll rewrite as the project allows. Unicode is not that important, this is a line-of-business application for a firm whose business is bound tightly to the laws of a single US state. – Larry Lustig
As far as Vista style dialogs (and I believe the office where this application runs is still on XP) can that not be handled by simple refactoring after the application is compileable? – Larry Lustig

7 Answers

6
votes

It should be very possible to do this migration, and depending on how your code is written, it may either be painful or painless. Unfortunately its not easy to say which until you start the migration process.

The first thing i would do would be to make sure that ALL DFM files are converted to their text representation. This I believe was set to default in later versions of Delphi but as I recall Delphi 3 used a binary format. There should be a utility file named DFMConvert or something in the delphi 3 bin directory which allows you to convert a DFM to text. The reason you will want to do this is to insure that you can read the source if you have to perform a hand edit of the DFM due to a component not loading. Not only are you jumping versions of Delphi, but you also are jumping versions of EVERY component you use and there may be a few incompatibilities that may cause a component to fail loading. I have found if this is the case and you have a "new" version, then use the edit the DFM source directly and compare a test form with the component on it against what your old version contains. Remove anything (or rename) that is out of place and then attempt to load the form again.

As Frabricio mentioned, if you use variants then you will need to make minor adjustments to your uses clause.

The good news is that your code itself should work fine once you get the components/uses clause corrected. If you go directly to Delphi 2010, your only other issue would be Unicode and the compiler does a fantastic job of pointing all of them out to you via errors and warnings.

5
votes

As you have D2007 and assuming all these component sets come with D2007 dcus as well, I'll advise you to first try reopen the codebase on D2007. And after that, go to D2010 because of the Unicode feature of the actual VCL - which can create some migration problems (which I'll not discuss here because it's deeply discussed on the web and here on SO).

I'd say that because somewhere between D5 and D7 (don't record exactly) happened an unit reorganization of the rtl (with the creation of the Variants.pas unit and many OTAPI units changed names, etc). So that will be where your first problems arise. EDIT:Not only Variants got relocated, but much IDE integration stuff too - to avoid unlicensed code to get deployed. If you have some OTAPI code (for example, code that allows published properties on inherited forms), it'll need to be relocated to a package project.

As skramradt said, you may have to deal with the binary DFM thing....

After that, if all works, go to the Unicode thing. Depending on the app, it can be easy or not. For mine ones, not of great annoyance. But I know there are others facing greater problems with it than me.

4
votes

Here are a few notes we made regarding upgrading to Delphi 2010

  1. The executables complied in Delphi2010 are about 3 times more bytes than those compiled by Delphi3.
  2. Any compilation will result in a whole heap more warnings and hints than Delphi3. Good practice is to remove all hints and warnings.
  3. I have found several corrupted Pascal file that compiles fine in Delphi3 but not in Delphi2010. Visually there appear no problems or difference. However compilation errors clearly indicate the error on the wrong line number. In my examples the issue was related to CR/LF, in my Delphi there was only a CR. A difficult problem to solve and a real time waster. However the text may be viewed in Notepad or using WinHex.exe. I have written a program called PARSER.EXE, which allows these control characters to be identified. This is the best way to edit these files in Notepad once you know where the control characters are.
  4. AnsiString. Delphi 2010 now uses AnsiStrings, MBCS and WideStrings, (UniCode). As opposed to Delphi 3 which used ASCII strings. The standard Delphi 2010 implementation uses strings as Unicode and Chars as 16 bit characters. It is now necessary to ensure that many 8 bit ASCII strings are defined as AnsiStrings. Obviously older dlls that had interfaces defined with PChars now require PAnsiChar.
  5. The code is not interchangeable between the Delphi platforms for the following reasons
  6. Delphi 2010 has extra functions and variable types such as AnsiChar, AnsiStrings.
  7. The forms are not compatible between versions because latter Delphi versions have extra properties.
  8. The dcus are not compatible between versions.
  9. The packages are not compatible between versions. There is no Crystal Reports in Delphi 2010 so you may need to purchase this separately. Any other packages that were used may also require upgrading, at cost.
  10. Many functions, such as Readfile, Writefile, GettickCount now insist on parameters as DWORDs, whereas Delphi3 was more tolerant. Some of these functions are associated with higher disk capacities.
  11. Popup Menus. These have a new property called AUTOHOTKEY. This should be set to manual. If this is set as default, the captions will have ‘&’ inserted to provide hot key functionality.
  12. Cursors. The method for using cursors has changed.
  13. It appears that Delphi2010 has a whole heap more features that have been added at the expense of making it simpler to use. Probably Delphi 3 had a better and more easy to use interface.
  14. Help. Maybe better than Delphi 3. But seems to disappear for some minutes trying to find help information. Interactive help is a nuisance.
  15. BorlandMM.dll does not work on Windows 2000 with Delphi 2010 Applications. So you may have to upgrade a load of PCs if you want to use this dll.

I have about 100 applications dlls and COM servers to upgrade. Probably about 12 weeks work with commissioning. Hope this helps.

3
votes

Just to reassure you, I recently converted the software I am developing from Delphi 4 to Delphi 2009 to gain Unicode capabilities, and I had a number of issues, but they were all solvable within a couple of weeks.

One thing to note: If you use any 3rd party packages, make sure they have a Delphi 2010 version available that you can upgrade to before you convert. Delphi 2009 would be okay, but I would not try to use older packages in D2010.

1
votes

I can't say much about migrating D3 to D2010, but I've recently migrated D6 to D2010 successfully. To begin with, what I did was to make sure that all third party components that you've used in D3 are also available in D2010. Recompile any custom built components from D6 to D2010. Loaded my D6 source code, and compile. Handle all unicode issues. Handle all the compiler errors one by one... all done in about 3 days (approx 30000 lines of code)

0
votes

I have a Delphi 7 project group which Delphi 2010 readily upgraded. Unfortunately, during the next start with the newly created Delphi 2010 project group files, the IDE just crashes and vanishes after loading the project. No exceptions are shown, no error messages. My workaround is using the Delphi 7 file all the time and let Delphi 2010 upgrade whatever it likes to without using the newly created project files.

0
votes

I confirm what the others are saying: converting a D3 application to D2010 is usually easy as far as your own code is concerned.

I see two difficulties:

  1. You used String as general buffer, storing something else than characters.
  2. Your code assume that sizeof(char) is 1, that is use Length() when SizeOf() should be used or the reverse.

The most difficult part are the 3rd party components.

It looks like all components you are using still exists for D2010, that is a good point. But it is likely that their interface has been changed and of course will require some code changes.