From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, <pgsql-hackers-win32(at)postgresql(dot)org> |
Subject: | Re: win2k, service, pg_ctl, popen, etc |
Date: | 2004-07-21 14:06:37 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE34BED7@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers-win32 |
> >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
way.
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*...
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2004-07-21 14:10:58 | Re: win2k, service, pg_ctl, popen, etc |
Previous Message | Bruce Momjian | 2004-07-21 14:05:37 | Re: Borland c++ compile problems... |