Can't read FileVersionInfo with Code Page mismatch

Question

I have some reasonably tried and tested code which uses the Windows API calls to read FileVersionInfo strings, like "FileVersion" and "CompanyName".

I found it failed with one particular 3rd party DLL. The problem seems to be this:

Reading the \VarFileInfo\Translation value, I get 040904B0 (US English, Unicode). But when I then attempt to call VerQueryValue on \StringFileInfo\040904B0\CompanyName, it returns false.

But tweaking the code to use the Windows Latin-1 ANSI codepage works: \StringFileInfo\040904E4\CompanyName.

So, the code page in the string table doesn't match the \VarFileInfo\Translation value.

According to the example resource at the bottom of MSDN's VERSIONINFO resource documentation, this is an appropriate thing to do!

Given this, can I use the published VersionInfo APIs to correctly read the strings for this file, without "guessing" the codepage?

In our experience we've found that the VarFileInfo\\Translation value is often wrong (e.g. it will indicate German but the StringFileInfo table is only in English). In our code we try first of all for the user's default language (GetUserDefaultLangID()) followed by the Translation value, and failing both of those we loop through several variants of US-English (1200, 1252, 437) as a fallback. — Jonathan Potter
@JonathanPotter Thanks. That's the kind of heuristic I was hoping to avoid, but I suspect it's the only way :) — Roddy
@JonathanPotter: why not use the \Translation value first, in case it actually exists, and then fall back to GetUserDefaultLangID()? Why use the user language first and then fall back to the \Translation value? FormatMessage() has some additional fallbacks: "FormatMessage looks for a message for LANGIDs in the following order: 1.Language neutral 2.Thread LANGID, based on the thread's locale value 3.User default LANGID, based on the user's default locale value 4.System default LANGID, based on the system default locale value 5.US English" — Remy Lebeau
@Roddy: XN has an "Export resource" feature. But no matter. I have libvlc.dll and do see the codepage mismatch in it, as well as in axvlc.dll and libvlccore.dll. I have reported the bug to VideoLAN. — Remy Lebeau

theB theB · Accepted Answer · 2016-06-23T00:04:05

Unfortunately the VERSIONINFO structure, when compiled from a resource file, allows you to define languages that don't exist in the string block, and string blocks that have no entry in the language table. In other words, the structure isn't sanity checked. As Jonathan Potter mentions in comments, your best bet when working with an arbitrary library is to use a heuristic search for the string block that best fits your application.

In your case, however, you're using the VLC libraries which currently define their version information as follows: (trimmed so it doesn't take half a page)

BEGIN
  BLOCK "StringFileInfo"
  BEGIN
    BLOCK "040904E4"
    BEGIN
      (...)
    END
  END
  BLOCK "VarFileInfo"
  BEGIN
    VALUE "Translation", 0x409, 1200
  END
END

As you can see the language in the translation block is en-us CP1200 (UTF-16LE), but the string block is tagged en-us CP1252 (ANSI Latin 1). Oddly enough the information for the main executable is correct, and the information is nearly identical.

Remy Lebeau submitted a bug report for the issue, and I've submitted a patch.

As of 24-Jun-2016 the patch has been accepted and backported to the 2.2 maintenance branch.

Can't read FileVersionInfo with Code Page mismatch

1 Answers