Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!osu-cis!sppy00!jmv
From: jmv@sppy00.UUCP (Jim Vickroy)
Newsgroups: comp.sys.ibm.pc
Subject: Re: CTRL-ALT-DEL key
Message-ID: <240@sppy00.UUCP>
Date: 31 Mar 89 17:51:24 GMT
References: <1623@arctic.nprdc.arpa> <3818@nicmad.UUCP> <234@sppy00.UUCP> <6414@bsu-cs.UUCP>
Reply-To: jmv@sppy00.UUCP (Jim Vickroy)
Distribution: na
Organization: Online Computer Library Center, Dublin, Ohio.
Lines: 56

In article <6414@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
=>A philosophical point:  For an application to trap keystrokes so
=>they bypass the ROM is bad practice for several reasons.
=>
=>1.   This introduces incompatibility with many of the machines on the
=>     market.

I doesn't create incompatibility with those machines which boast IBM
compatibility. These "many machines" you speak of will have many other 
problems if they can't handle a keyboard interrupt handler. I have placed
interrupt handlers in IBM's and compatibles (some of the compatibles used
Phoenix BIOS) and had no problems. Of course, because the interrupt handler
is operating a such a low level, you do have special conciderations in terms
of incompatibility. In the end these have to be weighed against the benifits.

=>
=>2.   The user may already have deliberately installed special software
=>     to trap ctrl-alt-del, your application may cause chaos when it
=>     tries to trap the same key sequence.  Don't second-guess the
=>     user by adding your own keyboard driver.

If the interrupt was 'stolen' properly and the handler was written in such a
way as to maintain the overall design of the interrupt, you won't have 
problems stacking another handler on top. In fact if you steal an interrupt
and do the IRET yourself, the previous handler will not gain control. Also,
assuming that the PC is still a single-user workstation, you are the user. Any
second guessing that is going on will be aimed at yourself. You will be in 
control of what is being loaded.

=>
=>3.   If the database is so fragile that a power outage will cause
=>     unrecoverable damage, then it is badly designed, and trapping
=>     ctrl-alt-del is no solution.
=>
=>The right way to avoid corruption of a database is to make sure that
=>any partial update of the database is reversible even if a system crash
=>or a reboot occurs during the update.

Your point is well taken but you use what is available in the environment you
are working in. I tend to believe that a database of the sophistication you
imply would probably not be able to function under an application of any size.
To go further, some of this, in many mainframe sights, is handled by fault-
tolerent hardware. Indeed, many of the largest database systems still have 
problems that are compinsated for by fault-tolerent hardware.


jim
--

!==================================================================!=========!
! Jim Vickroy                          | cbosgd!osu-cis!sppy00!jmv !/././././!
! Online Computer Library Center, Inc. |---------------------------!././././.!
! Dublin, Ohio  43017                  | jmv@sppy00                !/././././!
!------------------------------------------------------------------!././././.!
! "That voodoo stuff don't do nothin' for me"                 -jrr !/././././!
!==================================================================!=========!