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
