The problem is backwards compatibility. To make the code transition from Win16API to Win32API very easy in 1994-95 era Microsoft made several design decisions for Win32API, that don't make sense anymore - 20 years later.
Unfortunately, the Windows shell (explorer.exe/shell32.dll & cmd.exe) are more limited than what you can do with Win32API.
One can access the NT object tree from C/C++
"\\.\PhysicalDrive2" ... opens third physical drive
"\\.\C:\" ... opens the file system of the C: volume
"\\.\COM1" ... opens serial port 1
"\\.\pipe\pipename" ... opens named pipe
"\\.\mailslot\sample" ... open mailslot
"\\?\UNC\server\share" ... opens universal UNC path
"\\?\C:\" ... opens C:, you can exceed the MAX_PATH limits
Instead of further improving Win32API, as they have done like ReadFileEx() (http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... ), Microsoft toys around with several dotNet API layers on top of Win32API and now a WinRT API that stills sits on top of the Win32 subsystem. Windows NT would support several subsystems (like there are POSIX, OS/2, Xbox subsystems for WinNT/ReactOS).
Some of them are the limited MAX_PATH, which is defined as 260 characters, reserved characters in file names, 8.3 filename aliasing (fixed), etc. - see: http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
Unfortunately, the Windows shell (explorer.exe/shell32.dll & cmd.exe) are more limited than what you can do with Win32API. One can access the NT object tree from C/C++
You can use CreateFile(), ReadFile(), WriteFile(), etc. Win32API function to work on NT objects (not just files but real NT objects, the name is just inherited from Win16API) - http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... , http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... , http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
Some NT path examples:
screenshot of WinObj that corresponds to the last example: http://s1.postimg.org/ckhs6xedr/ntobject.pngInstead of further improving Win32API, as they have done like ReadFileEx() (http://msdn.microsoft.com/en-us/library/windows/desktop/aa36... ), Microsoft toys around with several dotNet API layers on top of Win32API and now a WinRT API that stills sits on top of the Win32 subsystem. Windows NT would support several subsystems (like there are POSIX, OS/2, Xbox subsystems for WinNT/ReactOS).