xvid 1.1.12 bug: versions

[zachdms]

This is dumb, but at least the 1.1.12 xvid decoder dlls don't have version numbers:
===
C:\WINDOWS\system32>filever xvid*
--a-- W32i - - - - 77,824 11-01-106 xvid.ax
--a-- W32i - - - - 765,952 11-01-106 xvidcore.dll
--a-- W32i - - - - 180,224 11-01-106 xvidvfw.dll
===

Version numbers are really helpful for helping track what version a user has when you get a crash dump. (I was looking at user crash dumps today and noticed this. I'm pretty sure they had an old version that was crashing, but realized that without this bit of data I could be guessing a little more than usual.)

[unskinnyboy]

Just checked myself. The *.rc files (both dshow and vfw) don't have the VERSIONINFO in them, that's why. Shouldn't be a problem for the devs to add them if you send a mail to the XviD-dev mailing list. Meanwhile maybe you could just compare the MD5 hashes of the DLLs for the moment.

[sysKin]

XviD's libraries never had version numbers.

Basically, I have no clue how to add them in a way that's automatic... ie so that I don't need to commit new rc files every time.

[shae]

Use the same version string #define used elsewhere.
VALUE "ProductVersion", PROGVER "\0"

The tricky part is using the same #defines for creating also the binary version info (PRODUCTVERSION/FILEVERSION). With the following you can only set #VER_? and use #PROGVER_BIN and #PROGVER_STR where appropriate.

#define VER_A 1
#define VER_B 1
#define VER_C 2

#define STR1(s) #s
#define STR2(s) STR1(s)

#define PROGVER_STR_PRM(a, b, c) a "." b "." c
#define PROGVER_BIN_PRM(a, b, c) a, b, c, 0

#define PROGVER_STR PROGVER_STR_PRM(STR2(VER_A), STR2(VER_B), STR2(VER_C))
#define PROGVER_BIN PROGVER_BIN_PRM(VER_A, VER_B, VER_C)