On 15 Nov 2013 at 13:52, Gavin Lambert wrote:
On 15/11/2013 08:52, Quoth Niall Douglas:
I've bumped the notion of raising that limit to our friends in Microsoft. Who knows, it may be possible for Windows 8.2!
As I previously mentioned, I don't think it's something they can do on a version boundary, only on an ABI boundary (eg. 32-bit vs. 64-bit, or by introducing new APIs).
There's just too much existing (and will not be recompiled) code that has stack based char[MAX_PATH] buffers.
They can't even do the manifest-version-based shimming that they're doing for some other things, as that's defined at the process level -- just because an application claims that it knows about a larger MAX_PATH doesn't mean that all the DLLs that it uses does.
I wouldn't be proposing that MAX_PATH should be changed for any code not being compiled for the latest toolset where MAX_PATH was extended. So, if you're linking to MSVCRT13.DLL then you get MAX_PATH=1024, while any previous MSVCRT gets MAX_PATH=260. What about mixed MSVCRT apps? Well, already those aren't reliable and you shouldn't do them :) But it still should usually work as usually application code is compiled with a newer toolset than library code, and therefore you're passing in a larger buffer which may cause library code to puke on the longer path, but not corrupt memory. A lot of time library code simply passes through externally supplied buffers anyway, and therefore doesn't care.
(Not that I wouldn't love them to try, I just wouldn't hold out much hope for it.)
I got a response - it is thought highly unlikely to be successful. I guess you'd need to make a convincing business case, and I agree given Windows' size in the market they don't have to bother adapting to others i.e. if you're porting to Windows, you accept the 260 char path limit as part of the porting effort and all the code refactoring therefore needed. BTW, my current side project of implementing a standard transactional graph database gets rid of the path length limitation on Windows. One of its interfaces is a POSIX-like file system interface, and by POSIX-like I mean it looks just like a POSIX file system except it has more reserved characters for working with things like multiple file versions, creating directories which are really live searches on the graph store, being able to transact update many files atomically or not at all etc. My idea is that (eventually) you could mount this graph store as a fuse filesystem and work with it as if it were a real file system. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/