🚀 go-pugleaf

I have some foolish questions about DOS, BIOS and keyboards. I
realise this may not be exactly the right group, but I think some folk
here know the answers. Skip now if you aren't such a person.

1) I am using the Microsoft C compiler, which doesn't (as far as I can
tell) allow for inline assembly code. (I'd only be dangerous if it
did allow it). This first question is for anyone who knows how Microsoft's
C runtime implements the "hooking" of interrupts, and also for folk who
know how the BIOS, and IRET, works.

I use a pntr = _dos_getvect(0x09); to get a pointer to the keyboard interrupt
handler, then do a _dos_setvect(0x09, myroutine) to hook in my own
handler. Having read port 0x60 while in myroutine() to see what is going on,
I want to transfer control back to the usual interrupt handler (otherwise, the
BIOS gets real confused). My *guess* is that what I really should do is
"JMP pntr" but I have no way to JMP. Instead, I cast pntr to a
pointer-to-function-of-type-void-taking-no-args, and call: (*pntr)();
as the last step of my interrupt routine.

It works. I think. I have this awful feeling that, by calling when I 
should probably be JMPing, I am slowly filling some stack somewhere,
and it isn't getting properly unfilled by a RET. Is this going to bite me?
Is a stack switch happening somewhere, which causes this to be a non-problem?

2) I want to disable cntrl-alt-del. One obvious way to do it is to
hook the keyboard interrupt, keep track of what keys are pressed, and
do something clever when those keys are all down. The "clever" thing I
tried was writing a 0 to port 0x60, then transferring to BIOS as usual,
in the hopes that writing to the port would clear the scan code stored
there. It seems to work; but I don't have any documentation that tells
me that it is a proper approach, and won't, for example, turn off all the
keyboard LEDs and cause smoke to pour out of the backspace key on a
different make of keyboard. Anyone here know how the ports respond to being
written?


3) I have a Wang keyboard. I get the impression that it is not 100%
IBM compatable. The DOS book I have talks briefly about how keyboard
handling works, and it claims that, for an extended keyboard, pressing
an extended key causes two scancodes to be transmitted: E0, and the
scancode for the extended key. My keyboard seems to transmit 36 scn or
38 scn, depending on the extended key I hit. Should it in fact be sending
E0 to be compatable, and is there any way to ask a keyboard if it is
IBm compatable? (I think I know the answer to that...). E0 seems like
an odd choice, since it should be interpreted as a key *release*, but
then IBM has never been sane.

I don't *really* need to hook the keyboard for my game. But it might be
nice to be able to disable the warm reboot request, and to be able to
tell when odd combinations are being done ("if you press 'a' and 'e' at
the same time, it means this...")

4) I get the impression that, when cntrl-alt-del is pressed, it does more
than just do whichever interrupt causes a warm boot (0x17?). That is
why I want to catch cntrl-alt-del before it goes into the BIOS. Is this
really needed? Or is it sufficient to just hook 0x17 (or whatever) with
a noop routine, to make cntrl-alt-del mostly harmless? There are a few
experiments I am afraid to try (especially on company hardware.)
--
"On guard, you musty sofa!"        James Thurber _The 13 Clocks_
smayo@wang.com