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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
