Apparently we'd never bothered opting in, despite nearly everything in all out apps being entirely compatible and designed with long paths in mind.
GetModuleFileNameW is a bit awkward as it's just about the only Win32 function that returns the minimum of the buffer size and the string size - nearly everything else returns the full size even if it won't fit, so you can pass it a null pointer and a size of zero, and it'll tell you how much space you need to allocate.
I pretty much just copied the mostly-working long-path-friendly call site in the crash catcher to windowspath.cpp, but I also noticed that if the function failed and returned zero, the original implementation would loop forever, so I fixed that.
There was some code that could be ditched from the catch monitor as \\?\ is a prefix you can use to opt into long paths for a single API call instead of using the manifest to set it everywhere.
The same Windows functionality as scaling user interface elements,
confuses fullscreen games unless they set a particular of metadata to
indicate that they perform the scaling by themselves.
What happened was treating 2160p as 1440p despite the former being
chosen. The same occured with other game title prior to introducing the
metadata bits.
Fortunately with CMake there's no need to invoke the mt.exe "manifest
tool" manually.
Note that the setting of "per-monitor DPI aware" still leaves openmw
confused, hence the choice of global-DPI-aware.
