> >Does there continue to be any resistance to this approach?
> If not, I'll
> >gladly provide a patch.
> As I understand it, Windows has a standard set of DLL/EXE
> metadata (build number, copyright, product name yadda yadda
> yadda) stored in some well-known segment of the file. Is
> there any reason we can't put the version number somewhere in
> there and use some standard API to extract it, rather than
> running the .exe to make it tell us? (Not that I have any
> idea how to do such a thing.)
We could, see VerQueryValue() and friends on MSDN.
It *requires* that the version number *always* follows the pattern
a.b.c.d, where each of a-d is a 32 bit unsigned int. Meaning there is no
way to determine RCs etc, unless we start tracking build numbers in some
While I think the whole checking of the version there is somewhat of an
overkill (again, if you mix binary versions, you are probably going to
mess up a whole lot of other things too), it is probably not a bad idea
to add version numbering to the binaries *anyway*...
pgsql-hackers-win32 by date
|Next:||From: Andreas Pflug||Date: 2004-07-21 14:10:58|
|Subject: Re: win2k, service, pg_ctl, popen, etc|
|Previous:||From: Bruce Momjian||Date: 2004-07-21 14:05:37|
|Subject: Re: Borland c++ compile problems...|