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?
VarFileInfo\\Translation
value is often wrong (e.g. it will indicate German but theStringFileInfo
table is only in English). In our code we try first of all for the user's default language (GetUserDefaultLangID()
) followed by theTranslation
value, and failing both of those we loop through several variants of US-English (1200, 1252, 437) as a fallback. – Jonathan Potter\Translation
value first, in case it actually exists, and then fall back toGetUserDefaultLangID()
? 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 Lebeaulibvlc.dll
and do see the codepage mismatch in it, as well as inaxvlc.dll
andlibvlccore.dll
. I have reported the bug to VideoLAN. – Remy Lebeau