Boost logo

Boost :

Subject: Re: [boost] [build] File / path lengths difficult to manage on Windows
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-24 16:48:44

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.)

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