You don't even need to use the NT APIs directly. The Win32 APIs already do it if you use the \\?\ prefix.
You can even demonstrate this with cmd.exe (which uses the Win32 API, it doesn't directly access the NT API)
`mkdir c:\con` will not work, says `The directory name is invalid.`
`mkdir \\?\c:\con` does work. But then to delete you have to use the \\?\ prefix again. And `cd \\?\c:\con\` doesn't work, you get the `CMD does not support UNC paths as current directories` error. (Win32 does, this is a cmd.exe limitation only)
My proposal was to have a way of getting the `\\?\` behaviour without having to explicitly provide that prefix.
Actually, not quite. There is one aspect of `\\?\` which is undesirable. The NT API only supports backslash as a directory separator. The Win32 API supports forward slash as well, it automatically converts forward slash to backslash. But `\\?\` turns that conversion off. I think you'd still want the forward to backslash conversion on, to maximise compatibility with Unix.
The reason why it's not quite so simple is because any existing API that uses TCHAR[MAX_PATH] would be ABI-broken. Some of them are obvious, e.g. the WIN32_FIND_DATA struct used by FindFirstFile/FindNextFile.
The less obvious part is that for a very long time, it has been a contract for all Win32 functions that return PATHs, that the maximum size of the returned path is MAX_PATH. So there are a lot of apps that basically allocate a buffer of that size and assume that it'll always be enough. So functions like GetFullPathName can't just start returning longer names, because it would break those apps. Instead, they rely on the presence of "\\?\" prefix in the input path as an indicator that the calling app understands those longer paths, and is ready to accept them as outputs as well.
I agree, but there are two different issues here (1) \\?\ to bypass the maximum path length limitation; (2) \\?\ to bypass the reserving of file names for devices
You are talking about (1), and I agree it has some problems, yet Microsoft already has an EXE manifest option to bypass maximum path length without \\?\.
Whereas, I am proposing (2), which could exist without (1). They could add an EXE manifest option and/or registry key to tell the Win32 API to ignore bare device names, or device names with extensions, when converting Win32-to-NT paths, even while keeping the MAX_PATH limitation. So you wouldn't need \\?\ to access a file/directory with a reserved device name. But you might still need it to access a long path. The two issues are orthogonal and could be controlled by different settings.
