On 25/11/2013 07:35, Quoth Niall Douglas:
And of course well written Win32 API code ought to adjust to a larger MAX_PATH without any problems at all :)
If you get to recompile it, sure. The trouble is that there are a LOT of existing Windows apps that aren't going to get recompiled. Even mission-critical LOB ones for which source code no longer exists (or is otherwise inaccessible, eg. external developer no longer in business). The problem is that most of the APIs themselves don't have a parameter that specifies the buffer size actually provided, they just have an assumption that the buffer is "at least MAX_PATH characters". There is no safe way to increase the value of MAX_PATH with these APIs, without either making a new parallel set of APIs that use eg. MAX_PATH2, or (better) add an extra parameter that allows the buffer size to be specified. (It doesn't matter so much with APIs that only take string input, such as CreateFile; but there are a lot of string output APIs too, and quite a bit of external code that hooks APIs at various levels, or library code that abstracts and encapsulates the APIs.)
Still, it would be hard to create a business case in favour of it within Microsoft, and therefore it is very hard to imagine it happening.
Exactly. Although even they run into it from time to time. (I had a case recently where an SQL Server install failed because the installer was being run from a pathname that was too long for its internal support files, which is why their install wrappers tend to use a random-numbered folder in the root instead of the "real" temporary folder.)