> how should a KEYB scancode->keycode driver react to copdepage > changes, and how are these communictated?
Well, first of all the keyboard driver should detect the current Code Page on installation and not just assume one. And, the KEYB program should work with multiple code pages when it can. If DISPLAY.SYS is installed, you can use INT 2F.AD00 and INT 2F.AD02 to detect the current Code Page. If DISPLAY.SYS is not installed, you can use INT 21.6601. If neither of these work, you should assume code page 437 (which is the default on most systems). DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to inform KEYB so it can change its mapping. > why would any other TSR need insight into KEYB installed/not > installed state or a pointer to private tables? Unless the tables are in a "public" format, the data contained in the tables is irrelevant. E.g., MS KEYB and FreeDOS KEYB tables do not use the same format. I'm not sure about any of the other DOS's out there, but wouldn't necessarily expect them to be the same as MS. The reason that other TSR's (at least mine) may need to know what the keyboard mapping looks like is because they need to do an "ASCII-to-Scancode" lookup. That is, the program allows the user to provide an ASCII code as an input parameter (since ASCII is far easier for the user to enter than a scancode), but the program itself uses the scancode. My SCANCODE program, e.g., "types" scancodes automatically (it is useful for creating "macros"), but the user can tell SCANCODE what to "type" with ASCII codes. To do this, SCANCODE needs to know what scancode(s) to type (what physical key(s) on the keyboard to press) to generate the ASCII code the user wants to see. For example, if you tell SCANCODE to type a "Z" it will press the shift-key, press the "z", release the "z", then release the shift-key. But, it needs to know where the Z key is on the keyboard to do that, and the Z key is in different places (different scancodes) depending on the keyboard layout and, in some cases, the code page. So, it has internal tables of a bunch of different keyboard layouts so it knows how to "type" the different ASCII characters. It would be nice if SCANCODE could somehow "ask" the KEYB program what its tables look like, but that's not really feasible. I realize you may think "typing" scancodes may be a "silly" thing to do, but there are cases where it works and ASCII codes do not (e.g., SCANCODE is able to "type" into older DOS-based versions of Windows, and can actually "type" things like PrintScreen or Pause or the multimedia keys or the Sleep/WakeUp/ShutDown keys that some keyboards have). Another kind of TSR that needs to know is a TSR that has some sort of "hot-key" to enter into the TSR as it is running to make configuration changes. My CLOCK and SERIAL programs do this. TSR's usually (though not always) monitor scan codes for hot-keys rather than ASCII codes, but the user usually enters the hot-key as an ASCII code. The current versions of CLOCK and SERIAL simply assume the keyboard is a standard US QWERTY layout, but I'm in process of changing them to be "keyboard-layout aware"). To do this, they need to know the current keyboard layout so they can do the "ASCII-to-Scancode" lookup using the internal tables. If the KEYB program doesn't identify itself using INT 2F.AD80, the TSR's don't know what the current keyboard layout is, and the user will get frustrated because the keys they are supposed to press on the keyboard are in the wrong places. What this boils down to is making it easier on the user, trying to make things as "automatic" as possible, even though it can make it MUCH harder on the programmer. BTW, this brings up another issue I've been trying to figure out regarding keyboard layouts. There are two different parts to the keyboard layout identification -- there is a two-letter code (for example, US = United States), but most keyboards also have a code number to go along with that (for the US keyboard, it is 103). But there are also cases where the there is more than one keyboard layout for the same two-letter code. An example of this is Bulgaria (BG) which has three different layouts with three different numbers (103, 241, & 442) even though they are all "BG". Unfortunately, the standard KEYB interface (which MKEYB doesn't use) only tells you the "BG" part and doesn't tell you the number part. Does anybody know of a way to automatically/programmatically determine the number part of the keyboard ID from KEYB? _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
