The console itself is still a graphical user mode app; it or a DOS box simply uses a DefConsoleProc (sic) instead of DefWindowProc behind the scenes to manage the GUI aspects and system menu, and may use an OEM code page instead of an ANSI one in full screen mode. Windows may eventually be able to boot to a native mode full screen console instead of explorer, but that is real low on the priorities list, afaik.

The primary bar to using braille in the installer, that I see, is that it requires at least two code pages to represent various text and line delimeters and the 8 dots of graphics defined for it, or G0, G1 and G2 charmaps for systems that support ISO-2022, and the installer is only designed to use one code page, that maps to one defined GL and GR charmaps as inputs, for ANSI code pages. This is because no video card or terminal I'm aware of currently supports multi-byte encodings at power up / boot time as a hardware limitation, not software; at most a BIOS may use additional graphics for chars that index into the C0 and C1 charmaps on output, like with VGA/VESA's support for CP437.

The assumption has been boot time applications like installers would limit themselves to ISO-646 variants like ASCII, to make writing BIOS ROMs easier. People needing special peripherals like braille bump printers or bump scanners would have these supported once a sighted person configured their system for them.

------ Original message------

From: Erkin Alp Güney

Date: Wed, Nov 14, 2018 12:49 PM

To: ros-dev@reactos.org;

Subject:Re: [ros-dev] no replies about making reactos accessible for the blind