Another handy dos command, originating back to DOS is SUBST.
Came in pretty handy when I wanted to share a folder with Remote Desktop, but it would only let me select whole drives.
Made a SUBST drive letter for that folder, worked like a charm!
Came in pretty handy when I wanted to share a folder with Remote Desktop, but it would only let me select whole drives.
Made a SUBST drive letter for that folder, worked like a charm!
You can either see this by using "NtQuerySymbolicLinkObject" on "\??\M:", or calling "QueryDosDeviceW" on "M:". On Windows NT, you will see the result as an NT-native path "\??\C:\target_path" rather than a Win32-style path "C:\target_path".
"\??\" is not some kind of special notation for paths or anything, it is a real NT object that exists. It holds your drive letters and other things.
On Windows 9x, you won't see an NT-native path from QueryDosDevice, you'll instead see a Win32-style path "C:\target_path".
Weirdly enough, Sysinternals Winobj is unable to find the symbolic link object at all, despite that it exists when you query it using NT API calls.
Fun fact about NT native paths, you can use them in Win32 if you prefix them with "\\?\GLOBALROOT". So "\??\C:\" becomes "\\?\GLOBALROOT\??\C:\". You can use it in any Win32 program that doesn't actively block that kind of path (such as the file explorer/open dialog)
It is run from a registry key upon bootup.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices]
"P:"="\\??\\C:\\Dev\\Source"
Nice thing about this vs using SUBST is that the SUBST is for your user only, so if you have a separate admin account it won't see it. However the above registry entry is for the machine, so all users on the machine will see it.
Obviously makes it less useful for terminal servers and other shared machines.
The same applies to network drive letter mappings.
Under the hood, both are implemented as NT Object Manager symbolic links, which you can see using, e.g.,
https://learn.microsoft.com/en-us/sysinternals/downloads/win...
Canonicalizing the path resolves all drive letters and symbolic links. The Rust function that canonicalizes a path can fail on some mounted filesystems if the drive letter wasn't registered using the Windows Mount Manager.
The idea of everybody having the same paths for things never sat right with me, because it's an easy way for absolute paths to sneak in, which can be (and occasionally was) a problem when trying to support multiple branches later in the project lifecycle. But if you've got a CI system, which people typically do in 2024, that's much less of an issue (because you can arrange for the CI system to build from a random path each time). And it is pretty handy when you can paste universally-usable paths into the chat.
Or you can end up having to use the magic path for all builds.
At work, we have a subst’d drive. The way we set it up means that some <evil crap> requires it (by the virtue of hardcoding, or by common configuration). But I do most of my development from a fully separate, leaner copy of the repo, and consider the subst drive to be a garbage pile.
Now the chance of introducing dependencies on the standard path is much lower. You can do it, and it will work for you, and it will work for everybody else too when they get your change. But at some point, the CI system will get it, and it will fail, and you'll know that you have something to fix.
You go on folder up and use subst to make a drive letter from which you can delete content.
Win32 allows you to use paths above MAX_PATH in length when you 1. Use the utf-16 filename apis and 2. prefix your path with \\?\.
But the shell doesn't do the latter. It may also use fixed size buffers for paths, that is a common reason for such limitations.