[fpc-devel] bug report 20473: Please add a directive to define string=utf8string

[Hans-Peter Diettrich]

Craig Peterson schrieb:

> In Delphi XE2 on OS X AnsiString does *not* map to UTF-8.  On an English 
> system it maps to "Windows-1252".  If you want to convert an "array of 
> AnsiChar" to a WideString you need to cast it as a UTF8String first.  By 
> default DefaultSystemCodePage is 1252, not 65001.

Well, XE2 is quite a different Delphi version, which probably is not 
mature yet. From the FPC view it could become just another mode, that 
works on OS X only with that specific RTL version.

But is it worth to configure or split FPC into any number of versions, 
which are fully compatible with specific Delphi versions (including 
bugs), in addition to the objfpc etc. modes?

When we include Lazarus in our considerations, then we have no fully VCL 
compatbile LCL yet, what's impossible for certain non-Windows 
widgetsets. Going ahead and changing the behaviour of FPC on those 
platforms, which had been supported before in the "FPC way", would break 
the LCL badly.

Instead I'd expect that the current LCL should be completed, or declared 
as completed, before taking the next step with a D2009+ compatible RTL 
and LCL. And in this move we should fix the Delphi flaws, residing in 
the Windows-only versions up to XE.

When somebody wants something compatible with Delphi XE2, he can start 
immediately to modify FPC accordingly - but please without breaking 
other code - and start implementing a new FireMonkey component library, 
independent from the LCL.

But are we dreaming right now, or are we about to take the *next* step 
in the FPC evolution?


BTW, I just found -Mdelphi documented as "Delphi 7 compatibility mode", 
how many further options had to be added for newer Delphi versions???

At least one new option/mode is required for Unicode Delphi 2009+, and 
this mode should not break any existing code (Lazarus, mseGui, fpGUI...).

And this new mode should be designed either in collaboration with the 
LCL maintainers, which may better know what changes deserve what efforts 
and breaks/forks in the LCL and Lazarus, or it should be designed as a 
mere option, for the implementation of other packages, component 
libraries or IDEs.

It should be worth to note that the Delphi IDE is no more written in 
Delphi.Win32, since the Delphi.NET experiment, but instead relies on 
.NET heavily. Perhaps a similar separation may be required with the 
Lazarus IDE, which must not necessarily use the new string types internally.

BTW2, the Lazarus IDE has big problems with the lack of dynamically 
loadable packages, which still are *not* supplied by FPC. This will 
possibly make impossible above separation between the IDE implementation 
and FPC progress. Wouldn't it be much more important to improve the 
package support, before experimenting with new Delphi features?

DoDi