[fpc-devel] Changing Windows API A routines in SysUtils to W in Windows NT

[michael.vancanneyt at wisa.be]

On Tue, 7 Feb 2012, Felipe Monteiro de Carvalho wrote:

> On Mon, Feb 6, 2012 at 9:35 PM, Sergei Gorelkin <sergei_gorelkin at 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.