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.