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]>
