[Lazarus] Lazarus (UTF8) and Windows: SysToUTF8, UTF8ToSys... Is there a better solution?

[Marcos Douglas]

On Tue, Dec 24, 2013 at 3:18 AM, Hans-Peter Diettrich
<DrDiettrich1 at aol.com> wrote:
> Marco van de Voort schrieb:
>>
>> On Mon, Dec 23, 2013 at 06:52:21PM +0100, J?rgen Hestermann wrote:
>>
>>> Am 2013-12-23 11:32, schrieb Marco van de Voort:
>>>  > So I would say UTF16, and maybe, if there is demand, some can get utf8
>>> :-)
>>>
>>> The question is:
>>> Should FPC and LCL use a fixed encoding for all platforms
>>> or should the encoding be adapted for each WidgetSet/OS?
>>
>>
>> Not necessarily. Supporting both on both platforms is a sane reason too.
>>
>> One can't ditch utf16 because of Delphi compatibility. It will be hard to
>> ditch utf8 because of old Lazarus compatibility.
>
>
> In the meantime we have 2 Delphi compiler/RTL versions:
> - Ansi (Win32)
> - Unicode (UTF-16, multi target)
> and 4 GUI versions
> - VCL Win32
> - CLX
> - VCL.NET
> - FireMonkey
> summing up to 8 versions in theory, and 3 versions in practice.
>
> So what does "Delphi compatible" mean *really*?
>
> The FPC compiler supports multiple targets, and most probably can be managed
> to support both string types using the *same code base* (maintenance
> issue!). IMO this  does *not* apply to the libraries (RTL and LCL) and
> existing applications, where Lazarus counts as the most important and
> prominent application. We can be happy to have one single LCL and IDE
> version, which is already incompatible due to the use of UTF-8 strings
> instead of Ansi. Multiple versions, for compatibility with the other Delphi
> combinations, are beyond *development capacities*.
>
> This sheds a very different light on Delphi compatibility, meaning that a
> Unicode LCL and IDE can *not* be supported in parallel to the existing UTF-8
> implementation. Dumping UTF-8 would discontinue support for the *entire*
> range of *existing* LCL applications, i.e. loose all the current Lazarus
> users :-(
>
> So what should be the intended *audience* for a future Lazarus version?
>
> IMO the biggest group are old fashioned Delphi (D7) users, which want their
> existing Ansi/VCL code base supported *without* complications and
> incompatibilities introduced by the newer Delphi versions. The subject of
> this thread clearly indicates that UTF-8 is *not* a solution for this group
> of users.

I started this thread. My problem isn't to use UTF-8 on Windows... my
problem is use different encodings on the same code, ie, RTL <> LCL.

Use functions, always, to convert string between RTL and LCL and
vice-versa IHMO is wrong because the final code is confusing. In a
huge application you still need to think "here is UTF-8 or
ANSI/UTF-16?"

> Another important user group is targeting mobiles, where time will tell
> whether FM will ever succeed, or shares the fate of Kylix or VCL.NET. IMO
> these should be happy already with fpGUI or mseGUI, no need to raise another
> competitor in this area.
>
>
>
>> But if I have to chose to kill one, it is utf8. It is the lesser used
>> choice
>> for unicode strings INSIDE APPLICATIONS.  Yes, UTF8 is dominant in
>> documents, but
>> not in APIs.
>
>
> That's my conclusion as well. But is that new audience worth to abandon the
> entire existing Lazarus audience?

Of course nobody will abandon the entire existing Lazarus audience. If
the RTL will be UTF-16, UTF-32, whatever the Lazarus will continues --
I think -- working using UTF-8.

Marcos Douglas