Prev: What could cause ::MessageBox to fail?
Next: afxwin1.inl - Debug Assertion Failed
From: "Yan K. Avlasov" <___ yavlasov at funk dot com on 17 Jun 2005 15:13
I've never tried it...
but you can use FindResourceEx( RT_VERSION ) / LoadResource functions. I
think this will return a version block you can use with VerQueryValue
function.

Good luck.

<tnewton(a)cbnco.com> wrote in message
news:1119024000.729273.128020(a)g44g2000cwa.googlegroups.com...
> Hello,
>
> I want to add a function to my DLL to return its file version:
>
> Is there a way to retrieve the file version from the string table
> *without* calling GetFileVersionInfo()?
>
> or
>
> Is there a way to *set* the file version in the string table using
> another parameter (which I could then retrieve somehow else)?
>
> Thanks in advance,
> Terry
>


From: Joseph M. Newcomer on 17 Jun 2005 15:14
If you have a library, that is, a .lib file, then it cannot have a version number, because
to have a version number requires a VERSIONINFO resource, and resources cannot be stored
in libraries. Since STRINGTABLE is also a resource, you couldn't store it as a resource,
either.

What you would need to do is compile a module

static DWORD MyLibraryVersionNumber = 0x0700;
LIBSPEC DWORD GetMyLibraryVersion() { return MyLibraryVersionNumber; }

for example. Now, to use it, the user would call

DWORD whatversion = GetMyLibraryVersion();

and would get the version number. It then becomes your responsibility to maintain this
variable, and change its value as needed.

Here's how you define LIBSPEC:

if you are compiling a DLL, it will be

#define LIBSPEC __declspec(dllexport)

if you are compiling a static library, LIBSPEC will be

#define LIBSPEC

if you are compiling the client code, you will use

#define LIBSPEC __declspec(dllimport)

See my essay on "The Ultimate DLL Header File" on my MVP Tips site for more details on how
to do this. You will have to enhance my example to allow a static library compilation.
joe

On 17 Jun 2005 11:36:14 -0700, "tnewton(a)cbnco.com" <tnewton(a)cbnco.com> wrote:

>The problem I am trying to solve is how get the version without calling
>GetFileVersionInfo():
>
>I have a library. I want to use the same version number whether the
>library is static or dynamic. Since there's not necessarily a file,
>GetFileVersionInfo() will not work.
>
>Thanks,
>Terry

Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 17 Jun 2005 15:33
See below...
On 17 Jun 2005 10:28:35 -0700, "tnewton(a)cbnco.com" <tnewton(a)cbnco.com> wrote:

>Two reasons (one mock indignant, one goofy):
>
>1.) I don't see why the DLL has to go to the file system, given that
>the file version number and the function are both inside the DLL
>itself.
****
I don't even understand this one. What do you mean "I don't see why the DLL has to go to
the file system" because a DLL by definition IS a file, and consequently IS part of the
file system. Or is this some childish idea of "efficiency" that needs to be unlearned? Why
in the world would this matter in the slightest? (If you think it matters, you need to
re-examine your basic premises about what constitutes good programming). The fact that you
think this is even relevant suggests a serious problem in how you are approaching the
problem.
****
>
>2.) This DLL is sometimes distributed inside a Java wrapper (don't ask
>me why). So, when the function is called from Java, the DLL will no
>longer be a file on the disk. (Excuse me if i'm not using the right
>terms, I'm not much of a Java programmer.)
****
Sorry, you are missing what is going on here. If a DLL exists, it is by definition a file
on the disk. It is not possible to "call" a DLL that is NOT part of a file system. A Java
wrapper is probably using the JNI (Java Native Interface) to pass the call to the DLL.
Consequently, the DLL is part of the file system, orit couldn't be called! I think you
have really misunderstood what a DLL is, or how it works. A Java wrapper is just that: a
wrapper. It is merely a translation interface between the Java environment and some
external environment, such as a DLL. The DLL is still very definitely part of the file
system, no matter how you interface to it. This does not require any understanding of
Java; it only requires understanding that a DLL is by intrinsic definition, a file.

Objection (1) is silly and pointless, and can be ignored. Objeciton (2) is based on a
complete misunderstanding of how Windows works, and can be ignored. Therefore, use
GetFileVersionInfo. I thought when you were referring to a library that you were referring
to a statically-linked library, which is a slightly different problem, but irrelevant to
this discussion.

[I turned around, grabbed my JNI documentation, and on pages 13-16 it shows how to create
the Java wrapper to a DLL. This means the DLL is still a DLL, it is still in the file
system, and your issues therefore make no sense. Just use GetFileVersionInfo. This took
about two minutes to read.]
****
>
>Thanks,
>Terry

Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 18 Jun 2005 00:22
It is a bit more complex than that, and his concern was "going to the file system", which,
guess what, FindResource must do anyway! So his concern is pointless, and shows he is not
thinking clearly about how to solve a trivial problem in a trivial way using a trivial
method, but wants to "improve" on it by somehow bypassing the documented, working
mechanism to implement some ad-hoc mechanism that could break on the next release of the
OS, because of a peculiar idea that "going to the file system" somehow is a Bad Thing.

I always worry about how poorly we are training people when they even consider such issues
worthy of discussion.
joe

On Fri, 17 Jun 2005 15:13:53 -0400, "Yan K. Avlasov" <___ yavlasov at funk dot com ___>
wrote:

>I've never tried it...
>but you can use FindResourceEx( RT_VERSION ) / LoadResource functions. I
>think this will return a version block you can use with VerQueryValue
>function.
>
>Good luck.
>
><tnewton(a)cbnco.com> wrote in message
>news:1119024000.729273.128020(a)g44g2000cwa.googlegroups.com...
>> Hello,
>>
>> I want to add a function to my DLL to return its file version:
>>
>> Is there a way to retrieve the file version from the string table
>> *without* calling GetFileVersionInfo()?
>>
>> or
>>
>> Is there a way to *set* the file version in the string table using
>> another parameter (which I could then retrieve somehow else)?
>>
>> Thanks in advance,
>> Terry
>>
>

Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Mihajlo Cvetanovi? on 20 Jun 2005 11:49
Joseph M. Newcomer wrote:
> It is a bit more complex than that, and his concern was "going to the file system", which,
> guess what, FindResource must do anyway! So his concern is pointless, and shows he is not
> thinking clearly about how to solve a trivial problem in a trivial way using a trivial
> method, but wants to "improve" on it by somehow bypassing the documented, working
> mechanism to implement some ad-hoc mechanism that could break on the next release of the
> OS, because of a peculiar idea that "going to the file system" somehow is a Bad Thing.
>
> I always worry about how poorly we are training people when they even consider such issues
> worthy of discussion.

I think tnewton really stumbled on something here because it *is*
possible to rename currently loaded dll, and place another with the
previous name. In this situation GetFileVersionInfo will return invalid
data (if the old dll is still loaded).

This could be an issue if you want to update dll on the fly, and you
have only restart mechanism available, but not stop/start mechanism. In
this case updating must be done with "rename and copy another" routine.
In all the other cases the "prize" isn't worth the effort.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: What could cause ::MessageBox to fail?
Next: afxwin1.inl - Debug Assertion Failed