这与另一个Delphi版本问题相关，但仍然不同；
我正在寻找一种方法来检测正在编译我的代码的 Delphi 编译器的服务包（或内部版本号）。 jedi.inc 很好，但它没有告诉我确切的版本。 （我也不能使用其中的 SUPPORTS_* 定义，因为它们也与版本相关）
我需要这个，因为旧版本中存在一些错误（在这种情况下，它是 _Delphi 2009 中的_ValLong bug）已在更高版本的服务包（本例中为 Delphi 2009 Service Pack 3）中修复）。
目前我的代码中有各种检查，如下所示：
{$IFDEF BUG_QC_68123}
但我不能只在我的主包含文件中这么说：
{$IFDEF DELPHI2009_UP}
{$DEFINE BUG_QC_68123}
{$ENDIF}
...因为这会忽略 D2009SP3 及更高版本不再有此错误的事实。
有任何想法吗？
PS：这可能也适用于较旧（和较新）版本的 Delphi，因此我认为任何库和/或组件供应商也会对此感兴趣。
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.
发布评论
评论（4）
每个版本都定义了符号：
来源
另一个来源
您无法检查不同的内部版本号。
对于好奇的人来说，VER10-VER70 是 Turbo Pascal 版本，而 VER110 是 C++ 构建器版本。
There are symbols defined for each version:
Source
Another 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.
不幸的是，像 System.pas 中的 RTLVersion 这样的常量不会在更新中更新，但我认为如果有人想为其创建 QC 条目，这将是一个很好的建议。
如果您正在测试的错误可以在代码中重现，您始终可以在启动时测试它们并设置您自己的全局标志。
我通过确保我们始终应用最新更新来解决这些差异。 我还没有遇到过更新不稳定并迫使我回滚的情况。 至少德尔福不是这样。
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.
您可以尝试在软件中包含编译器文件版本。 例如，DCC32.exe 有一个文件版本，您可以通过编程方式获取该版本，然后将其作为常量写入单元。 这可以作为构建过程的一部分来完成，以便它在构建应用程序之前获取版本信息（使用 FinalBuilder）。
我已经为其他事情这样做了，以便在我们的“关于”屏幕上我们可以获得各种有用的信息。 此外，当我们的应用程序出现错误时，我们可以将此信息捆绑到我们的 EurekaLog 错误报告中。
但是我不知道 DCC32.exe 上的文件版本是否会随着每次 Delphi 更新而更新。
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.
编译器不会公开该信息。 它仅告诉您主要版本，应用更新时不会更改。
我认为你能做的最好的事情就是始终为最新更新编写代码。 假设您的代码的使用者也将获得最新的更新。 如果他们不这样做，那就是他们自己的错，而不是您需要担心的问题。 在您的系统要求中提及它。 当然，您的代码不适用于他们，但其他人也不会，因为他们仍在使用已知的错误代码。
下一个最佳替代方案是假设没有已应用更新。 也就是说，编写代码时就好像所有已知错误仍然存在一样。 缺点是您的代码可能无法正常运行，因此每个通过升级做了正确事情的人都会因继续使用次优代码而受到惩罚。
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.