Make it easier to embed a windows manifest for long paths

[konstin]

This issue is a crossover from #14948 and #9770 with a more narrow focus: Make it easier to have an embedded windows manifest that enables long paths.

It seems that widely used Rust CLI applications that process user file trees eventually run into the problem of long path support. Some examples (feel free to add more):

• Cargo and rustc: Add a windows manifest file #13131 and Add Windows application manifest to rustc-main rust#96737
• uv: Add a Windows manifest to uv binaries astral-sh/uv#16894
• ripgrep:BurntSushi/ripgrep@db6bb21

Currently, this requires understanding (or copying) a Windows manifest that sets <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>. There's even a dedicated crates for generating this manifest: https://codeberg.org/carey/embed-manifest.

The main argument from Microsoft's side to not enable this by default is that you may write a long path that other applications can't read (microsoft/WindowsAppSDK#875 (comment)). In my experience, the current default does not protect from problems with long paths (e.g. astral-sh/uv#16877).

The two main problems are that most application developers are unaware of Windows manifests, how they relate to long paths and that the error message they see is a path length issue, and that this requires a build script for crates that would otherwise work without a build script.

[epage]

We in general want to find ways to reduce the need for people to write build scripts (#14948).

My main concern with this is if multiple manifests are allowed. If not, how do we compose this with anything the user wants to put in the manifest.

[samypr100]

My main concern with this is if multiple manifests are allowed

I'd expect the flexibility of having different manifests per [[bin]] would be needed, although by default it could be the same one for all the binaries. I don't expect composing being needed (if I'm understanding correctly), although that depends on the final design consensus.

I'm not trying to propose how it should be implemented, but below is an example I'd expect to be fairly common where entries may be different depending on the generated binary and enabled features.

[package]
name = "without_gui"
win_manifest_file = "/path/to/manifest_default.xml"
...
[[bin]]
name = "with_gui"
win_manifest_file = "/path/to/manifest_override.xml"
required-features = ["subsystem-windows"]

Where each manifest could have a different entries such as

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
  <assemblyIdentity name="without_gui" type="win32" version="0.0.1.0"></assemblyIdentity>
...
  <asmv3:application>
    <asmv3:windowsSettings>
      <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">unaware</dpiAwareness>
    </asmv3:windowsSettings>
  </asmv3:application>
...
</assembly>

and

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
  <assemblyIdentity name="with_gui" type="win32" version="0.0.1.0"></assemblyIdentity>
...
  <asmv3:application>
    <asmv3:windowsSettings>
      <longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">permonitorv2</dpiAwareness>
    </asmv3:windowsSettings>
  </asmv3:application>
...
</assembly>