Re: [boost] [build] File / path lengths difficult to manage on Windows

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