fix(win): Embed manifest in OIIO .exes to enable long path handling

[nrusch]

Description

Adds an embedded manifest to OIIO's generated executables on Windows, which enables "long path" awareness.

This is done via a "resource" file, with the manifest resource ID specified. From what I've read, this is more broadly compatible with e.g. non-MSVC build toolchains like MinGW.

The manifest file was created by building OIIO from main, extracting the manifest from the resulting oiiotool (using the mt tool), and manually adding in the XML snippet from https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#application-manifest-updates-to-declare-long-path-capability.

Fixes #5064

Tests

Added a new Windows-only test to validate that oiiotool can correctly read long image paths.

The one executable that I have not tested is iv. The only reason I'm more curious about it than others is that it is a GUI executable, so I'm not sure if its default

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested somewhere in the
  testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: nrusch / name: Nathan Rusch (6e3caf7, 95cc2f3)

[nrusch]

This is something I don't have a strong instinct for. The manifest resource ID isn't going to change, and this value hardcoding seems to be fairly commonplace from what I've found. I opted to avoid an #include here to start just because I don't know if that would have any other implications.

[lgritz]

Need a DCO sign-off on the commit.

Can you add something to the testsuite that verifies that this allows the long filenames so we will know if there is any regression?

[nrusch]

DCO should be fixed. I'll look at adding a test for this as soon as I can.

[nrusch]

OK, I've added a smoke test for long path support in oiiotool, and confirmed that the test fails without my patch applied.

However, the last thing I think I need to do is make the test conditional on whether long path support is enabled in the registry (the first of the two conditions documented here: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later)

I'll try to figure that out tomorrow (worst case scenario is I can just have the test script check and "succeed" if it is not enabled).

[lgritz]

However, the last thing I think I need to do is make the test conditional on whether long path support is enabled in the registry

What? You mean that in addition to the fix on our side, there's also a system setting not under our control that can be wrong, and will make our software just fail for long paths?

[lgritz]

By the way, if you rebase on current main, I think it will clear up the spurious CI failures.

[nrusch]

What? You mean that in addition to the fix on our side, there's also a system setting not under our control that can be wrong, and will make our software just fail for long paths?

Yup. The additional key in the executable manifests only has an effect if long path support is enabled at the system level.

Setting aside the insanity of this situation, I can imagine two schools of thought here from a maintainer's perspective:

1. If someone is dealing with a long path on Windows, they're going to run into this problem in other tools (like the system file explorer), so they should have already encountered the need for a registry tweak. This mindset more or less aligns with the proposal here, and (in OIIO's case) keeps the change surface area low.
2. "I don't ever want to hear about any form of this problem again": I imagine some version of this sentiment would motivate someone to implement their own path transform logic so all internal path handling is done in terms of extended-length paths (\\?\...) on Windows.

[nrusch]

I've added a check for the registry setting before enabling the test, and rebased onto main.

[lgritz]

Setting aside the insanity of this situation, I can imagine two schools of thought here from a maintainer's perspective:

I think we're doing exactly the right thing: Fix the part that's under our control as simply as we can, and for the rest, if somebody is using long filenames and Windows and don't know about the registry thingie, they've made their own bed.

[lgritz]

LGTM, thanks for this fix!