[fpc-devel] String handling in trunk (was utf8 in 2.6.0)

[Michael Van Canneyt]

On Sun, 6 Jan 2013, Hans-Peter Diettrich wrote:

> Michael Van Canneyt schrieb:
>
>>> IMO resource strings are for display purposes, so that UTF-8/16 encoding 
>>> is expected by an OS API.  AFAIR Win32 string resources are stored in 
>>> UTF-16,
>> 
>> You are very much wrong.
>
> Not really. I was talking about Win32 resources, not about what FPC makes 
> from resourcestring.

The discussion is about unnecessary conversions in *FPC resourcestrings*, 
not about win32 resources.

Why you brought up the Windows resourcestrings was (and is) a mystery to me.
>From your statement, I assumed that you probably thought FPC stores it's 
resourcestrings as win32 resources. It does not.

>> To start with, resource strings are not stored as Win32 resources. 
>> Secondly, they are stored in the code as an ansistring.
>> 
>> The resource string of the above example is stored as:
>> 
>> .globl  _$PROGRAM$_Ld2
>> _$PROGRAM$_Ld2:
>>         .ascii  "Something\000"
>>         .balign 8
>>         .short  0,1
>>         .long   0
>>         .quad   -1,15
>> .globl  _$PROGRAM$_Ld3
>> 
>> Thirdly: in my apps, no UTF-8/16 encoding is expected by the OS. If it 
>> were, I would have used widestrings instead of ansistring to begin with, 
>> and in that case I would not have made any remark...
>
> I don't know which OS you're using, but the WinAPI uses UTF-16 throughout.

I use both windows and Linux.

You are mistakenly assuming that I am using Windows GUI calls or so. 
There is no GUI.

Probably the only call that cares about codepage is FileCreate(), and that is not done using resource strings.
For the rest, all is done using FileWrite() and sendto()/recvfrom().
Both do not care about encoding. They transfer bytes, that's it.

So I use ansistrings throughout.

And hence, resourcestrings being stored in unicode format would cause totally unnecessary conversions.

Michael.