On Wednesday, 19 September 2018 at 10:29:11 UTC, Vladimir
Panteleev wrote:
- GetFullPathName is documented as also having the MAX_PATH
limit, but the framework seems to use it for normalization
BEFORE prepending the prefix.
https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-getfullpathnamea
That part is erroneous :)
Recent additions to msdn are too often incompetent, e.g. long
path registry switch in windows 10 doesn't enable the feature,
it's only the first of two gates, manifest is not optional. Don't
ask me who does it. They can't even get backslashes right.
Passing unparsed path to GetFullPathName makes no sense because
such unparsed path must be already full normalized path, and it
doesn't have MAX_PATH limit, probably because it doesn't talk to
file system.
- GetFullPathName has a big warning on it about how you
shouldn't use it in multithreaded programs.
I wonder about that too, shouldn't the system do the same to
resolve the absolute path? Theoretically it can keep an open
handle to the current directory and get its path from that.