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

[Hans-Peter Diettrich]

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.

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?

DoDi