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-13 21:13:37

On 14/11/2013 14:31, Quoth Ben Craig:
> I think this is being unrealistic. If we take this approach, then you
> should request every Win32 program that uses fopen, iostreams, or
> CreateFile without the magic marker to change their program to use a
> non-portable API. This includes programs like cmd.exe, explorer,
> bjam, 7zip, and countless others.

Did you mean to quote someone else?  Because I was agreeing with you.

> I wish that "normal" Windows APIs permitted a higher maximum path
> length, but they don't.  Reasonable Windows support means
> acknowledging this limitation.

It's unfortunately a wart of its DOS outgrowth.  Back in the days of 8.3 
filename limits a total path length of 260 was ample, and most of the 
early DOS APIs were based around local stack buffers of [MAX_PATH]. 
This has ended up getting carried forward via backwards-compatibility, 
because the APIs don't provide any way to accept the buffer size 
explicitly and it can't be increased arbitrarily without crashing older 
programs.