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.
If mAbortReloadCells is set to true before the first mReloadCellsMutex
lock the loop can become infinite. Unlikely to happen in practice but
theoretically possible.
I tested this with a USB3 external hard drive.
These two places were the only ones where we're IO-bound and block the main thread, so they're the only ones that need progress bars.
If trying to replicate this test, then it's important to unplug the hard drive between each repeat.
Apparently Windows is excellent at disk caching these days as it takes a minute and a half to start the launcher with Total Overhaul on this drive when it's just been plugged in, but less time than the first launch after a reboot on an NVME drive once the cache has been warmed up.
Store original representation of paths in content lists. Also compare against existing content lists in a more forgiving way.
See merge request OpenMW/openmw!4424
Also compare against existing content lists in a more forgiving way.
The first improvement makes it possible to use relative paths in openmw.cfg without the launcher canonicalising them.
This was really annoying if you used a relative path on purpose.
It also stops the launcher converting all paths to Qt's convention, where forward slashes are used on Windows even though they're not native.
The engine doesn't care, so you could always put either in the config file, but the launcher wouldn't stand for that, and would make them match.
To make this work, we need to store a path's originalRepresentation in the content list, compare paths loaded from openmw.cfg based on their originalRepresentation, and convert paths from originalRepresentation to absolute value when loading them from a content list.
The second improvement means that paths that are equivalent, but expressed differently (e.g. mismatched case on Windows, mismatched separators on Windows, or mild differences like unnecessary `./`es and doubled separators) don't trigger the creation of a new effectively-identical content list.
To make this work, we had to switch the comparison to lexicaly normalise the path first.
It could only be lexical normalisation as originalRepresentation might be absolute, relative, or absolute-but-based-on-a-path-slug, and we didn't want slugs to break things or relative paths to count as equivalent to absolute ones that refer to the same file.
The comparison is case-insensitive on Windows, and case-sensitive elsewhere.
This isn't strictly right, as you can have case-sensitive things mounted on Windows or tell a Linux directory to be case-insensitive, but we can't tell when that might happen based on a lexical path as it depends on real directory properties (and might differ for different parts of the path, which is too much hassle to support).
