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 - int 15/4F stuff (Developers)

posted by Ninho E-mail, 16.05.2011, 03:35
(edited by Ninho on 16.05.2011, 03:51)

Thanks for providing your advice. I've been soliciting remarks indeed and this is why I make kbfr a 'beta'.

Note however that it is Japheth's work you're criticising before being Ninho's, not that I want to elude responsibility, only I can't reply relative to Japheth's own intentions, just my take.

> I can't let Ninho's comments simply pass for fear that
> someone might actually try to implement something based on what he says.
The 'something' in question exists and has been in use since 1993 however. This may relativise your 'fear'. As for the French version, I am using it for typing this and quite pleased although I'm arguably not impartial.


Your article is trying to make 2 points, which I'll address in turn. There's good news and there's bad news, only maybe not so bad...


Bret's point #1 :

>> You do realise int 15/4F handlers execute as part of an int 9/IRQ1
> handler (...)
> This is not true.
Says who ? Not true, is : in your not so humble opinion.

According to Ralf Brown, int 15/4F is "called by INT 09 handler", providing a keyboard "intercept" (IOW a hook) used by software which wants to "rearrange the keyboard".

> INT 15.4F is indeed called by the INT 09 handler, but
> that is not the only time it is called. It can be called by any program at
> any time.

A rather personal, even excentric interpretation! "INT 09 handler" (R. Brown's word) is not quite "any program" !


> Because of this, an 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.).
Leaving apart "because of this", since as we've shown 'this'...is a fallacy;
now /you/ insist on calling int 15/4F, which is an abuse, then /you/ decide what int 15/4F is allowed to do to suit your abuse? That's too much if you ask me.

Don't get me wrong : I don't deny your right to (intelligently) twist standards to suit your fancy. But you must be prepared for all kinds of compatibility problems, and throwing bad words at others is not an answer either.

I will admit we (Ninho and Japheth) may be pushing things a bit, but a mere trifle compared to your admission of /calling/ int 15/4F. You and we alike are doing non standard stuff, yours more than ours. Together you and us may examine if and how compatibility can be ensured, or the user may have to choose between using our driver or your programs (better, our driver might be unloaded). No case for throwing accusations of idiocy or incompetence at one another.

> E.g., Some of my "keyboard simulation" programs may call INT 15.4F in order
> to make sure they are simulating a valid scancode.
Without seeing the programs in question , I decline to comment.

> I think I've also seen
> references to programs that simulate a Ctrl-Alt-Del through INT 15.4F in
> order to flush the caches of a disk caching program like SMARTDRV
Methinks there are much better ways... SMARTDRV provides an API. Alternatively they could use DOS buffer flushing calls which smartdrv or similar caches intercept.

(...)
>> int 15/4F... should be called /only/ by a BIOS IRQ 1
>> handler (or replacement thereof).

> Not true, as stated above. INT 15.4F is allowed to be called by any
> program at any time.

Bis repetita non placent!


>That is why it is a separate interface and not
> actually required to be part of the INT 9 handler.
Grossly inexact : int15/4F has been part of the AT BIOS/ ISA de facto standard at least since the PC-AT, maybe PC-XT even.

I think we must agree to disagree re. the "philosphical" meaning of int 15/4F.
We could however learn how your program's calls conflict, or not, with our hook.

°°° °° °°° °° °°° °°

Bret's point # 2 :

> Regarding your specific implementation, it has problems. I haven't look at
> all of the details, but your INT 15 handler is incorrect. There are
> programs that "monitor" keystrokes by trapping INT 15.4F. E.g., SMARTDRV
> monitors INT 15.4F for Ctrl-Alt-Del, and flushes its write caches when this
> occurs.
I'm well aware of smartdrv and similar intercepting ctrl-alt-del, in fact I've mentioned it upthread.

I do not blame you for not reading everything ;=)

> Since your program does not chain to the old INT 15 handler, there
> is a potential for drive corruption during a reboot if the user installed a
> disk caching program (like SMARTDRV) before they installed your driver.

KBFR must be installed before Smartdrv for that reason precisely, which I'm doing. Remind me to add a note in the Manual.


> You must chain to the old handler even if you are the one processing the
> INT 15 Request. Because you must chain, there is also the possibility that
> the user has installed more than one INT 15.4F handler (either
> inadvertently or on purpose), which you must handle correctly.
Please note we are chaining (jmping, rather) to the old handler for all int 15, /except/ our 4Fh.

I shall leave it to Japheth to tell his rationale for not chaining.

I considered chaining, chose /not to/ for I couldn't trust other hookers not to modify the initial scan code. There's no problem with hooks which only /examine/ scan codes, our driver just can't tolerate another to /change/ a scan code, otherwise the keyboard behaviour could become erratic and user would put the blame on /us/.

I might reconsider. A compromise would be to call the old handler only on int 15/4F53 (the DEL sc iirc) and then only in ctrl+alt state.

The only case which need really concern me is, indeed smartdrv. Even so, there are situations already (older DOS versions for instance) when Smartdrv will not get ctrl-alt-del notification irrespective of a keyboard driver.


> Your INT 15h handler should look something like this. Note that this is in
> A86 syntax, and is untested, so there might be errors/problems with it, but
> you will hopefully get the idea:
>
> (code snipped for brevity)
 ]
Oh I get it. A detail, I would rather chain only the 4F case and JMP to the old driver for the general int 15, don't you think so ?


°°° °° °°° °° °°° °°

Phew, this has been long. Hope we can come to an understanding of sorts...

Regards,

---
Ninho

Post reply
 

Complete thread:

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