Overview of Module Version Numbers
There are four version fields that every Windows module is guaranteed to have. They are all two-part version numbers (#.#). They include:
|
|
Image Version |
This value is set by the developer of the module by using the VERSION statement in their DEF file or by using the /VERSION linker option. It usually represents the version of the module or product that the module is part of, but can contain any value since it is up to the developer to set it. If the developer does not specify a version, then this value will default to 0.0. This value may be used as a last resort when comparing two modules to check which module is newer. |
|
OS Version |
This value represents which version of the operating system the module was designed to run on. Certain functions may behave differently depending on this value in order to remain compatible with applications built for a particular operating system version.
|
|
Subsystem Version |
This value represents which subsystem version the module was designed to run on. Most modules use the default value, but developers can override the default by using the /SUBSYSTEM linker option if they wish to target a particular subsystem version other than the default. Certain subsystem functions may behave differently depending on this value in order to remain compatible with applications built for a particular subsystem version. |
|
Linker Version |
This value represents the version of the linker that was used to build the module. It can be used to determine if a specific linker feature was available at the time the module was built. For example, delay-load dependencies is a new feature introduced with version 6.0 of the linker, so if this value is less than 6.0, the module shouldn't have any delay-load dependencies. |
|
In addition to the four standard version values, developers can add four more optional version values by including a VERSION_INFO resource as part of their resource file. This resource structure has two four-part numeric fields (#.#.#.#) and two text fields. They include:
|
|
File Version Value |
This field is known as the "FILEVERSION" field in the VERSION_INFO resource structure. This numerical value usually represents the version of the module itself, but can contain any value since it is up to the developer to set it. This is the value that most programs use when comparing two modules to check which module is newer. |
|
Product Version Value |
This field is known as the "PRODUCTVERSION" field in the VERSION_INFO resource structure. This numerical value usually represents the version of the product that this module is part of, but can contain any value since it is up to the developer to set it. For example, "Acme Tools version 3.0" is a set of ten utilities, including "Acme Virus Checker version 1.5". The virus checker executable might have a file version of 1.5.0.0 and a product version of 3.0.0.0 |
|
File Version Text |
This field is known as the "FileVersion" field in the VERSION_INFO resource structure. This text string usually represents the version of the module itself, but can contain any text string since it is up to the developer to set it. |
|
Product Version Text |
This field is known as the "ProductVersion" field in the VERSION_INFO resource structure. This text string usually represents the version of the product that this module is part of, but can contain any text string since it is up to the developer to set it. |
|
Dependency Walker shows the true FILEVERSION and PRODUCTVERSION version values and not the text string versions. Other applications, like the Windows Properties dialog, show the text string values since that is what the developer of the module wants the average non-technical user to see. For example, you may see only "2.0" in the Windows Properties dialog for a module when its real version is 2.0.5.2034. If you want to know the true version of a file, you should use Dependency Walker and not the Windows Properties dialog.
A great web site for looking up version numbers of modules is the Microsoft DLL Help Database (http://support.microsoft.com/servicedesks/FileVersion/dllinfo.asp). This site has detailed version histories of DLLs and lists what products were shipped with each version. This database can be helpful in tracking down version problems.