> As you know, we are very keen on backwards compatibility.... Ummm, I'll need to investigate that. But if it seams risky we could always add "and (DefaultSystemCodePage = CP_UTF8)" to the if, which would disable it for legacy code and enable it only for Unicode applications. If you use SetMultiByteConversionCodePage then you are clearly saying you desire Unicode support.
On Mon, Feb 6, 2012 at 7:39 PM, Thaddy <tha...@thaddy.com> wrote: > IMO This should not be done that way (at all): > MS does it by respecting the PE flag for unicode and expects strings > accordingly: If the PE says it's unicode, a default string should > be unicode, (so apiW) if the header says ansi the default should be apiA. The Microsoft way is not the same as the Free Pascal way. We are not required to immitate them when implementing our routines. The Microsoft way has nasty side effects: 1> makes it impossible to support Unicode and support Windows 9x at the same time, but I doubt that Free Pascal wants to drop Windows 9x support (even if it is obsolete). 2> Breaks the interface because the string type changed -- Felipe Monteiro de Carvalho _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
