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 Ninho E-mail, 16.05.2011, 15:10

> MKEYB FR and indeed it was hooking int 15 and int 2F. Had I known of
>> it before, I might not have embarked onto this boat

> I had wondered why you started it ;)

>> - mKEYB FR uses up 200 bytes more than my KBFR tho :=)
> not bad, considering the fact that mKEYB is 98% C, and handles 20 keyboard
> layouts ;)

Sure, I wanted to underline that mkeyb's code must be, i presume, table driven(?) and in any case prepared to handle many languages, while our driver can have optimised instruction flow for the unique keyboard layout.

>> Quick viewing of in-memory mKEYB code further seems to confirm it doesn't
>> chain int 15/4F.

> that's wrong.
> mKEYB chains most of the time, and only handles the (few) scancodes that it
> wants to modify. most work is done by the BIOS (in particular *both* DEL
> keys !)

Sure we want as much of the work as possible to be done by the BIOS, for which we IRET. This is not chaining :
I quick viewed mKEYB in memory (using the disassembler included in McAffe's proview), it didn't appear to /chain/ 154F (as in passing scancodes by calling or jmping to the previously installed int 15 hook). Either I mis-looked or there is a misunderstanding over the notion of chain. Please clarify.

Incidentally I also noticed you use int 16h for stuffing the buffer - I have reservations over such use (we do direct buffer handling); not because of reentrancy nor efficiency problems, but because calling int 16h at that point you don't know /who/ is going to mess with the buffer for good or bad. Either do it ourselves, or we could call the BIOS int 16 at its default entry point (per ISA quasi standard).

>> This being so, Bret's wrath should in good logic be directed at Tom
> Ehlert
>> (mKeyb) - we can only assume he was not aware of its existence either...

> IMHO Bret is plain wrong with
> 'INT 15.4F handler is not allowed to actually "process" any keystrokes
> or make any system changes at all (put ASCII codes in the keyboard
> buffer,
> make changes to the BIOS Data Area, etc.).'


I tried to put it less abruptly :=)

>>> Yes, Smartdrv is a little problem. I agree that a note in the
>> documentation
>>> is the best "fix".
> the fix is to chain the DEL scancode to the BIOS; no user will ever read
> documentation ;)

You have a point...

---
Ninho

 

Complete thread:

Back to the forum
Board view  Mix view
22756 Postings in 2121 Threads, 402 registered users (1 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum