In our previous episode, dmitry boyarintsev said:
> > RTLString.
> >
> > This sets a precedent.
> 
> Could you please resolve the issue with "won't be accepted" (or no
> changes required)?

It's not my decision alone. The whole problem with this unicode string is
that there is no definitive roadmap, and the utf-8 ansistring is not ready.
 
> The implementation is not only about RTL encoding, but system
> environment as well, since it depends upon Windows *W function to be
> available.

True, but I'm not going to commit anything Windows only till the plans for
the system environment are clear. On all relevant platforms.

> But who cares about 9x these days?! :)

I don't. But that is not even a problem;

FPC has prepared long for this by having and UNICODE define in most
windows headers. (afaik Peter already did when he translated windows unit
originally), but specially the older bits are not test and probably full of
bugs.

In theory, we could have a win32u target that sets UNICODE and switch the
default of most functions to unicode, like D2009+. It is probably going to
happen that way anyway, sooner or later.

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to