Yeah only the DOS façade of Windows NT is well known. Under that skin lurks some pretty wild late-1980s concepts. One of the core things to understand is that a lot of the features are based on a reverse map of GUIDs to various actions, and resolution of these map entries pervades the UI. That's why you can put {hexspew} as the name of a shortcut on the Windows desktop and have it magically become a deep link to some feature that Windows doesn't otherwise let you create a shortcut to, and also why you can just add things to the control panel which doesn't seem like it would be an intentional feature. And these actions can be named symbols inside DLLs, so they can do literally anything the OS is capable of doing. This is also why Windows has always been ground zero for malware.
>so they can do literally anything the OS is capable of doing
Yea, over the years someone thought of something they wanted to do and then did it without a systematic consideration of what that level of power meant, especially as multi-user network connectivity and untrusted data became the norm.
As far as I can tell, the drive will still be accessible, it'll just require the character equivalent to € on the other code page as a drive letter.
As long as your code page doesn't have gaps, that should be doable. It'll definitely confuse the hell out of anyone who doesn't know about this setup, though!
I don't think it works that way, the actual drive letter is a UTF-16 Unicode path. The application must be able to provide an "ANSI" string that encodes to that UTF-16 value if it uses an "ANSI" function to open the file. It's not like 8-bit systems where they just want the same 8-bit value.
