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... (Developers)

posted by Ninho E-mail, 18.05.2011, 15:41
(edited by Ninho on 18.05.2011, 15:56)

> Again, that is the point. MS (via their code) says INT 15.4F can come from
> anywhere, not just from the INT 09 handler.
Their "knowledge base" article and piece of code are a "cooking recipe" aimed at your typical "systems administrator", not reference material. Not so bad however.

>> even if 'something' is simulating a keyboard by sending scancodes into
>> the system by callimg int15.4f, usually the intension is to enter
>> characters into the keyboard buffer.
>
> Perhaps usually, but not always. It is also true that the only programs I
> know of that use INT 15.4F are the SMARTDRV-compatible caches, and the only
> scancode that is used for this is Ctl-Alt-Del. But that doesn't mean there
> aren't other programs or other scancodes that do the same thing.
It is unclear from your writings whether you believe that the MS reboot program issues int 15/4F with the intent of flushing smartdrive's cache ? This is not the case. It is the int 21/0D function that causes Disk caching programs, including but not limited to "smartdrive compatible", you forgot Drivespace, network redirectors...to flush dirty buffers to disk.

But the purpose of issuing int 15/4F53 is to give notification of impending reboot to internal (and any add on) components which need a chance to clean-up before reboot. Smartdrv, DrvSpace and other standard systems components hook that, as do memory managers (not just EMM386! UMB managers like UmbDrvr or UMBPCI... must hook this too)

I belieeve one important aspect of int15/4F53 control-alt-del processing is DOS IO.SYS itself restores the original BIOS interrupts that it preserved very early in its sysinit module(including int 13h!).

Really, the control alt del case of int 15/4F is very specific and indeed, when you call it (as you may indeed, like the MS reboot mini utility does), it is not even likely to return from the call... did you understand this ? In the case it /does/ return to you, you had better initiate the soft reboot yourself immediately, as trying to continue processing would be hazardous.

Oh, and I hope you'll be pleased with it, following up to this discussion, I've updated KBFR to chain int 15/4F53 to previous handler (in control-alt state only) I have no intention ti chain arbitray scan code events however.
Is this enough to make you (rather, your programs) happy ?


>> if this something is sending CtrlAltDel scancodes, it's either an
>> annoyance or a remote control program - the system will boot anyway.

> Most likely, but not necessarily. It is at least theoretically possible to
> flush the SMARTDRV caches with INT 15.4F even if you don't intend to
> reboot.

No !!!! Don't do that !!!! Explained above.

> In reality, though, nobody would ever do this -- they would just
> use the SMARTDRV INT 2F interface instead. BTW, this is yet another
> justification to assume MS & IBM intended INT 15.4F to be called from
> anywhere -- the example reboot code from MS could have used INT 2F instead
> of INT 15, but it didn't.
You are confirming you don't understand the real purpose of int 15/4F in that smallish MS sample.


> Determining the keyboard layout, if it is other than the default, can only
> be done using INT 15.4F, and hoping it doesn't actually process the
> scancodes. Actually, for my purposes, merely supporting INT 2F.AD80 with a
> two-letter language ID is enough.
int 2F/AD is not part of a standard at all, it's an /internal/, private interface. It is not used by many non MS keyboard drivers, and it was not used by older MS Keyb.com either !

Anyways, there is no way to "determine the keyboard layout". It could have been part of the IBM AT keyboard ID interface, unfortunately it isn't.

> If you add support for INT 2F.AD80 to your program, which I would STRONGLY
> encourage everyone to do
There is IMHO no reason to support that private MS keyboard interface in a non MS driver.

, you really should change it to a "proper" INT 09
> interface instead of an INT 15.4F interface at the same time. The only
> difference between an INT 15.4F interface and an INT 09 interface is the
> entry/exit "wrapper", which is pretty insignificant.
False ! There's all the communication with the hardware, not only the interrupt and keyboard controllers, hardware initialisation, protocol management (error/resend), keyboard LEDs, just to scratch the surface. All this is done, and welldone, by the BIOS IRQ1 handler, it does not have its place in a driver which seeks to minimise overhead.


Tom said :
>> I doubt that. int16.5 was exactly created to enter keys into the
> keyboard
 >> buffer; no reason not to use it.

In reply to Tom : using it will save a few bytes, sure. The price maybe some lag, more seriously : we have no way to know what f^cker hooked int 16. A securer possibility is to call the /original/ int 16 at F000:E82E .
End of reply to Tom.


> Different concepts. INT 09 (IRQ / scancodes / keyboard language), INT
> 15.4F (keyboard layout), INT 16.5 (ASCII codes). You can call INT 16.5
> just as easily from INT 09 as you can from INT 15.4F.

---
Ninho

Post reply
 

Complete thread:

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