Re: How to check runtime DLL version

[Tor Lillqvist <tml iki fi>]

> I'm wondering how to check the runtime version of the (glib and gtk for
> example) DLLs, that the application is linking to.

You mean check at run-time? Using the API provided for that, if any.
For GLib, use the glib_major_version, glib_minor_version and
glib_micro_version variables (which are exported from the DLL). For
GTK+, correspondingly gtk_major_version, gtk_minor_version and
gtk_micro_version. For Pango, use the function pango_version() and
then split it up into major, minor and micro version numbers using the
expressions pango_version()/100/100, pango_version()/100%100 and
pango_version()%100.

Or do you mean check before running? Then your are on the wrong track.
There is nothing in the Windows executable format that would say what
*version* of a DLL an executable (an EXE or DLL) links to. Just the
DLL name is specified.

> I know one can check the version of included headers and statically linked
> libraries using GLIB_MAJOR_VERSION and glib_major_version, but the dynamic
> linking is giving me trouble.

glib_major_version etc works fine also for DLLs, as long as you just
include the appropriate headers that declares the variable correcly as
dllimport. If you just write "extern int glib_,major_version:" in your
code and don't use the GLib headers, you might (depending on compiler)
actually access the so-called import stub linked in from the import
library, not the real exported variable in the DLL. (Although with a
current mingw toolchain, it seems to work fine also to leave out the
dllimport declaration.)  (Complications like this is one reason why
having variables (as opposed to functions) in a library API is not
recommended.)

> Or maybe the only way is to actually place the required DLLs in the
> application directory (the workaround I'm now using)?

For applications installed by an installer on end-user systems, that
is indeed the recommended way. Attempts to share GTK+ stack
installations between unrelated applications developed and distributed
by unrelated parties is not a good idea on Windows (or Mac OS X for
that matter). In an ideal world, sure, it would be the right thing,
but this isn't an ideal world.

For a development system, you just need to know what you are doing and
keep track yourself of what you have where and what your PATH is in
any shell or other process... Not really that different from doing
development on a Linux system with several versions of some shared
libraries installed and manipulating LD_LIBRARY_PATH to test against
them.

> If so, then how do I know which files are actually required?

You mean *required*, or *used*? For all DLLs in the GTK+ stack, the
overall rule is simple: the DLL version required is the one compiled
against, or newer. if the DLL name is the same, the DLLs are backward
compatible. I.e. you can run against a newer version even if the code
has been compiled against an older version. Of course, occasional
regressions in some corner cases make matters more complicated: it
might be that some software works better with an explicit old version
than with newer ones.

To know which DLLs are used at run-time, familiarize yourself with the
rules for DLL lookup. Read
http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx .
Especially note that the system and Windows directories are searched
before the directories in PATH. That's why one should never, ever,
install 3rd-party DLLs in these directories (typically
\windows\system32, \windows).

--tml