Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

In reply to : Bret 'll have to hate FreeDOS mKEYB, too (Developers)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 18.05.2011, 18:14

> ;FAKE A KEYBOARD KEYSTROKE USING METHOD 2 (WORKS WITH MOST AT KEYBOARDS)
>
> IMHO this is exactly the way your code should work, and will work nicely
> both with the default BIOS, and with existing international keyboard
> drivers
In my experience, Method 2 has NEVER worked reliably on ANY of my test computers. It completely locks up some computers, especially older ones. I have even considered removing it as an option since it is so unreliable, but I keep it because it might work for others even though it never has for me.

Method 1 is the best one to use if the BIOS HW supports it. The Method 1 function should exist on all modern hardware, but it doesn't, especially on laptops. Method 3 is the only one that even has a chance of working on all computers, but even it doesn't work all of the time -- sometimes it needs the BIOS INT 09 code replaced (which is what MS KEYB does).

> there is no such thing as a 'keyboard language'.
> INT 2F.AD80h reports the 'language' of the keyboard *driver*
You're correct there. Drivers are all we can talk about, since the KB HW never lets you know what it looks like, and (on most keyboards) you can physically move the printed parts of the keys around so they are located wherever you want them to be.

RBIL (and probably MS) refers to it as a country, I prefer to call it a keyboard language. Calling it a country doesn't really make sense, because, e.g., there are two different layouts for Brazil (and Italy and others), but there is only one of each of those countries. Also, even though I live in the country of USA, I sometimes load a driver for one of the Brazilian keyboard languages when I need to type a lot of accented characters. The physical layout of the Brazilian keyboard driver language is exactly the same as the US keyboard, but the Brazilian keyboard language has dead keys that make it much easier to type accented characters.

We can call it a "keyboard driver language" instead of a "keyboard language", or something else, if you prefer. Whatever you want to call it, it is the concept of how scancodes are translated into ASCII codes. Further down, you call it an abstraction, and we can use that term if you want to next time.

> there is also no such thing as a 'keyboard layout'.
> hitting the key between 'T' and 'U' produces the exact same scancode
> on each keyboard in known universe;
> it's translated to 'Y' in america, and to 'Z' in germany.
> not the 'Y' or 'Z' keys are are changed in the layout, they were only
> labeled different, and are transleated accordingly by the keyboard driver.
Quoting INT 15.4F from RBIL: "called by INT 09 handler to translate scan codes" ... "This permits software to rearrange the keyboard; for example, swapping the CapsLock and Control keys" ...

What would you prefer to call this, if not a "keyboard layout"? BTW, RBIL never says, or even implies, that INT 15.4F can be used to change the keyboard driver language (or abstraction or whatever it is you choose to call it).

> what's even the relation of int15.4f to int2f.ad80 ?
INT 2F.AD80, and the other INT 2F.AD8x functions, are how keyboard language drivers are supposed to interface with the "outside world" (the OS itself and other programs). They aren't supposed to be related, because INT 15.4F isn't supposed to have anything to do with the keyboard driver language. Because your (and other) drivers are acting as "KEYB surrogates" using INT 15.4F to "create" a keyboard language driver, however, they must use INT 15.AD8x to let the rest of the world know that they are installed and what keyboard driver language is currently being used.

Look at the other INT 2F.2D8x functions in RBIL. E.g., it is possible for the user (or a program) to request a change in the code page any time they want to. KEYB (and KEYB surrogates) are supposed to monitor and respond to INT 2F.AD81, which is (or at least is supposed to be) called by MS DISPLAY.SYS (or whatever the DISPLAY.SYS surrogates are in the various DOS versions). If the user (or a program) tries to change the code page to one your driver doesn't support, and you don't respond appropriately, you could be in trouble. If you don't monitor INT 2F.2D81, you must instead poll the system to determine the current code page each time you perform a scancode-to-ASCII translation, at least for ASCII characters > 127.

KEYB surrogates are also supposed to respond to INT 2F.AD82 & 2F.AD83 to be able to report and toggle themselves between the "foreign" keyboard driver language and the default (US) keyboard driver language (this basically turns the driver on and off). If the keyboard driver language supports multiple sub-mappings (e.g., the Greek keyboard driver language has a "Greek mode" and a "Latin mode"), the driver must monitor and support INT 2F.AD84 & 2F.AD85 to be able to toggle between the sub-mappings.

I know RBIL refers to these functions as specifically related to KEYB.COM, but they are in reality "system level" calls that the OS and other drivers (like DISPLAY.SYS) depend on for compatibility. KEYB surrogates must also support them.

> 'other programs' shouldn't care if this is written using a german or US
> keyboard. this is called an 'abstraction'.
RBIL certainly doesn't call it an abstraction -- they call it a country, and I'm pretty sure they get that language from MS and/or IBM. But we can call it an abstraction if you want to -- it doesn't change the concept or separation that is there between what INT 09 is supposed to do and what INT 15.4F is supposed to do.

> BTW: simulating a keyboard interrupt, and then single stepping it to
> modify scancodes is an heroic attempt to solve the problem, but probably
> overkill
As stated earlier, it's the only method I've found that even comes close to working reliably on all computers. I consider SMM overkill, but it may come to that someday the way the hardware is changing. I'm not 100% sure about this, but I don't think SMM is emulated in virtual machines, either.

BTW, the single-stepping method is what at least some of the commercial DOS remote control programs used (Carbon Copy, CO/Session, LapLink, etc.).

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 218 users online (0 registered, 218 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum