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 Pound_Sign, while Text_IO.Put( Character'val(156) ) will indeed display a Pound_Sign.
One may claim that this is a Microsoft problem, rather than an Ada problem, 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 put.
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 routine 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 Microsoft-supplied routine OemToCharA to set up an Ada.Strings.Maps.Character_Mapping that will map each OEM Graphic Character into the proper Ada.Characters.Latin_1 character.
Note, that both Microsoft-supplied routines seems to have a problem with non-graphic control-characters.
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 box-character, number 254 in the OEM-characterset, a symbol not otherwise used in Ada.Characters.Latin_1.
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.
In Ada.Characters.Latin_1, 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 order ÆØÅ.
Probably, obtaining a true alphabetic ordering of strings is a complicated affair.
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.
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.
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 Win32Ada.
GNAT users may obtain the same by using the linker-option "-luser32".