views:

407

answers:

4

This is related to another Delphi-version question but still different;

I'm looking for a way to detect the service-pack (or build number) of the Delphi compiler that's compiling my code. The jedi.inc is nice, but it doesn't tell me the exact version. (I can't use the SUPPORTS_* defines in there either, as those are version-related too)

I need this, because some bugs are present in older versions (in this case, it's a _ValLong bug in Delphi 2009) that's fixed in a later service-pack (Delphi 2009 service pack 3 in this case).

Currently I have all kinds of checks in my code, like this :

{$IFDEF BUG_QC_68123}

But I can't just say this in my main include file :

{$IFDEF DELPHI2009_UP}
  {$DEFINE BUG_QC_68123}
{$ENDIF}

...As this would miss the fact that D2009SP3 and later don't have this bug anymore.

Any ideas?

PS: This will probably also apply to older (and newer) versions of Delphi, so any library- and/or component-vendor will have an interest in this too, I presume.

+3  A: 

Unfortunately, constants like RTLVersion in System.pas aren't updated in updates, but I think it would be a good suggestion if someone wants to make a QC entry for it.

If the bugs you are testing for are practical to reproduce in code, you could always test for them on startup and set your own global flags.

I get around these differences by making sure we always apply the latest updates. I haven't run in to a case yet where an update was unstable and forced me to roll it back. At least not with Delphi.

Bruce McGee
+4  A: 

There are symbols defined for each version:

VER80 - Delphi 1
VER90 - Delphi 2
VER100 - Delphi 3
VER120 - Delphi 4
VER130 - Delphi 5
VER140 - Delphi 6
VER150 - Delphi 7
VER160 - Delphi 8
VER170 - Delphi 2005
VER180 - Delphi 2006
VER180 - Delphi 2007
VER185 - Delphi 2007 (Note: symbol VER185, for example, is used to indicate Delphi 2007 compiler or an earlier version.)
WIN32 - Indicates that the operating environment is the Win32 API.
LINUX - Indicates that the operating environment is Linux
MSWINDOWS - Indicates that the operating environment is the MS Windows/li] 
CONSOLE - Indicates that an application is being compiled as a console application

Source

You can't check for different build numbers.

And for the curious, VER10-VER70 where the turbo pascal versions, and VER110 was a C++ builder version.

Gamecat
VER190 = Delphi.NET 2007. VER200 = Delphi 2009. CIL = Delphi.NET
Remy Lebeau - TeamB
+1  A: 

The compiler does not expose that information. It only tells you the major version, which doesn't change when updates are applied.

I think the best you can do is to always write code for the latest update. Assume that consumers of your code will also have the latest update. If they don't, then it's their own fault, and not a problem you need to worry about. Mention it in your system requirements. Sure, your code won't work for them, but neither will anyone else's because they're still using known-bad code.

The next-best alternative is to write assuming that no updates have been applied. That is, write your code as though all known bugs are still present. The downside is that your code probably won't run as well as it otherwise could, so everyone who did the right thing by upgrading gets punished by continuing to have your suboptimal code.

Rob Kennedy
+1  A: 

You could try including the compiler file version in your software. For example, DCC32.exe has a file version on it which you can programmatically get at and then write to a unit as a const. This could be done as part of your build process so it gets the version info before building your app (it'd be very easy to do with something like FinalBuilder).

I've done this for other things so that on our About screen we can get various bits of useful info. Also when we have an error in one our applications, we can bundle this info into our EurekaLog bug reports.

However I don't know if the file version on DCC32.exe is updated with every Delphi update.

Pauk