On Tue, 7 Feb 2012, Felipe Monteiro de Carvalho wrote:
On Mon, Feb 6, 2012 at 9:35 PM, Sergei Gorelkin <sergei_gorel...@mail.ru> wrote:
So, this is basically a first step of locking Windows RTL to use utf-8 by
default
No, it will not use UTF-8 by default because that would break
compatibility. It will use the system encoding by default and you can
use SetMultiByteConversionCodePage to change it to use UTF-8.
And this is not about just about Windows, but all platforms of the
Ansi RTL. Just that most other platforms are already using APIs which
can handle Unicode so they don't need changes.
SetMultiByteConversionCodePage is not specific to the Windows RTL.
and reducing chances it ever will call 'W' API without conversions?
This is a very strange argument. You cannot oppose something by
arguing that then it will be successful and people will not want to
implement your way. There are no such barriers in a volunteer led
project. If someone wants the UnicodeString RTL ... he can write it. I
am not against another RTL existing which will use UnicodeString or
which will use 1 different string in each platform or 1 different
string for each weather condition. But I just don't want to use it. I
want to use the Ansi RTL + SetMultiByteConversionCodePage to make it
UTF-8 capable, so that's what I am writing.
Let me intercede here:
The plans are already laid out.
The ANSI RTL will be exactly that: ANSI;
No unicode or UTF-8 hacks will be added to it.
The planned unicode RTL will be unicode, and by corollary will support UTF-8.
So any patches to "utf8-enable" the Ansi RTL will not be accepted.
You'll have to wait for the unicode RTL or start work on it yourself.
If you want, I can send you the details in private, and you can decide for
yourself what to do.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
