[fpc-pascal] Unicodestrings and Assign(File)

Sven Barth pascaldragon at googlemail.com
Sun May 13 10:56:37 CEST 2012


On 12.05.2012 22:18, Jorge Aldo G. de F. Junior wrote:
> does TFileStream use the same code as assign ?
>
> you could create a TFileStream instance and then use AssignStream to a
> regular file type and keep on using plain old read/write...
>
> not tested here, but could be worth a try...
>

Currently the Windows RTL uses (nearly?) always the Ansi functions 
(exception might be WinCE as there the Ansi functions don't exist), so 
using TFileStream won't help here.

Regards,
Sven

> 2012/5/12 印場 乃亜<shiruba at galapagossoftware.com>:
>> 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 at lists.freepascal.org
>>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>>
>> _______________________________________________
>> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal




More information about the fpc-pascal mailing list