On Friday, 14 September 2018 at 19:42:39 UTC, Josphe Brigmo wrote:
"It doesn't matter. When I compile a program or DLL in C/C++
and many other languages, I use the Windows headers. These
headers define MAX_PATH to 260.
So the program will have the limit set by compile time, no
matter what you do in the OS later on. There is no advantage
with this setting for now, except that you now *may* pass long
paths to API functions w/o the infamous \\?\ prefix, but you
have no guarantee for it.
So to make this have the advantage that some people think it
will provide, we'd need:
wait until the Windows headers (in Visual Studio, or the
DDK, or the Platform SDK or whatever) is properly updated, i.e.
the runtime libs may take advantage of it
wait until MS forces this setting to be enabled all the
time, otherwise it's useless when it stays optional
not checking any more for the target OS in the application,
assuming Win 10 with the mentioned update
The latter will only be the case when an app can't target an
Windows version below 10. So all in all it will take years
until we get the advantage for standalone applications, and for
TC these things don't matter for now anyway.
"
enum size_t MAX_PATH = 260;
MAX_PATH only applies to static arrays (usually on the stack),
i.e. code which does this:
void doSomething()
{
char fileName[MAX_PATH];
...
SomeWindowsAPI(fileName);
}
D almost never does this - instead, it uses dynamically sized
buffers which fit the entire file name. The only times MAX_PATH
is used in Phobos is:
- thisExePath (return path to current .exe file)
- tempDir (return path to temporary directory)
Obviously neither of these is related to the problems you're
seeing.
