[fpc-devel] Is calling the Windows Unicode APIs really faster than the ANSI API's?y

[Martin Schreiber]

On Friday 26 September 2008 12.30:27 Marco van de Voort wrote:
> In our previous episode, Martin Schreiber said:
> > Hmm, you should ask the Russian users for example if they prefer MSEgui
> > utf-16 internal encoding or Lazarus utf-8.
>
> Users always look short term, and want to change as little as possible.
>
> This goes both for UTF-16 (with the "is UCS2" approximation and keep the
> old ways of string indexing) as for UTF-8 (as superset of ansi, avoidance
> of multiple file types (no endianess)).
>
> Note that e.g. source ocde seems to go en masse in the direction of UTF-8
> (Even Tiburon, which works exclusively on Windows, an UTF-16 platform,
> saves source default to UTF8 afaik).
>
As does MSEide, source code is stored in the current locale encoding or utf-8, 
the latter is preferred. MSEgui stores ini files and the like in utf-8, the 
form definition files (*.mfm, the MSEgui equivalent of Delphi *.dfm) are pure 
ASCII.
For DB access MSEgui converts from utf-8 or the current locale encoding to 
utf-16 while fetching the data from server and converts back to utf-8 or the 
locale encoding before writing data to the server. There is a switch in the 
connection and dataset components to select either utf-8 or the locale 
encoding. Strings in the dataset buffer are stored as variable length utf-16 
strings.
All this can be done with the currently available standard FPC 2.2.2 
widestring facilities. I have no problem if the FPC RTL supports the system 
encoding only, MSEgui has the commonly used interface  to the filesystem and 
other services with widestring parameters. If something is missing, it can be 
added to the MSEgui library.
But for internal character encoding where the users must work with, utf-16 is 
better suited than utf-8, I am happy that FPC will support a reference 
counted widestring type in Windows in future releases.

Martin