VERSIONINFO resource is non-compliant

[alabuzhev]

Windows Terminal version

1.24.2507.04001

Windows build number

Irrelevant

Other Software

No response

Steps to reproduce

1. Get the latest terminal nightly.
2. Pick any PE binary from the distribution, e.g. OpenConsole.exe.
3. Extract its VERSIONINFO resource using third party tools.
4. Do the same for any other typical Windows binary, e.g. conhost.exe.
5. Compare both.

Expected Behavior

The basic structure should be consistent (see below).

Actual Behavior

There are quite a few differences:

The most problematic one is that VarFileInfo.Translation is inconsistent with StringFileInfo header:

• VarFileInfo.Translation is [0, 1200] => [language neutral, Unicode]
• StringFileInfo header is "040904b0" => [U.S. English, Unicode]

This ultimately means that third-party apps cannot query version information of these binaries using VerQueryValue API, because they are supposed to obtain the language-codepage pair from VarFileInfo.Translation first, serialise it as %04x%04x and use that as a key to request data from a corresponding block in StringFileInfo, but serialising [0, 1200] obviously yields "000004b0", which is not there.

Notice that the StringFileInfo block is missing. The tool has failed to find it in OpenConsole.

Minor issues:

• All the Windows binaries and probably most of binaries in the wild these days set FILEOS to VOS_NT_WINDOWS32 (0x40004), i.e. "Win32 subsystem running on NT", which is probably the only reasonable combination anyway. In WT binaries it is for some reason set to just 0x4, i.e. VOS__WINDOWS32. The high word is 0, implying that the base OS is VOS_UNKNOWN. Not a big deal, but can be confusing.
• Spaces in LegalCopyright seems to be off.
• FileDescription could be better :)

Very minor issues:

• When I build locally, binaries don't include version info, is it by design?

[DHowett]

So, this one has an interesting history! We used to rely on the Windows internal versioning rules through some lovecraftian horror of a build system. We (I) identified this specific issue early on, worked around it (#5274):

terminal/src/cascadia/TerminalSettingsModel/CascadiaSettings.cpp

Line 1063 in 02f173d

pVarLocalization->language ? pVarLocalization->language : 0x0409, // well-known en-US LCID

This introduces a magic LCID constant (0x0409). By default, Package ES emits
version resource information that says we're localized to ... language zero.
It also emits a language-coded version block for 0x0409 (en-US).

These two things cannot both be true. Collapse the wave function by hardcoding
0x0409.

... and decided it was out of our hands to handle.

Since then, though, we forked their code and made it not depend on the rest of their terrible build system.

We {sh,c}ould probably fix it now.

[DHowett]

When I build locally, binaries don't include version info, is it by design?

Alas, it is. Now that we nominally "own" the versioning package, I think we could fix this. It's just a nuget package with some pre-build rules. I actually really like it - it's like NerdBank's GitVersion but not awful.