>>> Another one is that MKEYB doesn't >>> report itself correctly as a "standard" keyboard driver to other >>> programs which can cause some compatibility problems.
>> no one complained so far. ever. in 15+ years. > Well, then consider this your first complaint. I don't use MKEYB for this > and other reasons. >> how would this report look like? > Look at RBIL, INT 2F.AD80 and related calls. > As Aitor alluded to, KEYB interacts with the various other things > in DOS (COUNTRY, DISPLAY, CHCP, NLSFUNC, ...). If KEYB doesn't > report itself through that mechanism the other DOS functions may not > work correctly. admittedly, I'm a german user, who had never anything then an US-ASCII keyboard, never used anything of the DISPLAY, CHCP, NLSFUNC family *ever* and so I am certainly not experianced on these things. how should a KEYB scancode->keycode driver react to copdepage changes, and how are these communictated? why would any other TSR need insight into KEYB installed/not installed state or a pointer to private tables? > But, it's usually only a problem if you try to > switch between languages or keyboard layouts or code pages on the > same computer, which very few people do. even then, I only see 'changing between keyboard translation and no translation' which MKEYB should support. > It's also a problem for other programs (including other TSR's) that > need to know the current keyboard layout for some reason (which some of mine > do). why would they want to know this? just pass around scancodes, and MKEYB will be happy. Tom _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
