This blog has moved. Please update your bookmarks.

Upgrading Delphi: From 5 To 2005

Our company is currently preparing to upgrade our development system from Borland Delphi 5 to Delphi 2005. While the process is pretty much straightforward, there are a few issues that have come up.

First of all, it's a big process. We meant upgrade to Delphi 6 when that came out, then Delphi 7, and now we have to upgrade to 2005 before it's all too late. Since we're planning on doing this in a Big Switch, all of our software needs to be updated. This involves the two major product lines we're running, as well as a serious number of little nifty utilities we've developed along the way. Fortunately, Delphi is in itself pretty much a seamless upgrade: The language and the VCL is entirely backwards-compatible - Thank God - and if it all comes down to Borland, all it takes is a recompile.

The trouble starts with the components, though. Over the years we've amassed a serious library of components, which we've incorporated into our programs. Some of them we've purchased, some are open source, some are ... well, just found online and if the author isn't dead by now, development sure is. Torry.Net usually is a terrific place to look up Delphi components, but some of them are bordering on old.

The migration of open source components is usually a bit tricky, if enough time goes by. Every two years it seems like the authors decide their old version is dull, throws it out and develops a new version with an incompatible API. Such was the story of ZeosDBO, an excellent library of database components (just plain source code, no big install, no BDE/ODBC..); our 5.4.1 version is now horribly out of date and the 6.1.5 version is an entirely new API. Fortunately enough not too dissimilar, but it still means going over every single project and update every single database component. And that takes time.

Purchased components are easier, but sometimes big changes happen there too. Upgrading could mean different components, different licensing, and in the worst case scenario serious incompatibilites. The big lesson learned here is to always, always buy with source code included: that means you can hack the components yourselves and add all those little {$IFDEF VER170} that Delphi 2005 sorely needs.

In one case, we even settled on a rather unconventional solution: Instead of upgrading, we chose to completely reimplement a purchased library with a "fake" version, exactly mimicking the original API (even identical .bpl files), but writing our own components instead. It takes time, but with no other solution available, sometimes it's worth it. In this case, a TCP/IP component library that we reimplemented by using WinSock directly, with good measure.

Still, faced with a major deadline, we've pushed the upgrade off a bit. For now, we're migrating to ZeosDBO 6.1.5, and the rest of Delphi 2005 comes later.

To summarize what we've discovered:
  • Upgrading Delphi itself is seldom difficult. It's extremely backwards-compatible.
  • Upgrading components, however, takes time and effort.
  • If possible, use open source components, and stay with the releases as they update. You don't want to get too far behind. (On the other hand, you want to use stable versions too. It's a fine line.)
  • If you purchase components, always buy the source included. If you can't get source code with it, consider an alternative.
  • Try to depend on fewer, but larger, component packages. It's easier to replace a big package than twenty small ones.
In maintaining the package libraries, we've developed a small program which automatically rebuilds and installs multiple packages with a single mouse clicks (okay, maybe a couple of mouse clicks). It allows us to keep all our components in a central VSS repository and switch between packages and Delphi versions pretty seamlessly. But that would probably be a topic for another post.


Post a Comment

<< Home


Blog contents copyright © 2005 Mats Gefvert. All rights reserved.