VerQueryValue() problem

[Hans Pesata]

Hi!

I created a VC++ 6.0 MFC application which loads a DLL via
AfxLoadLibraray().
afterwards I query the version information of the DLL and I am running into
the problem, that VerQueryValue() fails on some systems and runs OK on
others for the same DLL.
the DLL has the name "Tools.dll"
GetFileVersionInfoSize() and GetFileVersionInfo() are always working fine.
somehow I cant access the version resource on some machines running WINDOWS
2000 SP4,
this is strange and I dont know what to do about it...

any help with this would be greatly appreciated,
thanx in advance!

best regards,
Hans Pesata

 

[John Phillips]

You've neglected to give the most important piece of information - what
happens when you call VerQueryValue()? Do you get an access violation?
Does the return value indicate failure? What does GetLastError() return?
Does the problem occur when retrieving particular values, or any values?

 

[Hans Pesata]

Hi John!

You've neglected to give the most important piece of information - what
happens when you call VerQueryValue()? Do you get an access violation?
Does the return value indicate failure? What does GetLastError() return?
Does the problem occur when retrieving particular values, or any values?

thanx for your reply!

VerQueryValue() just returns 0

according to the MSDN-documentation this means the following:
valid, the return value is zero
MSDN doesnt mention that I could call GetLastError() in case of an error.

it seems that my app cant retrieve any version resource information, I am
tyring to query the following values:

\\StringFileInfo\\040904E4\\ProductVersion
\\StringFileInfo\\040904E4\\PrivateBuild
\\StringFileInfo\\040904E4\\ProductName
\\StringFileInfo\\040904E4\\SpecialBuild
\\StringFileInfo\\040904E4\\OriginalFilename

the strange thing is, that this just happens on some PCs which are running
WINDOWS 2000, I wasnt able to reproduce it.

I would be very thankful for any further suggestions, thanx in advance!

best regards,

Hans

 

[John Phillips]

Is your app hard-coding the language/codepage combo? Shouldn't that be read
from the \VarFileInfo\Translation value?

 

[Hans Pesata]

Hi John!

Is your app hard-coding the language/codepage combo? Shouldn't that be read
from the \VarFileInfo\Translation value?

yes, I hardcode the language/codepage info because I created the dll and
know,
that the language/codepage settings are like this.

the problem seems to be related to another tools.dll which is a part of
WINDOWS 2000

the explorer version info displays the info from a MSWC Tools tools.dll if
you right click our dll.
thie dll seems to have different language/codepage settings and so we are
not able to access
the correct version information.

I am using AfxLoadLibrary() on our dll, but somehow the MS-dll gets
accessed...

do you have any idea on how to make sure OUR dll is accessed ?

best regards,
Hans

 

[John Phillips]

And you've changed the language on the version resource from the default?
Seems as though VC creates the version resource with lang/codepage=040904b0
by default (http://tinyurl.com/3atul). Hard-coding language values always
makes me cringe, and you can imagine why.

At any rate, if the problem is that the wrong DLL is being loaded, then the
solution is to make sure your DLL comes up first in the DLL search
algorithm. Check out the documentation for LoadLibrary() for a description
of the search algorithm.

But just to erase any ambiguity, it's better to rename your DLL to a less
common term than "Tools"

 

[Hans Pesata]

Hi Sten!

And you've changed the language on the version resource from the default?
Seems as though VC creates the version resource with lang/codepage=040904b0
by default (http://tinyurl.com/3atul). Hard-coding language values always
makes me cringe, and you can imagine why.

I changed the version to the appropriate value 040904E4 and there should be
no problem
in hardcoding this, because I access the version information via a exported
DLL-function and the DLL
itself knows about its resources.

I wasnt able to retrive the dll-version-information within my app, if I look
at the
version-information of my DLL via explorer, it displays the version
information of the already
loaded MS Tools.dll ?!?!?!

At any rate, if the problem is that the wrong DLL is being loaded, then the
solution is to make sure your DLL comes up first in the DLL search
algorithm. Check out the documentation for LoadLibrary() for a description
of the search algorithm.
But just to erase any ambiguity, it's better to rename your DLL to a less
common term than "Tools"

this is wired for me, does a DLL-name have to be unique in the system ???
how can I accomplish that, I can never know which DLLs will be within my
system ...
I dont think that I can interfer in how DLLs get loaded, if the MS-Tools.dll
gets loaded at startup
I can never load my DLL ...

I would make sense to me if the whole DLL-path would be used as unique
DLL-name.

best regards,
Hans