
This document describes how the console works around the fact
that it uses OEM fonts, GDI uses ANSI glyph mapping, and the
console internals are Unicode.

Here is the problem.  The character mappings described below
are not accurate, but demonstrate the problem.

        OEM     ANSI
0xba    ~       !
0xc0    $       *

        OEM     ANSI    Unicode
~       0xba    0xc0    0x2047


    WriteFileA(0xba);                                   // console client
    ConvertToUnicode(OEM codepage,0xba) -> Unicode 2047 // console server
    ExtTextOut(2047)                                    // console server
    glyph mapper sees that we're using an 8-bit font    // gdi server
    ConvertToAnsi(ANSI codepage,2047) -> 0xc0           // gdi server
    look up c0 in font to get glyph -> $                // gdi server

$ gets written to screen instead of ~.

The ideal fix to this problem is to use Unicode fonts, but the only
unicode fonts are TrueType, which look terrible in small dimensions.

One workaround considered was having GDI look at the type of font
being used and pass the correct codepage to ConvertToAnsi.  The GDI
group thought that since the console was the only important app that
has this problem, that the workaround should be done in the console.

The workaround agreed upon takes advantage of the fact that if the
same codepage is used for both the 8-bit -> unicode and unicode -> 8 bit
translations, the codepage used doesn't matter.  Applying this to
the console means using the ANSI codepage to translate OEM characters
into Unicode.  For example,  when an an app calls WriteFileA("~"), the
ANSI codepage is used to translate 0xba into Unicode, resulting in
the unicode value for "!" being stored in the screen buffer.

The unicode characters stored in the screen buffer data structure are
those generated by translating OEM characters into unicode using the
ANSI codepage (referred to as UnicodeAnsi in the code).  For 8-bit
output APIs, this means that the string is translated to unicode using
the ANSI codepage, then stored in the screen buffer.  For unicode output
APIs, this means that unicode string is converted back to 8-bit using
the OEM codepage, then converted to unicode using the ANSI codepage,
then stored in the screen buffer.

Input characters are stored in the input buffer as the true unicode
value.  This means that as they are echoed to the screen or written
from the command history, that they must be translated to UnicodeAnsi
by translating from Unicode to 8-bit using the OEM codepage and then
back to Unicode using the ANSI codepage.
