Introduction
File Version numbers in Windows consist of four positions with 16 bits each, e.g. 6.0.2600.0 is the version of my iexplore.exe. Typically you use the first two positions as "major.minor" version, based on the features of the module, the third position for an incremental build count, and the fourth for special builds. (You already knew all this, didn't you?)
RCStamp grew out of the necessity to manage a rather complex versioning scheme on a dozen of binaries. It can modify the FILEVERSION entry and the "FileVersion" string entry in a VERSIONINFO resource. It uses a format string that can affect the four positions of the version number individually. A typical call looks like this:
rcstamp myproject.rc *.*.+.*
This would increment the third position, and leave all others unmodified. You get a simple automatic build counter when you integrate this as custom build step into your Visual Studio project.
A more complex call:
rcstamp myproject.rc *.+.0.+1000
would increment the second position (minor version), set the third position to 0, and increment the fourth by 1000.
Command line options:
rcstamp file <format> [<options>...]
rcstamp @file [<format>] [<options>...]
Format options:
| * |
leave position as-is |
| + |
increment position by one |
| n |
set the position to the number n (decimal) |
| +n |
increment position by the number n (decimal) |
| - |
decrement position by one (if you ever need it) |
| -n |
decrement position by the number n (still decimal, and you have been warned) |
Additonal command line options:
| -n |
don't modify the "FileVersion" string value |
| -rRESID |
modify only the version resource with the resource id RESID (Default: modify all resources) |
| -v |
Verbose (echo the modified values) |
| -l |
Process a list file instead of a resource (see below) |
List Files
For batch processing, you can specify a text file containing a list of file names, like this:
rcstamp @files.txt *.*.+.*
files.txt could look like this:
c:\sources\hamlet\hamlet.rc
c:\sources\ophelia\ophelia.rc=*.*.0.+
c:\sources\laertes\laertes.rc
You can add a format for an individual file (separated by a '=') to override the format specified at the command line.
-l - the Self-Awareness switch
The -l option allows to modify a list file like the one above, instead of a resource script. This is far from useful, since all special formattings will be rendered as 0, and I suspect a bug there. But it's a perfect example of the useless features you spend late hours with.
Return Values
Since it's intended for batching, there are some errorlevel's to evaluate:
ERRORLEVEL 3 : invalidarguments
ERRORLEVEL 1 : an error occured when processing at least
one file (error message written to stderr)
ERRORLEVEL 0 : everything's fine
Source
The sources are pretty straightforward, it doesn't rely on any library (besides the VC runtime). main() clobbers the command line, and then processes either the specified file, or opens the file list and processes each of the files. ParseArg() will analyze one command line parameter at a time, and store it's findings in global variables. ProcessFile() will process a single file according to the options set. CalcNewVersion() calculates the new file version from a string containing the old one and a format specifier.
The files are read with std::ifstream line-by-line, The modified text is collected in a std::string, and then the entire file is overwritten.
Issues
This is a one-nighter (a half-nighter, even) - I didn't test everything (e.g. the '-' format specification, and the -l option), there are some potential buffer overruns and when you run out of memory it will look ugly. The file parsing is homegrown, it doesn't really "understand" the .rc file; it just looks for certain tokens, using of strdup and strtok. it is fairly stable with the .rc files produced by Visual Studio, but it might fail in exotic cases (I didn't even dive into the .rc documentation so I don't know what is allowed).
Oh, and you might already have guessed - you can't decrement the first position, since the leading '-' is interpreted as option. Since this tool is in daily use (I use it now for the daily builds at work, and for preparing releases) I for sure will fix the bugs that appear in the features I need. Beyond that, it's up to you - at least, up to your persuasion skills.
Enjoy.
