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

[Hans-Peter Diettrich]

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.

> 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 suppose that other OS also use some Unicode string 
representation, for lossless representation of texts of all languages.

The dual W/A interface of Win32 is due to the stripped-down Win9x 
versions, which require Unicode extensions for supporting more than 
CP_ACP. But now we are in 2013, with Unicode being present everywhere.

> So the conversion really would be 100% totally redundant.

It may look so to you...

Why then do you use resourcestring instead of ordinary string constants?


Another note and question, about multi-lingual resources. Windows 
resource scripts (.RC) allow for multi-lingual stringtables. In my 
recent research I learned that the resource compiler extracts the 
requested language from the script, and stores only these strings in the 
resource file (.RES) and application (.EXE, .DLL). That's why 
resourcestring was added to Delphi.

How does FPC support the same? (.PO files?)

DoDi