Hi,
On 2012/05/12, at 18:31, Jürgen Hestermann wrote:
Noah Silva schrieb:
Thus, the only question would be whether you have to manually convert a
UnicodeString to a UTF8String or not.
No, that would not help. Under Windows you can access long paths *only* when
using special functions (i.e. FindFirstFileW instead of FindFirstFileA). And
these functions need unicode (widechar) paths strings with a prepended '\\?\'.
There is no other way to access long paths under Windows. Simply converting
Unicode to ANSI may let me use most (but not all) Unicode characters but the
paths would always be restricted to MaxPath (about 260) characters. Only when
using API functions ending with a W I can access longer paths (up to 32000
characters) and these
Ah, I forgot about that little detail. Given that, it doesn't really make
sense to use the *A versions at all in Windows (Unless you want to support very
old Windows versions). Thus the approach for Windows should be the opposite of
Unix, I suppose. UTF8 or ANSI gets converted to UTF16 and call the *W
functions.
string *must* be Unicode (widechar). So the RTL needs to be rewritten to allow
Unicode paths handed over without conversion and then use Windows API functions
with the W at the end.
I'm surprised this isn't available already. The 260 char path limitation is
pretty severe these days.
Because this is not the case (yet), I was wondering, whether it is possible to use other Windows API
functions like CreateFileW and then somehow connect them to RTL file data structures so that I can replace
"assign" and "reset/rewrite" by Windows API functions and then be able to use
"readln" on such (text) files.
I'm sure it's possible somehow since those structures probably track the
Windows file handle, but it wouldn't be very portable or future-proof.
Still, fixing Assign/Reset/Rewrite would be better than using Unix calls,
because you could submit a patch to save everyone else trouble in the future.
Yes, I would like to but neither time nor knowledge allows me to do that
currently.
I have the same time problem, but I will take a look at the source code, I
don't think it should be very difficult to figure out.
Thank you,
Noah Silva
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
