0

Looks like I've spent enough time trying to resolve this to ask the community.

I need a reliable way to determine the file's version and trying to use GetFileVersionInfoSize + GetFileVersionInfo for that. In particular, I use dwFileVersionMS and dwFileVersionLS in VS_FIXEDFILEINFO. And with does work for almost all the files on my hard drive except the ucrtbase.dll, which resides both in c:\windows\system32 and c:\windows\syswow64 folders. MSDN states that this part of the file version is not redirected, but I get different behavior. That is, Explorer shows "10.0.18362.387", but the fields in structure from the above WinAPI functions returns "6.2.18362.387". Note, both are not localized strings, but binary values from the VS_FIXEDFILEINFO. When I open the DLL with any binary editor and search for the file version I see that it's correct - 0x00 0x00 0x0A 0x00 0x83 0x01 0xBA 0x47.

Could anyone explain to me what I'm missing here?

OmG
  • 18,337
  • 10
  • 57
  • 90
  • it redirected https://stackoverflow.com/a/38071773/6401656 – RbMm Jun 06 '20 at 06:34
  • so use https://stackoverflow.com/a/38069323/6401656 – RbMm Jun 06 '20 at 06:35
  • Thank you RbMm. AFAIU that's not a redirection, but substitution inside WinApi according to the executable's manifest. I put a manifest file that supports Win10 into my project and now it reports correct version. – Alexei Migoun Jun 08 '20 at 08:53
  • yes, this is manifest based, but i think that this is wrong. assume you write code yet when no win10. or when "win11" will be - current soft wrong detect version if use something manifest based. however until exist way exactly get windows or file version without manifest – RbMm Jun 08 '20 at 09:07
  • @RbMm I agree about that's wrong. Hopefully MS will get rid of this mess one day. Thank you. – Alexei Migoun Jun 08 '20 at 09:55

0 Answers0