I've tweaked the pcbuild options for pyshellext to reduce the size of the binary.
Since this is a very simple component, there really isn't much benefit of
optimizing for speed, likely the slowest part of this component's lifetime is
simply loading it.

This patch turns on Whole Program Optimization, MinSpace optimization, /Ob2
AnySuitable function inlining (to expose more code to elimination, this does
actually help here), /Zo (so that people can still debug it when lots of code
has been optimized out), turns of C++ RTTI (nobody is using it), /OPT:REF dead
code elimination, /OPT:ICF COMDAT folding, Link Time Code Generation, and
DebugFull debugging information creation.

/Gw global data optimization seemed to do nothing, which makes sense since
there isn't much going on in this project, very little in the way of actual
global data. Disabling C++ exceptions both in the project config (i.e. /EH-),
and disabling stdlib exceptions via _HAS_EXCEPTIONS=0, had no effect.
Strangely, with exceptions disabled and _HAS_EXCEPTIONS=0, exception functions
are still emitted in the binary (as seen in IDA). I presume it has something
to do with the fact that its a dll.

Enabling optimizations (even for Debug builds) should have no effect. The debug
builds were not actually using debugging featuers (not even assert), so nothing
should change.

pyshellext.dll   32 bit unimproved release size: 42KB
pyshellext.dll   32 bit   improved release size: 25KB
                                size reduction: -17KB
                             %  size reduction:   40%

pyshellext_d.dll 32 bit unimproved debug size:   85KB
pyshellext_d.dll 32 bit   improved debug size:   32KB
                               size reduction:  -53KB
                             %  size reduction:   62%


pyshellext.dll   64 bit unimproved release size: 52KB
pyshellext.dll   64 bit   improved release size: 30KB
                               size reduction:  -22KB
                             %  size reduction:   42%

pyshellext_d.dll 64 bit unimproved debug size:  105KB
pyshellext_d.dll 64 bit   improved debug size:   38KB
                               size reduction:  -67KB
                             %  size reduction:   63%

If this patch is merged, and all 7 million (estimated) Python developers update their installation, I calculate that I just saved the PSF 119GB worth of bandwidth costs :)

I'll take my 10 cents in the mail please :D

I'm seeing some numbers that suggest it's even bigger than 7 million, so you might be deserving of more! Of course, that bandwidth is a donation, so you'll have to apply to Fastly ;)

Our MSBuild projects are hand-maintained (often by people on non-Windows systems). Could you tidy the XML to minimize the "Condition" attributes? And as much as is reasonable, move defaults into pyproject.props and per-project overrides in the specific projects?

Ahh, ok. Even though I question the usefulness of manually maintaining MSBuild files instead of something like CMake, I can work with that. Is there a preferred way to do it? It looks like I can do a Condition="'$(Configuration)|$(Platform)'=='Release|x64'" and merge a bunch of things under each one.

Oh, uh, also, do you prefer I add a commit or a new branch & PR?

In general, no settings rely on both Platform AND Configuration, so you likely only need to check one or the other.

Look at PCbuild/pyproject.props for the best examples. IIRC, properties are set assuming Win32/Release, and then we override those that need to be different for either Debug or x64/ARM builds. Any settings that you think are worth applying to all projects can go in this file, while any that are strictly for pyshellext can go in its vcxproj (but using a similar style).

Let's not start a CMake debate here - there are plenty of other issues on here about that. We currently maintain MSBuild files by hand, and it works well.

More commits on the same PR are fine. We squash merge at the end, so the history only remains in the commit message if we need to put it there.