Boost logo

Boost :

Subject: Re: [boost] [build] File / path lengths difficult to manage on Windows
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-15 16:34:25

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.


Currently unemployed and looking for work.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at