Uhm, Shell APIs are necessary when you're dealing with shell objects, but all filesystem APIs can work with paths longer than MAX_PATH iff you use the Unicode A

Uhm, Shell APIs are necessary when you're dealing with shell objects, but all filesystem APIs can work with paths longer than MAX_PATH iff you use the Unicode API (e.g. CreateFileW) and prefix the path with \\?\ [½]. They can't retroactively change MAX_PATH because it's a constant that's compiled in every application that uses it. Well-written applications these days will just do the \\?\ thing and be done with it. The downside of that is that you can get paths Explorer doesn't like. And I'm guessing Explorer explicitly doesn't allow you to create paths longer than MAX_PATH to prevent people complaining about »I created a folder in Explorer and copied a file there, but now I cannot open it.«. Keep in mind that (usually) developers can be expected to find solutions, but making it easy to frustrate regular users (of which the OS has at least a few hundred million) is not the best strategy to keep them using the OS. Of course, there are also heaps of software that cannot use above method to allow for longer paths because they don't use the Unicode APIs. Maybe because some developers think supporting Windows 98 is a good idea nowadays, or because they just don't know any better. And in that heap there's a lot of poorly-ported open-source software, too. [½] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...