blob: c55c48ee820d6c84e9121099d39344ed6ad688a5 (
plain) (
tree)
|
|
This file describes the nature of DBCS support in ntldr/setupldr.bin for x86.
On non-x86 machines we do nothing for now. The firmware is in control of the video
and thus the firmware is supposed to support displaying characters deemed necessary
by the system designer.
The x86 loaders operate using either standard 80x25 vga text mode or standard
640x480 graphics mode. In the latter case the loader display system paints
characters to simulate a console-type environment. Text mode is the default.
Early in initialization, the loader attempts to open a file called BOOTFONT.BIN
on the root of the drive from which boot is occurring (ie, in the same place where
it later expects to find ntdetect.com, boot.ini, etc). If that file is found and
is deemed valid, the display subsystem switches to graphics mode and is thus able
to display arbitrary glyphs. The font file gives such details as the dbcs lead byte
ranges, and so support in the loader display system is not dependent on any
particular codepage.
Thus we achieve single-binary and the ability to fully localize ntldr and
setupldr.bin for any locale.
See boot\lib\i386\bootfont.h for the format of the bootfont.bin file.
Note that Setup will install bootfont.bin. If this file becomes corrupt or the
user deletes it, the ntldr will fall back to sbcs support via vga text mode.
For this reason, it may be desirable to include English message resources
(as well as the ones for the particular localization) in ntldr so at least
the boot selection screens will be readable in English and not just display
as garbage.
Still to do some day, issues, problems, etc:
- If non-x86 machines' firmware starts to support DBCS we should be able to
extend support to these machines orthoganally since the x86 implementation
is entirely 'hidden' in the ARC emulation layer. The only thing we would need
is a mechanism to 'trigger' dbcs mode, which is performed by the presence of
bootfont.bin on x86 machines.
- The ARC console is driven by control sequences that are introduced with 0x9b.
Unfortunately this is a valid lead byte char in several Far East code pages.
In Japan this doesn't bite us because we don't actually use any characters that
lead with 0x9b. The fix is to replace use of 0x9b with ESC[ (escape-left bracket)
which is a synonym. However we don't know if all ARC firmware out there
supports that as a synonym, so #ifdef _X86_ would probably be necessary
(that would be ok since we are not enabling dbcs for non-x86 machines anyway).
- tedm, 7/11/95, Tokyo
|
