[fpc-devel] Forwarded message about FPC status

[Marco van de Voort]

In our previous episode, Hans-Peter Diettrich said:
> >> and component libraries to the new strings, RTL and LCL? IMO a typical 
> >> loose-loose situation :-(
> > 
> > ? No, the old RTL will remain maintained. It's the same codebase, just 
> > recompiled.
> 
> Sorry, I doubt that it is so easy :-(

Just a quick memory dump (as said it has been 6months since issues like this
were discussed in depth):

It is not a blind recompile of course. Everywhere where character access is
done has to be reviewed.

But any FPC rtl has some 2-byte and 1-byte support, so the amount of code to
be added is not that much. At least not till e.g. compiler structures like
RTTI will follow.

Like always with Delphi compatibility, the level of compatibility differs
greatly with what you expect.

Usually first the main support is added (the ability to have unicodestring
as a basetype for RTL and class hierarchy), other things follow later. That
is something else then being fully D2009 compatible.

So initially there will probably conversions when you pass a string to units
that have many stringroutines (like dateutils,strutils, sysutils, fmtbcd
etc), new utility units in Delphi will be missing etc.

But I hope it will be enough to allow Lazarus (and other big projects) to
start working on conversion.

The process then continues (with every issue discussed, checked and
doublechecked) with the other remaining defects, and probably some effort
will need to be made to kill excessive conversions (like on windows utf16 ->
utf8 -> utf16), RTTI, Literals
(if delphi literals are utf8, it will
probably be only a matter of time till a bug is found because sb is poking
with pointers in it), new delphi units etc etc.

You can also imagine that just the task of checking and fixing the windows
headers for all $ifdef unicode cases is daunting. (we are still fixing heaps
of 64-bit issues in them, 9 years after the initial 64-bit port)

The current logical next step is to start revising the OS interface to be
unicode, mainly on Windows. 

That alone (the fact that the windows unit swaps to unicode calls by
default) is a horrible incompatible change.