Skip to main content
Email Password   helpLost your password?

Sample Image - UpdateVersion.jpg

Introduction

The question "How can I update the version information in my file?" usually yields a handful of solutions. Everyone has their favorite. Some are generic, while others are specific to a particular environment. This type of problem is one of the reasons that the "There's more than one way to skin a cat" idiom exists.

Back when I was still using the 16-bit compiler (v1.52c), the solution I put in place required the version information structure in the .rc file to be modified to look something like:

#include "version.h"

VS_VERSION_INFO VERSIONINFO
 FILEVERSION _FILEVERSION_
 PRODUCTVERSION _PRODUCTVERSION_
 ...

The version.h file contained a whole slew of #define directives, a pair for each module. I then put together a little utility that ran during the automated build process that would open the version.h file, find the right #define directives, and increment them accordingly. This solution worked well, with little to no user interaction. For some reason, when our development team moved to the 32-bit compiler, version numbers, or at least the auto-incrementing of them, moved to the back burner. It wasn't that they were any less important, but was because we only had a small handful of 32-bit modules and it was more efficient to change the version numbers manually than to re-tool the utility to work with the 32-bit compiler's way of processing the .rc file. Maybe the .rc2 file could have been used. I give VB a thumbs-up for having this functionality in its IDE.

When the question is coupled with "at runtime rather than compile time", the solution becomes a tad more complicated. Such a question came across my viewport the other day.

You've no doubt used the suite of version-related functions to retrieve file version, description, copyright, platform, etc. from a file. Most have even seen the handy class, CModuleVersion, put together by Paul DiLascia back in 1998 to read from both new and old files. Knowing that the VERSIONINFO resource was stored in a file in an easy-to-retrieve location (we can use GetFileVersionInfo() for this or go Matt Pietrek's way (an up-to-date article is here) and navigate the PE file structure manually!), it only makes sense that it should be easy to update. The remainder of this article is my attempt at just that.

Implementation

The first thing we need to do is get a pointer to the start of the version information block. This is done with:

LPCTSTR lpszFilename = _T("c:\\winnt\\system32\\atl.dll");
DWORD   dwHandle,
        dwSize;

// determine the size of the resource information

dwSize = GetFileVersionInfoSize(lpszFile, &dwHandle);
if (0 < dwSize)
{
    LPBYTE lpBuffer = new BYTE[dwSize];

    GetFileVersionInfo(lpszFile, 0, dwSize, lpBuffer);
    ...
    delete [] lpBuffer;
}

At this point, lpBuffer now points to the start of the version information block, a VS_VERSIONINFO structure actually. In my example, that address is 0x007b25a8. From dwSize, I know that the block is 1700 bytes in size. From my tests, it seems that the compiler allocates more room for the version information block than is actually consumed by the data. Maybe, this is for performance reasons, or to ensure that boundaries are aligned following the version information block. It may also be that GetFileVersionInfoSize() is just overly cautious!

This image shows some of the version information block. What's outlined in red is the data that will be updated.

Sample screenshot

Next, we get to do a little pointer arithmetic. You'll note that the VS_VERSIONINFO structure contains a VS_FIXEDFILEINFO member structure. No big deal except that it follows a variable-length member and some padding bytes. The number of characters in the szKey member of VS_VERSIONINFO rounded to the nearest 4-byte boundary is where the VS_FIXEDFILEINFO member actually starts. So, if the szKey member contained 15 characters (usually "VS_VERSION_INFO"), plus 1 for the NULL character, the number of bytes offset from the beginning of the version information block would be calculated as:

// 'point to' the start of the version information block

VS_VERSIONINFO *pVerInfo = (VS_VERSIONINFO *) lpBuffer;

// the fixed section starts right after the 'VS_VERSION_INFO' string

LPBYTE pOffsetBytes = (BYTE *) &pVerInfo->szKey[_tcslen(pVerInfo->szKey) + 1];

VS_FIXEDFILEINFO *pFixedInfo = 
    (VS_FIXEDFILEINFO *) roundpos(pVerInfo, pOffsetBytes, 4);

After rounding to the nearest 4-byte boundary, we get 28. So, pFixedInfo starts 28 bytes after the beginning of the version information block, or address 0x007b25d0. roundpos() is a macro that handles the rounding. In this case, it uses a 4-byte boundary. Consult the source code for the actual implementation.

We're now ready to increment the version-related members of the VS_FIXEDFILEINFO structure. Just for demonstration purposes, I incremented each word by one using:

pFixedInfo->dwFileVersionMS    = pFixedInfo->dwFileVersionMS + 0x00010001;
pFixedInfo->dwFileVersionLS    = pFixedInfo->dwFileVersionLS + 0x00010001;
pFixedInfo->dwProductVersionMS = pFixedInfo->dwProductVersionMS + 0x00010001;
pFixedInfo->dwProductVersionLS = pFixedInfo->dwProductVersionLS + 0x00010001;

This was so I could tell that everything was working when I viewed the "before" and "after" files (see the pictures at the top of this article). At this point, we have an in-memory snapshot of an updated version information block. It's time to commit it to disk. Using the resource-related functions, we have:

HANDLE hResource = BeginUpdateResource(lpszFile, FALSE);
if (NULL != hResource)
{
    UINT uTemp;

    // get the language information

    if (VerQueryValue(lpBuffer,
                      _T("\\VarFileInfo\\Translation"),
                      (LPVOID *) &lpTranslate,
                      &uTemp) != FALSE)
    {
        // could probably just use LANG_NEUTRAL/SUBLANG_NEUTRAL

        if (UpdateResource(hResource,
                           RT_VERSION,
                           MAKEINTRESOURCE(VS_VERSION_INFO),
                           lpTranslate->wLanguage,
                           lpBuffer,
                           dwSize) != FALSE)
        {
            EndUpdateResource(hResource, FALSE);
        }
    }
}

Note the comment about using LANG_NEUTRAL/SUBLANG_NEUTRAL as the fourth parameter to UpdateResource(). The section of the version information block that we updated was independent of language and code page, so we could probably get away without having to call VerQueryValue() to get the translation array.

At this point, the file's version information has been updated. However, there remains but one problem. Can you spot it? The corresponding version numbers in the file's .rc file remains unchanged. The next time the file is built, the previous numbers will be used. I guess that's one reason for updating the .rc file rather than the compiled file.

Updating the StringFileInfo section

The above code snippets focused on the VS_FIXEDFILEINFO section of the file. This is somewhat easier to do because the information contained within it is, well, fixed. The information contained in the StringFileInfo section is not necessarily more difficult to change, but it does have the constraint that the new information be the same size or smaller than the old information. In other words, if I wanted to change the string "Copyright 2004" with an updated string of "Copyright 2004-05" the results would not be pretty since the string is three characters longer. Those extra characters would inevitably write on something important.

The first thing we need to do is get a pointer to one of the sub-blocks in the StringFileInfo section. We do this using VerQueryValue() like:

CString strSubBlock;
LPTSTR  pValueBuffer;

strSubBlock.Format(_T("\\StringFileInfo\\%04x%04x\\CompanyName"),
                   lpTranslate->wLanguage, 
                   lpTranslate->wCodePage);

VerQueryValue(lpBuffer, (LPTSTR) ((LPCTSTR) strSubBlock), 
           (LPVOID *) &pValueBuffer, &uTemp);

At this point, the variable pValueBuffer is pointing to the CompanyName key. Whatever change I make to this value must be the same length or smaller and end with a '\0' character. So you can either right-pad the new string with '\0' characters or zero the whole string out and then update it. For the latter, I used:

ZeroMemory(pValueBuffer, _tcslen(pValueBuffer) * sizeof(TCHAR));
_tcscpy(pValueBuffer, _T("My Company, Inc."));

You can watch this transition if you have the Memory window open in the IDE. At this point, BeginUpdateResource(), UpdateResource(), and EndUpdateResource() can be called as shown above.

Notes

Two of the language-specific strings that relates to this are FileVersion and ProductVersion. They're contained in the Children member of the StringTable structure and are dependent on language and code page. The updating of those is left as an exercise for the reader, or the author if time and interest permits.

References

Thanks goes out to Ted Peck for supplying the two macros I used in this sample.

Enjoy!

You must Sign In to use this message board.
 
 
Per page   
 FirstPrevNext
GeneralHi, why didn't U using following code to get pFixedInfo? Pin
Icepool		17:44 23 Sep '09  
GeneralRe: Hi, why didn't U using following code to get pFixedInfo? Pin
DavidCrow		3:51 24 Sep '09  
GeneralRe: Hi, why didn't U using following code to get pFixedInfo? Pin
Icepool		16:04 24 Sep '09  
QuestionRe: Hi, why didn't U using following code to get pFixedInfo? Pin
DavidCrow		16:40 24 Sep '09  
GeneralRe: Hi, why didn't U using following code to get pFixedInfo? Pin
Icepool		17:29 24 Sep '09  
GeneralResourceLib: same functionality that supports adding/removing/editing version and string resources Pin
dB.		13:22 8 Oct '08  
General64 bit version Pin
umeca74		22:16 26 Sep '08  
GeneralIt doesn't work when the file is ocx or arx format? Pin
malj		23:03 9 Sep '08  
QuestionRe: It doesn't work when the file is ocx or arx format? Pin
DavidCrow		5:19 10 Sep '08  
AnswerRe: It doesn't work when the file is ocx or arx format? Pin
malj		0:29 11 Sep '08  
GeneralUpdate of StringFileInfo entry doesn't work. Can you help ? Pin
cherbuliez		7:27 21 Sep '07  
QuestionRe: Update of StringFileInfo entry doesn't work. Can you help ? Pin
DavidCrow		8:30 21 Sep '07  
QuestionRe: Update of StringFileInfo entry doesn't work. Can you help ? Pin
cherbuliez		0:57 24 Sep '07  
QuestionRe: Update of StringFileInfo entry doesn't work. Can you help ? Pin
DavidCrow		3:57 24 Sep '07  
GeneralRe: Update of StringFileInfo entry doesn't work. Can you help ? Pin
BhawnaA		2:58 26 Sep '07  
GeneralRe: Update of StringFileInfo entry doesn't work. Can you help ? Pin
cherbuliez		6:26 26 Sep '07  
QuestionIs it possible to have more information Blocks (Not language) ? Pin
zmau		10:14 19 Jun '07  
AnswerRe: Is it possible to have more information Blocks (Not language) ? Pin
DavidCrow		3:22 20 Jun '07  
GeneralRe: Is it possible to have more information Blocks (Not language) ? Pin
zmau		4:35 22 Jun '07  
QuestionRe: Is it possible to have more information Blocks (Not language) ? Pin
DavidCrow		4:43 22 Jun '07  
AnswerRe: Is it possible to have more information Blocks (Not language) ? Pin
zmau		4:58 22 Jun '07  
GeneralRe: Is it possible to have more information Blocks (Not language) ? Pin
DavidCrow		7:08 22 Jun '07  
GeneralRe: Is it possible to have more information Blocks (Not language) ? Pin
zmau		7:28 22 Jun '07  
GeneralRe: Is it possible to have more information Blocks (Not language) ? Pin
DavidCrow		9:17 22 Jun '07  
GeneralAdd FileVersion to exe at runtime. Pin
JohnnyH!		6:17 13 Dec '06  
Last Visit: 23:41 21 Nov '09     Last Update: 23:41 21 Nov '09 1234 Next »


Last Updated 15 Jul 2005 | Advertise | Privacy | Terms of Use | Copyright © CodeProject, 1999-2009