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. So do you think that the Ansi RTL should not exist? Or you just think it should exist, but in disgrace, using obsolete APIs and with APIs which don't work properly to get people to give up on it? It has already been clearly stated that the Ansi RTL will not be deleted, and this RTL will not follow Delphi Unicode (because that would break compatibility). So if we will have an Ansi RTL, then people that use it intensively should be allowed to improve it. Make it respect SetMultiByteConversionCodePage fully and make it work reliably, make it support UTF-8 and use newer APIs when possible. Like my proposed patch does for improving the Unicode support of TStringList.LoadFromFile / SaveToFile. -- Felipe Monteiro de Carvalho _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
