GetFileVersionInfoSize failing?

[Dan Mitchell]

We have a unicode app (working just fine with unicows) that needs to
check the version of one of our DLLs. The DLL is non-unicode, and works
fine if we load it and call our functions on it. (though none of those
functions pass strings as parameters).

The problem is that if we call GetFileVersionInfoSize() on that DLL, we
get an error back and GetLastError() returns 120 ("the function is not
supported").

It works fine on WinXP etc, so it seems to be just something about
unicode. (and it didn't do this before we switched our main app to
unicode).

Is there anything we can do about this? If I try guessing that 64k should
be enough as a safe fake return from GetFileVersionInfoSize(), the call to
GetFileVersionInfo() fails the same way (getlasterror=120), and I don't
think I can usefully spoof the call to that.

thanks,

-- dan

[David Lowndes]

Post by Dan Mitchell
We have a unicode app (working just fine with unicows) that needs to
check the version of one of our DLLs. The DLL is non-unicode, and works
fine if we load it and call our functions on it. (though none of those
functions pass strings as parameters).
The problem is that if we call GetFileVersionInfoSize() on that DLL, we
get an error back and GetLastError() returns 120 ("the function is not
supported").

Dan,

Does the code work for other DLLs - or even on the exe itself?

I've used GetFileVersionInfoSize in a application that uses Unicows
and I'm not aware of any problems with it.

Does it work if you call GetFileVersionInfoSizeA directly?

Dave

[Dan Mitchell]

Post by David Lowndes
I've used GetFileVersionInfoSize in a application that uses Unicows
and I'm not aware of any problems with it.
Does it work if you call GetFileVersionInfoSizeA directly?

That does the trick. I'm not sure what was going on, but calling
GetFileVersionInfoSizeA,GetFileVersionInfoA,VerQueryValueA sorts things
out.

I suppose I should fall back to those only if I get problems from the
wrapped calls, but that's easy enough to put in.

thanks!

-- dan

[David Lowndes]

Post by Dan Mitchell

Post by David Lowndes
I've used GetFileVersionInfoSize in a application that uses Unicows
and I'm not aware of any problems with it.
Does it work if you call GetFileVersionInfoSizeA directly?

That does the trick. I'm not sure what was going on, but calling
GetFileVersionInfoSizeA,GetFileVersionInfoA,VerQueryValueA sorts things
out.

Hmm, I wonder what's going on in your circumstance with the Unicows
wrapped version though?

Which version of Unicows.dll are you using?

Dave

[Dan Mitchell]

Post by David Lowndes
Hmm, I wonder what's going on in your circumstance with the Unicows
wrapped version though?

Yeah, I'm not really sure what's up there. It happens with all DLLs, not
just that particular one; unfortunately, we can't make that DLL unicode
because it's a windows hook DLL and when I tried unicode-ing it, Win98's
kernel32.dll blew up somehow. Another option would be to provide our own
GetVersion() function and see if we can LoadLibrary/GetProcAddress that in
from DLLs, but that's pretty ugly.

Post by David Lowndes
Which version of Unicows.dll are you using?

Version 1.1.3790.0. (not sure if that's the newest one or just the one
that we happen to be using right now, sorry. MS signed it on Tuesday,
December 07, 2004 1:28:17 AM, apparently, so it can't be all that old).

-- dan

[David Lowndes]

Post by Dan Mitchell
Version 1.1.3790.0.

That's the same version I've been using too.

I've no idea why it's behaving differently for you. Does anyone else
has any suggestions?

Dave

[Michael (michka) Kaplan [MS]]

The error 120 (ERROR_CALL_NOT_IMPLEMENTED) is what the MSLU loader returns
when it is unable to do the LoadLibrary/GetProcAddress on the function.

Of course the reason for that is that it is the same thing that a Win9x OS
will return if you call its "W" stub.

The most likely cause is improper linking to unicows.dll -- the best way to
check is to do a dumpbin on the imports of the file calling unicows, and see
if GetFileVersionInfoSize is there -- if it is, then that means that the
unicows.dll one is not being called....

See http://blogs.msdn.com/michkap/archive/2005/01/24/359555.aspx for more
info on the MSLU Loaderf....
--
MichKa [Microsoft]
NLS Collation/Locale/Keyboard Technical Lead
Globalization Infrastructure, Fonts, and Tools
Blog: http://blogs.msdn.com/michkap

This posting is provided "AS IS" with
no warranties, and confers no rights.

Post by David Lowndes

Post by Dan Mitchell
Version 1.1.3790.0.

That's the same version I've been using too.
I've no idea why it's behaving differently for you. Does anyone else
has any suggestions?
Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Dan Mitchell]

Post by Michael (michka) Kaplan [MS]
The most likely cause is improper linking to unicows.dll -- the best
way to check is to do a dumpbin on the imports of the file calling
unicows, and see if GetFileVersionInfoSize is there -- if it is, then
that means that the unicows.dll one is not being called....

That's the problem alright. I have no idea what's wrong with it, though
-- the last time I hit this problem it was openssl that was pulling
advapi32.lib in, which was solvable by rebuilding openssl.

I have no idea what's pulling version.lib in this time; it doesn't seem
to be any of our libraries, and I don't think it's openssl. I guess it's
just a matter of poking around until I find where it's coming from.

-- dan