On Tue, 26 Feb 2019, Yuriy Sydorov wrote:
On 25.02.2019 20:03, Bart wrote:
On Lazarus, this no problem, since by default all strings are UTF8
encoded, so all conversions are lossless.
In a plain fpc program though on Windows, default encoding is the
current codepage (cp1252 in my case) and information will get lost
when you process the result further.
If you just recompile unmodified non-unicode app for Windows, string data
loss is imminent if the data is not encoded
using the current ANSI encoding. Even if you use UnicodeString parameters and
result for registry functions.
Just adding a single line to the beginning of the app will solve the data
loss:
DefaultSystemCodePage:=CP_UTF8;
I would leave the registry parameters and results as "string" as it is done
in other parts of RTL/FCL.
For performance critical functions it is possible to add an overloaded
versions of functions which accepts UnicodeString
parameters. IMO the registry access is not the time critical.
My proposal exactly.
But inner workings can be made to use Unicode, because the underlying APIs
are using unicode: The *W registry calls on windows, XML DOM on other systems.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
