[fpc-devel] Encoded AnsiString

[Marco van de Voort]

In our previous episode, Paul Ishenin said:
> > I don't think that this is a good idea, it means that e.g. 
> > TStrings.SaveToFile() or TFileStream.Create() is still crippled. 
> > Better bite the bullet. This is what I wanted to test in feb/march.
> 
> This will also mean that we will release 2.8 much later (looking at 
> cpstr development speed probably few years later) because together with 
> this implementation we need to solve ansi/unicode RTL problem (dotted 
> unit names in RTL and packages).
> 
> Imo it is better to release all that huge changes we have in trunk as is 
> (maybe together with resourcestring solution). Then with the following 
> minor releases we improve dotted unit names support (like default 
> namespaces) together with experiments for ansi/unicode RTL.

Having a base classes implementation that is unicode capable, can help with
e.g. fixing up TProcess to unicode over the 2.8 lifecycle and other simple
but crucial packages, and maybe even pioneer with fcl-db.

Doing this after the 2.8 branch makes trunk and fixes immediately
incompatible, which would make 2.8 quite an orphan.