windows resource files, bugs and what do we actually want

On Tue, Aug 30, 2022 at 12:13 AM Andres Freund <andres@anarazel.de> wrote:

Hi,

A few things about the windows resource files we generate

1) For make based builds, all libraries that are built with MODULES rather
than MODULES_big have the wrong "FILETYPE", because Makefile.win32
checks
$(shlib), which is only set for MODULES_big.

This used to be even more widely wrong until recently:

commit 16a4a3d59cd5574fdc697ea16ef5692ce34c54d5
Author: Peter Eisentraut <peter@eisentraut.org>
Date: 2020-01-15 10:15:06 +0100

Remove libpq.rc, use win32ver.rc for libpq

Afaict before that we only set it correctly for pgevent.

2) For make base builds, We only set InternalName, OriginalFileName when
$shlib is set, but InternalName, OriginalFilename are required.

https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource

3) We don't add an icon to postgres ("This is a daemon process, which is
why
it is not labeled as an executable"), but we do add icons to several
libraries, at least snowball, pgevent, libpq.

We should probably just remove the icon from the libraries?

Agreed, adding it to libraries seems plain wrong.

4) We include the date, excluding 0 for some mysterious reason, in the

version
number. This seems to unnecessarily contribute to making the build not
reproducible. Hails from long ago:

commit 9af932075098bd3c143993386288a634d518713c
Author: Bruce Momjian <bruce@momjian.us>
Date: 2004-12-19 02:16:31 +0000

Add Win32 version stamps that increment each day for proper SYSTEM32
DLL pginstaller installs.

This is obviously far too long ago for me to *actually* remember, but I
think the idea was to make it work with snapshot installers. As they would
only replace the binary if the version number was newer, so for snapshots
it would be useful to have it always upgrade.

Doing it for release builds seem a lot less useful.

5) We have a PGFILEDESC for (nearly?) every binary/library. They largely

don't
seem more useful descriptions than the binary's name. Why don't we just
drop most of them and just set the description as something like
"PostgreSQL $name (binary|library)"? I doubt anybody ever looks into
these
details except to perhaps check the version number or such.

At least back in the days, a lot of software inventory programs would
scrape this information into corporate-wide databases to keep track of what
was in use across enterprises. I have no idea if people still do that or if
it's all just checksums+databases now, but that was one reason back in the
days to put it there.

But yes, setting the description per your suggestion would work equally
well for that, and would make things more consistent.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

Hi,

On 2022-09-01 22:34:07 +0200, Magnus Hagander wrote:

4) We include the date, excluding 0 for some mysterious reason, in the

version
number. This seems to unnecessarily contribute to making the build not
reproducible. Hails from long ago:

commit 9af932075098bd3c143993386288a634d518713c
Author: Bruce Momjian <bruce@momjian.us>
Date: 2004-12-19 02:16:31 +0000

Add Win32 version stamps that increment each day for proper SYSTEM32
DLL pginstaller installs.

This is obviously far too long ago for me to *actually* remember, but I
think the idea was to make it work with snapshot installers. As they would
only replace the binary if the version number was newer, so for snapshots
it would be useful to have it always upgrade.

Does any installer actually behave that way? Seems very doubtful.

5) We have a PGFILEDESC for (nearly?) every binary/library. They largely

don't
seem more useful descriptions than the binary's name. Why don't we just
drop most of them and just set the description as something like
"PostgreSQL $name (binary|library)"? I doubt anybody ever looks into
these
details except to perhaps check the version number or such.

At least back in the days, a lot of software inventory programs would
scrape this information into corporate-wide databases to keep track of what
was in use across enterprises. I have no idea if people still do that or if
it's all just checksums+databases now, but that was one reason back in the
days to put it there.

Think that still happens, although I suspect they care more about the vendor
etc than about the description. And would likely care more if we signed
build products etc...

But yes, setting the description per your suggestion would work equally
well for that, and would make things more consistent.

I guess I'll come up with a patch then :(

Greetings,

Andres Freund

On Thu, Sep 1, 2022 at 11:22 PM Andres Freund <andres@anarazel.de> wrote:

Hi,

On 2022-09-01 22:34:07 +0200, Magnus Hagander wrote:

4) We include the date, excluding 0 for some mysterious reason, in the

version
number. This seems to unnecessarily contribute to making the build

not

reproducible. Hails from long ago:

commit 9af932075098bd3c143993386288a634d518713c
Author: Bruce Momjian <bruce@momjian.us>
Date: 2004-12-19 02:16:31 +0000

Add Win32 version stamps that increment each day for proper

SYSTEM32

DLL pginstaller installs.

This is obviously far too long ago for me to *actually* remember, but I
think the idea was to make it work with snapshot installers. As they

would

only replace the binary if the version number was newer, so for snapshots
it would be useful to have it always upgrade.

Does any installer actually behave that way? Seems very doubtful.

I think the one we had back in the days was. But that one is *long* dead
now.

5) We have a PGFILEDESC for (nearly?) every binary/library. They largely

don't
seem more useful descriptions than the binary's name. Why don't we

just

drop most of them and just set the description as something like
"PostgreSQL $name (binary|library)"? I doubt anybody ever looks into
these
details except to perhaps check the version number or such.

At least back in the days, a lot of software inventory programs would
scrape this information into corporate-wide databases to keep track of

what

was in use across enterprises. I have no idea if people still do that or

if

it's all just checksums+databases now, but that was one reason back in

the

days to put it there.

Think that still happens, although I suspect they care more about the
vendor
etc than about the description. And would likely care more if we signed
build products etc...

Yeah, agreed on both accounts.

And getting into signing them would certainly be a good thing, but that's a
much bigger thing...

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;g

Hi,

On 2022-08-29 15:13:14 -0700, Andres Freund wrote:

1) For make based builds, all libraries that are built with MODULES rather
than MODULES_big have the wrong "FILETYPE", because Makefile.win32 checks
$(shlib), which is only set for MODULES_big.

This used to be even more widely wrong until recently:

commit 16a4a3d59cd5574fdc697ea16ef5692ce34c54d5
Author: Peter Eisentraut <peter@eisentraut.org>
Date: 2020-01-15 10:15:06 +0100

Remove libpq.rc, use win32ver.rc for libpq

Afaict before that we only set it correctly for pgevent.

2) For make base builds, We only set InternalName, OriginalFileName when
$shlib is set, but InternalName, OriginalFilename are required.

https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource

These are harder to fix than was immediately obvious to me. We generate one
win32ver.rc per directory, even if a directory contains multiple build
products (think MODULES or src/bin/scripts). So we simply can't put a correct
filename etc into the .rc file, unless we change the name of the .rc file.

I looked into how hard it would be to fix this on the make side, and decided
it's too hard. I'm inclined to leave this alone and fix it later in the meson
port.

Greetings,

Andres Freund

On Fri, Sep 2, 2022 at 3:26 AM Andres Freund <andres@anarazel.de> wrote:

Hi,

On 2022-08-29 15:13:14 -0700, Andres Freund wrote:

1) For make based builds, all libraries that are built with MODULES

rather

than MODULES_big have the wrong "FILETYPE", because Makefile.win32

checks

$(shlib), which is only set for MODULES_big.

This used to be even more widely wrong until recently:

commit 16a4a3d59cd5574fdc697ea16ef5692ce34c54d5
Author: Peter Eisentraut <peter@eisentraut.org>
Date: 2020-01-15 10:15:06 +0100

Remove libpq.rc, use win32ver.rc for libpq

Afaict before that we only set it correctly for pgevent.

2) For make base builds, We only set InternalName, OriginalFileName when
$shlib is set, but InternalName, OriginalFilename are required.

https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource

These are harder to fix than was immediately obvious to me. We generate one
win32ver.rc per directory, even if a directory contains multiple build
products (think MODULES or src/bin/scripts). So we simply can't put a
correct
filename etc into the .rc file, unless we change the name of the .rc file.

Eeep. Yeah, that may be the reasoning behind some of how it was in the past.

I looked into how hard it would be to fix this on the make side, and
decided
it's too hard. I'm inclined to leave this alone and fix it later in the
meson
port.

Agreed.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/&gt;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/&gt;

On 30.08.22 00:13, Andres Freund wrote:

1) For make based builds, all libraries that are built with MODULES rather
than MODULES_big have the wrong "FILETYPE", because Makefile.win32 checks
$(shlib), which is only set for MODULES_big.

This used to be even more widely wrong until recently:

commit 16a4a3d59cd5574fdc697ea16ef5692ce34c54d5
Author: Peter Eisentraut <peter@eisentraut.org>
Date: 2020-01-15 10:15:06 +0100

Remove libpq.rc, use win32ver.rc for libpq

Afaict before that we only set it correctly for pgevent.

Note, when I worked on this at that time, it was with the aim of
simplifying the version stamping script. So I don't really know much
about this.

3) We don't add an icon to postgres ("This is a daemon process, which is why
it is not labeled as an executable"), but we do add icons to several
libraries, at least snowball, pgevent, libpq.

We should probably just remove the icon from the libraries?

Wouldn't the icon still show up in the file manager or something? Where
is the icon actually used?

4) We include the date, excluding 0 for some mysterious reason, in the version
number. This seems to unnecessarily contribute to making the build not
reproducible. Hails from long ago:

Yeah, that is evil.

5) We have a PGFILEDESC for (nearly?) every binary/library. They largely don't
seem more useful descriptions than the binary's name. Why don't we just
drop most of them and just set the description as something like
"PostgreSQL $name (binary|library)"? I doubt anybody ever looks into these
details except to perhaps check the version number or such.

We do an equivalent shortcut with the pkg-config files:

echo 'Description: PostgreSQL lib$(NAME) library' >>$@

Seems good enough.