Back to home page

DOS ain't dead

Forum index page

Log in | Register

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, 17.05.2011, 18:10

> this is clearly not "any" program, but a program that reboots the system in
> a SMARTDRV compatible way

That's true, but the point is it's a program, written by MS, that calls INT 15.4F from outside the INT 09 handler. Ergo, MS thinks it's OK to issue an INT 15.4F from outside the INT 09 handler, at least for Ctl-Alt-Del.

The only question, at least in my mind, is whether MS thinks Ctl-Alt-Del is the ONLY keystroke that can be "simulated" this way from outside the INT 09 handler. Nothing I've ever seen from MS or IBM, including official documents like the IBM Technical Reference, leads me to believe that INT 15.4F can ONLY be called from inside an INT 09 handler. In fact, quite the opposite. This simply seems to be an (incorrect) assumption that a lot of people have been making for a long time, though maybe somebody is privy to something I'm not.

> as already said: I'm not able to follow your reasoning; why exactly should
> it not call INT 16.5 (besides common DOS/BIOS reentrancy problems)

The reason is because if you call INT 16.5, or modify anything in the BDA, or anything like that, but the INT 15.4F did not come from inside the INT 09 handler, you will be "typing" something that didn't actually come from the keyboard. At best, this would be an annoyance to the user. At worst, it could cause catastrophic data loss (depending on exactly what the scancode actually was and what program was running at the time).

***

As I alluded to earlier, the reason I'm so concerned about this issue is because of virtual keyboards, like USB. I have several of these kinds of programs, and I sometimes try to make them automatically "sense" the current keyboard language so that they can "adjust" themselves and make sure that what comes out at the end is what the user is expecting to happen.

Based on everything I've seen from MS, the scancode-to-ASCII "translation" is supposed to occur completely inside the INT 09 handler. The purpose of INT 15.4F is simply to allow the user to move keys around on the keyboard (e.g., switching where the Ctl and CapsLock keys are located), not to actually manipulate what the keys do.

As another example, look in RBIL at how INT 2F.AD80 (the "official" KEYB API) is implemented. The data structure returned by this function includes the old INT 09 vector (which means it expects/requires it to be implemented as INT 09), and includes a two-letter abbreviation for the keyboard language. This two-letter abbreviation is what defines the scancode-to-ASCII translation, and is what other programs are supposed to use to determine the current keyboard language (not necessarily the keyboard layout, which can be manipulated by INT 15.4F, but the keyboard language, which is the scancode-to-ASCII translation).

It should be noted, however, that this is an incomplete solution because it requires a standard two-letter abbreviation for every possible keyboard language. There are several "documented" abbreviations, but anybody who wants to can create their own keyboard language that doesn't exactly match any of the existing ones. That's an issue that should be addressed. but doesn't negate any of the above conclusions.

 

Complete thread:

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