<p>Am 07.09.2013 16:19 schrieb "Jürgen Hestermann" <<a href="mailto:juergen.hestermann@gmx.de">juergen.hestermann@gmx.de</a>>:<br>
> > My question is: should DoDirSeparators handle this case and leave the<br>
> > filename untouched if it starts with '\\?\', or should we leave it up<br>
> > to the programmer not calling functions like ExpandFilename if a<br>
> > filename starts with '\\?\'<br>
><br>
> In general I would prefer if this '\\?\' prefix is hidden away from the programmer at all. File names should be just that: File names. On windows *every* API function that expects file names should be prepended with '\\?\' internally while for Linux this should be omitted. But the programmer should not need to know about this. Internal functions that use WinAPI calls should add the prefix theirself in all cases(!) (if supported) and omit it for Linux. For all situations where the file name is moved/converted from one function to another (when no OS-API functions is involved) it should just leave the name as it is.<br>

><br>
> I have written my own functions which do this because it is a nightmare to find out which kind of string encoding is expected/required by what function within FPC/Lazarus. The documentation just says "string" but never says whether it is UTF8, UTF16 or whatever. So when I want to be sure what happens I have to reinvent the wheel and write my own OS independend functions which in my case *always* expect UTF8 (which is my standard encoding in all situations) and convert to UTF16 and add the prefix '\\?\' when feeding it to a WinAPI function:<br>

><br>
> function WinAPIPathName(const Pfad : UTF8String) : UTF8String;<br>
> begin<br>
> Result := Pfad;<br>
> if (length(Result)<=3) or<br>
>    (Result[1]='\') and<br>
>    (Result[2]='\') and<br>
>    (Result[3]='?') and<br>
>    (Result[4]='\') then exit;<br>
> if (length(Result)>=2) and<br>
>    (Result[1]='\') and<br>
>    (Result[2]='\') then      // UNC-path, i.e. "\\server\share"<br>
>    begin<br>
>    Result := '\\?\UN'+Result;<br>
>    Result[7] := 'C';<br>
>    end<br>
> else<br>
>    Result := '\\?\'+Result;<br>
> end;<br>
><br>
> which I then call like this:<br>
><br>
> H  := FindFirstFileW(pwidechar(UTF8Decode(WinAPIPathName(Pathname))),FW);<br>
><br>
> This way I don't need to bother about path lengths and unicode issues. I just use UTF8 in my programs. And when I need other encodings I know that I have to convert them before calling functions that need UTF8.</p>

<p>The "\\?\" paths don't support relative paths and also not all I/O-APIs support this convention. </p>
<p>In my opinion a programmer needs to know the quirks of the platforms he/she wants to target.</p>
<p>Regards,<br>
Sven</p>