> codepage is a display thing, essentially it's the table how to > convert 8-bit bytes into a visable character set, and mostly > unrelated to the way the keyboard driver converts scancodes into > bytes.
The Code Page and the Keyboard layout are not unrelated at all -- they are HIGHLY related. Mateusz provided a Polish example, but probably the more common one is the Euro symbol. Cod Page 850, which was the "original" one for western Europe, didn't have a Euro symbol -- the Euro didn't even exist when when the Code Page was first developed. Code Page 858 is Code Page 850 with the "dotless i" (ASCII code 213 or D5h) character replaced by the Euro symbol. In other Code Pages the Euro symbol is not in the same place as it is on 858, and many Code Pages don't have the Euro symbol at all. KEYB needs to know what ASCII code is (or even if there is one on the current Code Page) for the Euro symbol if the user presses the appropriate keys to generate the Euro symbol. US/English-only users almost never even need to worry about these kinds of things. BTW, there are also Code Pages for printers which are managed by PRINTER.SYS, but that is even a much bigger can of worms than keyboard layouts and display Code Pages. > of course a brasilian KEYB might produce different values for á then > a french KEYB (I don't know), but they still produce the same value > consistently. No, they don't, unless they are using the same Code Page. > please provide an example where this is necessary AND plausible. See above. A user who speaks/writes in multiple languages would need/want something like this. E.g., Thraex, who has been helping some people (including me) recently with language translations, speaks/writes English, French, and Turkish. I've never inquired of him exactly how he manages the different languages on the same computer (and he may not even do that in DOS -- I'm not sure). Even though the vast majority of users will not have issues, there are some users who would need/want the ability to change things around. In my case, I swap things around for testing to try and make my programs are "international friendly" if there's a way to do it. I wasn't as concerned about this in the past as I am now, but it seems like a good way to go. > nope. you intend to do "ASCII-to-Scancode" lookup, then feed these > scancode to the KEYB program, in the hope that this KEYB program > converts it back to the same ASCII character that you started with. Do it merely "hoping" that it will work? I need to KNOW it will work before I start "typing" anything that can potentially screw up something the user is doing. > there's a BIOS call for this: > KEYBOARD - STORE KEYSTROKE IN KEYBOARD BUFFER (AT/PS w enh keybd > only) ... Uh, no, that won't help. That provides a scan code AFTER it has already been pressed, and only works with scan codes that produce ASCII codes -- not all of them do. Plus, you can have situations where there is not a unique set of ASCII/scan code combinations. E.g., ASCII 13 (Carriage Return) can be generated by Enter, Grey Enter (on the NumPad), Ctrl-M, Alt-013, and maybe other ways too. If the user tells me to "type" an ASCII 13, which key(s) do I use? > otherwise you have to implement what the KEYB program does in > reverse direction. not only different scancodes with different shift > states, but also dead keys: á is produced by hitting ´, then a; à is > produces by holding SHIFT, hitting `, hitting a, releasing SHIFT. > for the german keyboard at least ;) Exactly. That's why I need to know what the keyboard layout is, including things like dead keys. There are also some keyboard layouts with more than one mode (like various Hebrew, Cyrillic, & Greek ones) where there is a "Latin/English Mode" and a "Foreign Mode" and pressing the "a" key when it's in Foreign Mode doesn't generate an "a". > yes that's complicated. how about sending 'Z' to the program? Because some programs don't look at the "Z" -- they look only at the scan code and don't even care about the "Z". You're correct that most programs only look at the "Z", but SCANCODE will work both with programs that do and those that don't. SCANCODE can even "type" the correct keystrokes it takes to switch the keyboard between the English and Foreign modes (Ctrl-Alt-F1 & Ctrl-Alt-F2) which you can't do with ASCII codes. > there are enough 'non-controversial' keys to use for hotkey; just > use B-X and avoid Q. No, there are enough controversial keyboard layouts to make it a big problem. The main keyboard layouts I'm aware of that are VERY different than "common" keyboards are Dvorak, Dvorak Left-hand, Dvorak Right-hand, Colemak, Bulgaria (BG) 241, and Turkey (TR) 440. They are not commonly used, but there are DOS drivers for them (in FD-KEYB) and they are used by some people. There are also keyboards where even the number keys at the top of the keyboard are different, not just the letter keys. Knowledge of the current keyboard layout is an important, not a trivial, thing. _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
