21 Jan
2011
21 Jan
'11
11:23 a.m.
On 20.01.2011 23:58, Ian Emmons wrote:
What I intended here (but forgot to say explicitly -- sorry) was that Microsoft could allow a process (or thread) to set its local character set to UTF-8. Then all existing code that pays attention to the narrow representation would find that it is UTF-8 and deal correctly with it.
Naturally, this migration would take time -- but Microsoft has done that before. They successfully transitioned a large developer base off 16-bit Windows and onto 32-bit Windows (and, incidentally, introduced the wide character API at the same time). Won't happen. Follow the links here.
http://blogs.msdn.com/b/michkap/archive/2006/10/11/816996.aspx