Oddly, Ada applications for Console-mode under Windows 9X and NT
have problems with any characters outside ISO646, that is above 127.
When such a character is read by Text_IO from the keyboard,
the application gets another character than the one pressed.
When such a character is written to the screen using Text_IO.Put,
the appearing image does not belong to the character that is put.
As an example, pressing the key for ú, and reading it by text_io
will give you a Pound_sign, Character'Val(163),
instead of the expected ú, character'Val(250).
Likewise, Text_io.Put ('£') will display 'ú' on the screen instead of a
while Text_IO.Put( Character'val(156) ) will indeed display a
One may claim that this is a Microsoft problem, rather than an Ada
since Microsoft has indeed designed Console-mode to work like this.
Anyhow, here is a Package Console_IO, containing procedures Put,
Put_Line and Get,
which respects Microsofts design.
Using Console.IO.Get_Line to read from the keyboard,
the application will in fact get the character pressed.
Using Console_IO.Put or Put_Line for screen output,
the appearing image does in fact correspond to the characters that are
As an example, reading the keypress for ú by Console_IO
will give you the expected character ú, Character'Val(250):
Likewise, Console_IO.Put('ú') will display a ú,
while Console_IO.Put('£') will display a Pound_Sign.
Regarding Output to the screen, Console_io uses the Microsoft-supplied
CharToOemA to set up an Ada.Strings.Maps.Character_Mapping that will map
each Graphic Character into the proper OEM-character.
Regarding Input from the Keyboard, Console_io uses the
OemToCharA to set up an Ada.Strings.Maps.Character_Mapping that will map
each OEM Graphic Character into the proper Ada.Characters.Latin_1
Note, that both Microsoft-supplied routines seems to have a problem with
Regarding output to the screen, CharToOemA, converts the non-graphic
control-characters in the range
(128..159) to seemingly random characters, often an underscore.
For these characters (128..159) Console_IO.Put will instead display a
number 254 in the OEM-characterset, a symbol not otherwise used in
It is well known, that Ada allows the comparison of text strings,
which is done by comparing the individual characters according
to their position in Ada.Characters.Latin_1 in lexicographic order.
Unfortunately, Ada.Characters.Latin_1, does not quite respect the
"normal" alphabetic character sequence.
Upper-case letters are placed before lower-case.
Any basic letter comes before any accented or national letters.
The Nordic letters ÆØÅ are comes in the order ÅÆØ instead of the proper
Probably, obtaining a true alphabetic ordering of strings is a
Package Alphabetical contains the function POS that goes a long way
towards this goal.
For any string Istring, Alphabetical.Pos(Istring) returns a string
Ostring is similar to Ada.Characters.Handling.To_Upper(To_Basic( Istring
)), with special
processing for one German and some Nordic Characters.
Sorting according to Alphabetical.Pos implies that characters with or
without diacritical marks
sort to same position, as does characters in upper or lower case. Also
that Nordic and German
letters are placed in their customary position.
The example procedure Test_Alphabetical.ada is included.
Test_alphabetical dependes on Console_IO, but Alphabetical.Pos does not.
Console_IO and Alphabetical are developed and tested using ObjectAda 7.1
under Windows NT.
I believe they will work under Windows 9X as well.
I believe they will work using GNAT as well.
An objectAda project using Console_IO needs a link of type "Linker-only"
to ..ObjectAda\Apilib. Otherwise, Console_IO does not depend upon
GNAT users may obtain the same by using the linker-option "-luser32".
Click Here to Download