In Windows, there are two separate 8-bit character sets: one for GUI apps, which Microsoft calls the "ANSI" code page; and one for the console, known as the "OEM" code page. (On a typical U.S. system, these would be Windows- 1252 (a superset of ISO-8859-1) and IBM Code Page 437, respectively.)

In adding wide-character support to PDCurses, I made the existing char string functions, like addstr(), into wrappers for their wide-char counterparts, like addwstr(). They convert between Unicode and the current 8-bit character set via the standard library functions mbtowc(), mbstowcs(), and wcstombs(). And I still think that was the right thing to do -- but only later did I realize that, for Windows, I didn't know whether these functions would use the ANSI or OEM code pages.

As it turns out, different compilers have implemented it in different ways. MSVC and MinGW use the ANSI page; Borland and Watcom use the OEM. I'm not sure there's anything to "fix" here, since neither behavior is incorrect per se, and either might be desired; but it's something to be aware of.

Note that this only applies to the library built with wide-character support, but without forced UTF-8 mode. The narrow-character build uses the OEM code page, as always; in this case, the char string functions are not wrappers, and the wide-char versions are not available.

William McBrine <[EMAIL PROTECTED]>

Reply via email to