Migrating Delphi versions with DevExpress

I usually run on the latest version of Delphi while the other Delphi developers in our department run a version or two back.  I’m the pretty much the sole Delphi developer on our .NET projects and I switch between VS 2008 and Delphi 2007 as needed.  The core Delphi team is on Delphi 2006 because of how our product development and testing cycles work.  We don’t switch compiler versions without coordinating with our QA department.

The core team is moving up to Delphi 2007 later this year for the next release cycle.  The current version of the product will stay in Delphi 2006 and the versions of the 3rd party components will be locked.  While development on the next release goes on, we may need to release updates to the current version.  So we lock the 3rd party components so that QA only needs to test the code specific to the update, plus general regression across the application.

With some component vendors, this makes upgrading more challenging.  We use the Developer Express components for Delphi Win32 and for .NET.  DevExpress has wonderful components, but they use monolithic installers that install everything for each compiler per platform.  If I install the latest version of the DevExpress components for Delphi 2007, I’m also going to get the latest version for Delphi 2006.  You can’t install them separately, not without seriously confusing their installer.  Installer technology is scary enough, the last thing you want to is mess areound with the installer.  I wanted something robust, hand tweaking my system to manipulate the installer would be to fragile to have an entire team try it.

After a few emails with DevExpress support, I came with another method.  I wrote a Delphi app that would manually downgrade a DevExpress install for a specific compiler.  You would run this app after running the DevExpress installer and it would rip out the DevExpress current installed bits and replace them with a cached copy of the version that we need to stay at.  It does the following steps:

  1. Check to see if Delphi 2006 is running and stop with a warning message if it’s running.  Here’s how to check to see if Delphi 2006 is running:
    function IsDephi2006Running: boolean;
    var
    handler: THandle;
    data: TProcessEntry32;
    Delphi2006IsRunning: boolean;
    function GetName: string;
    var
    i: byte;
    s: string;
    begin
    result := '';
    i := 0;
    while data.szExeFile[i] <> '' do begin
    result := result + data.szExeFile[i];

    if uppercase(result) = 'BDS.EXE' then begin
    s := uppercase(ProcessFileName(data.th32ProcessID));

    Delphi2006IsRunning := pos('BDS\4.0\BIN\BDS.EXE', s) > 0;
    end;
    inc(i);
    end;
    end;
    begin
    Delphi2006IsRunning := false;
    handler := CreateToolhelp32Snapshot(TH32CS_SNAPALL, 0);

    if Process32First(handler, data) then begin
    GetName();
    while Process32Next(handler, data) do begin
    if Delphi2006IsRunning then
    break;
    GetName();
    end;
    end;

    result := Delphi2006IsRunning;
    end;

  2. See if the Package Cache key, HKEY_CURRENT_USER\Software\Borland\BDS\4.0\Package Cache, exists in the registry.  If it does rename it.
  3. Deregister the DevExpress components from the IDE. 
    In Delphi 2006, the component packages are registered in HKEY_CURRENT_USER\Software\Borland\BDS\4.0\Known Packages.  The rollback program has a list of list of every DevExpress 5 and 6 package.  My code rips them all out. Before they are removed, their location is cached as this is the folder where the compiled library files are located.  For Delphi 2006, this defaults to “C:\Program Files\Developer Express.VCL\Library\Delphi10”.
  4. Using the location the library folder for the DevExpress compiled units, we delete all of the files in that folder.  If you want to be extra cautious, you could just rename that folder and create a new one with the original name.
  5. Copy the cached copy of the rollback version of the DevExpress compiled units to the library folder.  I keep a clean copy of the library folder in a protected location on our network.  If you need to rollback your DevExpress components, you’ll want to cache those fiels before doing anything else.  You will also need to cache the list of packages to install.
  6. Register the rollback packages into the Known Packages key used in step 3.
  7. Copy the runtime packages to the bin folder.  You can get the location of the bin folder by reading the value of RootDir in HKEY_CURRENT_USER\Software\Borland\BDS\4.0.  I keep a cached set of the runtime packages in the same folder that I keep the cached library files.

This process goes on the assumption that the DevExpress source code is not your Delphi search paths.  We typically leave the source code of the 3rd party components off the search path and just use the compiled units.  You get a faster compile and you don’t have to see other vendors compiler hint and warning messages.  If you want the source code on the search path, the you will need to cache all of the source code files.  At that point, it would be easier to cache the entire “\Program Files\Developer Express.VCL” folder.  And that’s how we upgrade selcted portions of our development environment.

Proof by lack of evidence

CNET’s Matt Asay wrote an article for CNET’s News.com that was just so bad, it gets the “Epic Failtag.  You can get the gist of how bad it is by the first few lines:

Vista’s big problem: 92 percent of developers ignoring it

And to think Microsoft used to be popular with the developer crowd…

Not anymore. A recent report from Evans Data shows fewer than one in 10 software developers writing applications for Windows Vista this year. Eight percent. This is perhaps made even worse by the corresponding data that shows 49 percent of developers writing applications for Windows XP.

Wow, I’m not sure where to start on this one.  I started by visiting the Evans Data web site that Asay refered via this link.  It was vague and provide no actual metrics.  How that “one in 10” number was arrived that was never specified.  Sounds pretty bogus to me.

What they did say was this:

Only eight percent of North American software developers are currently writing applications to run on Microsoft’s Vista operating system, while half are still writing programs for XP, according to Evans Data’s Spring 2008, North American Development Survey. These same developers forecast a fragmented Windows market in 2009 with only 24 percent expecting to target Vista and 29% expecting to continue with XP.

8% of what?  Is that 8% of all developers writing for the Windows Desktop or is 8% of all North American software developers.  The former is a subset of the latter.  Did they exclude web developers from that count?

The other question is what do they mean by writing for Vista?  Does that mean writing for features specific to the Vista platform or does it mean writing the code so that it behaves under Vista?  Did they break that out by managed code as compared to unmanaged code?  If you are writing managed code like for the .NET Framework or Java, then you are not targeting an OS, you target the managed code framework.

Since Matt conveniently left out any actual numbers, I can use myself as a sample set.  A sample size of 1 is just as relevant and/or meaningless as an undefined sample size. I write shrink-wrapped applications for the Windows desktop market.  I do both Win32 coding (with Delphi 2007) and for the .NET Framework (with Visual Studio 2008).  All of my code is tested on XP, Vista, Server 2003, and Server 2008. 

With the .NET Framework, I have no code that is OS specific and I didn’t have to change any of it for Vista or Server 2008.  For the Delphi code, some minor changes were made to account for the location of the local application data folder.  That was all we had to do.  It’s something like 5 lines of Delphi code out 500,000+.  Of course by using Delphi 2007, we get the benefit of the Delphi VCL being Vista aware.  We get the Aero Glass effects and the new UI for dialogs without any code changes.

Does that mean we are not targeting Vista?  No, it just means for our applications, that Windows XP and every OS that comes after it is tested and supported.  That leads back to the critical failure point of Matt Asay’s article.  He’s making broad assumptions based on no evidence.  I’m reminded of that old quote by Leonard H. Courtney, “There are three kinds of lies: lies, damned lies, and statistics.”

I don’t usually read news.com anymore, in fact I came across Matt Asay’s article in a blog post by Steve Trefethen.  So I’m not familiar with Matt Asay’s body of work.  I don’t know if he wrote this out of ignorance out or as Steve put it: “written for no other reason than to generate traffic for c|net.”  I would like to know how much actual research Matt performed for his article.

The title of this post comes from the “You Are Wrong Because” portion of Scott Adams book, “The Joy of Work: Dilbert’s Guide to Finding Happiness at the Expense of Your Co-Workers”.  The context was that Adams has stated that irrational people are easily persuaded by anything that has been published.  I think that’s applicable with with Matt Asay’s article.

{updated on 6/23/08]
I removed the link to Matt Asay’s article because I didn’t want to give him any more traffic.  It’s not that there would be a lot coming from my blog, it’s more of a principle thing.  I had originally included a link so that people could make up their own mind, but I think I have enough of his article to make my point.  And if you really want to read it, you know where to find it.