I'm proposing the former for a start, since it doesn't require any UI changes.

Presumably any fix should continue to allow a user-specified .syso file to override the manifest.

We should automatically embed this manifest when linking EXE files. For prior art, see this third-party tool for generating a .syso file containing a manifest:

It is probably not important, but do you plan to generate .syso file with the manifest and link it with the executable, or modify linker to append manifest as executable is built?

Alex

What would the benefit be if we made this change? Now that we use long path syntax transparently in the Go APIs I don't see what adding the XML manifest would add (other than XML).

The main benefit is that the syscall.GetVersion() number would return the correct Windows version.

Applications not manifested for Windows 8.1 or Windows 10 will return the Windows 8 OS version value (6.2).

see https://msdn.microsoft.com/en-us/library/windows/desktop/ms724439

Example:

winver, _ := syscall.GetVersion()

fmt.Printf("Windows version: %v.%v.%v", byte(winver), byte(winver>>8), uint16(winver>>18))

With manifest: Windows version: 10.0.4074
Without manifest: Windows version: 6.2.2300

@quentinmit thanks for the hint on goversioninfo. This is how we currently approach it: https://github.com/konsorten/ktn-build-info/blob/master/ver/go.go

Note that the gcc that comes with MSYS2 under default configurations forces a manifest to be included; see msys2/MSYS2-packages#454 In a cgo build, it gets included in the output _cgo_.o file.

Just got hit by this again on goimports on windows machine. Fixing this only for single executable is possible, but way painful - there are too many of them. Fixing it for all Go-built executables would be absolutely wonderful...

Any solution would need to not interfere with a manifest that's provided by the programmer — for example, through cgo, or as a syso file. The MinGW thing I mentioned above will defer to a manifest you provide if you provide one.

Example showing my current solution, though in this case for selecting side-by-side assemblies instead of enabling Windows 10 version detection: https://github.com/andlabs/ui/tree/master/winmanifest

Also note that the OS version manifest is a promise that the program is well-written and uses the OS version information correctly — and there are incorrect uses of version detection, such as feature guards where a simple LazyDLL lookup will suffice instead. Even if Go does this automatically, the burden will still fall on the Go programmer as well.

I am currently working on a Windows GUI library and to get around the user having to create a manifest file I load one at runtime using CreateActCtx and ActivateActCtx, see here:

https://github.com/gonutz/wui/blob/de4f85fed213c34377fd068ef39e1b2f0e04ea7d/window.go#L1119

which is another way the manifest file can be overwritten.

We need someone to file a separate proposal to support a user-provided manifest on Windows. And also MacOS?

cc @zx2c4 @jstarks @eliasnaur

XML file + windres (from llvm or binutls) ==> .syso, which go gladly accepts. This works fine for me and lets me use other features of Windows resources.

FWIW, Gio has a tool for building Windows executables and adding a manifest to specify its icon: https://git.sr.ht/~eliasnaur/gio/tree/main/item/cmd/gogio/windowsbuild.go. I believe the Fyne project has something similar, including support for macOS.

Right. There are many ways to generate resource files -- they're just PE/COFF objects, after all. The point is, I'm not sure this is something that the Go toolchain needs now, beyond ingesting .syso files created by tools like yours or windres or others.

A counterargument is that various Win32 API behavior is tweaked according to the contents of the manifest. We've already identified the long path behavior as one case, but there is various compatibility-related behavior keyed off the more generic supportedOS element:

• GetVersion only reports the correct version if you advertise Windows 8+ support.
• The heap applies some extra optimizations to limit commit use if you advertise Windows 10+ support.
• The system is more aggressive about faulting on invalid handle use if you advertise Windows 10+ support.
• CreateFile and GetOverlappedResult have stricter behavior if you advertise Windows 10+ support.

Regardless what is decided about the long path bit, it may be in Go's interest to make setting these easy or automatic rather than rely on each application to construct and link a manifest manually.

@jstarks (or anyone) how should this work in practice?

Build-time recognition of a manifest source file for GOOS=windows? And automatic generation of a manifest with the features you listed (which could then be modified by user)? Should it issue warnings if it finds a manifest without those features?

Filed #44466 - proposal: create manifest when building for Windows.