frank@grebyn.com (Frank 'Scruff' Miller) (01/17/91)
Does anyone know of a way to disable (trap) cntl-alt-del within a C application. Frank
ralf+@cs.cmu.edu (Ralf Brown) (01/19/91)
In article <LEVERICW.91Jan17230451@cheetah.ece.clarkson.edu> levericw@cheetah.ece.clarkson.edu (Walden Leverich) writes: }frank> Does anyone know of a way to disable (trap) cntl-alt-del within }frank> a C application. } }Try trapping the keyboard interrupt (INT09) and watching for the }ctrl-alt-del combination. I believe ctrl-alt-del has an interrupt of }its own you could wath for Unfortunately, it doesn't. They keyboard BIOS does a jump directly to the BIOS entry point when you press Ctrl-Alt-Del. The only way to disable it is (as you said) to hook INT 09 and filter out the Del scancode if Ctrl and Alt are already pressed. -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/3.1 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? Did | It isn't what we don't know that gives us trouble, it's I claim something?| what we know that ain't so. --Will Rogers
valley@uchicago (Doug Dougherty) (01/26/91)
levericw@cheetah.ece.clarkson.edu (Walden Leverich) writes: >frank> Does anyone know of a way to disable (trap) cntl-alt-del within >frank> a C application. >frank> Frank >Try trapping the keyboard interrupt (INT09) and watching for the >ctrl-alt-del combination. I believe ctrl-alt-del has an interrupt of >its own you could wath for, but I am not sure about that, check ralf's >interrupt listing. My $.02 worth. I always thought this was a dumb idea. I mean all you do is force the pern to find the reset switch when (N.B., not "if"!) the machine locks up. Worse, if they don't have a reset switch, they gotta turn the damn thing off wait 15 seconds then power back up. I always thought this idea of trapping it was just programmer ego gone haywire (Frankenstein mentality: If it can be done, it should be done...)
levericw@cheetah.ece.clarkson.edu (Walden Leverich) (01/26/91)
> My $.02 worth. I always thought this was a dumb idea. I mean all you > do is force the pern to find the reset switch when (N.B., not "if"!) the > machine locks up. Worse, if they don't have a reset switch, they gotta > turn the damn thing off wait 15 seconds then power back up. I always > thought this idea of trapping it was just programmer ego gone haywire > (Frankenstein mentality: If it can be done, it should be done...) Think about the user who is waiting for a database action. A long one to be specific. If ctl-alt-del is trapped and he/she hits the buttons, a message can be sent telling that the operation is still running, or the operation can be closed down in an orderly maner. If the buttons are not trapped you can have a serious mess. The same argument applies to some network functions, not to mention disk cache programs. It may not be needed at all times, but trapping ctl-alt-del does have its uses. -Walden -- --------------------------------------------------------------------------- Walden H. Leverich III | Inet: levericw@clutx.clarkson.edu ECE Dept. | CServ: 73237,2212 <- checked weekly Clarkson University | SnailMail: Software Solutions | PO Box 763 | Potsdam, NY 13676-0763 #include <std_disclamer_concerning_what_I_say> --------------------------------------------------------------------------
nather@ut-emx.uucp (Ed Nather) (01/28/91)
In article <valley.664826121@gsbsun>, valley@uchicago (Doug Dougherty) writes: > levericw@cheetah.ece.clarkson.edu (Walden Leverich) writes: > >frank> Does anyone know of a way to disable (trap) cntl-alt-del within > >frank> a C application. > >Try trapping the keyboard interrupt (INT09) and watching for the > >ctrl-alt-del combination. > > My $.02 worth. I always thought this was a dumb idea. I mean all you > do is force the pern to find the reset switch when (N.B., not "if"!) the > machine locks up. [...] You are making an incorrect assumption, that the only time you want to trap this combination is when the machine "locks up." Be aware that people use computers for many differt things. For example, I use a PC to gather data at a telescope, in real time, and I don't want ctrl-alt-del or ^C or ctrl-PrtSc to bomb the real-time program. There is only one keystroke combination that will halt the program; all the others are trapped. This decision is a result of sad experience in the past. -- Ed Nather Astronomy Dept, U of Texas @ Austin
valley@uchicago (Doug Dougherty) (01/29/91)
nather@ut-emx.uucp (Ed Nather) writes: (DD) >> (DD) >> My $.02 worth. I always thought this was a dumb idea. I mean all you (DD) >> do is force the pern to find the reset switch when (N.B., not "if"!) the (DD) >> machine locks up. [...] >You are making an incorrect assumption, that the only time you want to trap >this combination is when the machine "locks up." Be aware that people use I should have been more verbose. I was hoping people would be able to read between the lines. My overall point is that trapping c/a/b is not a technical issue at all; it is a training issue. You need to train your users that there are a few things they shouldn't do when using your software; the following lists some, but by no means all, of these things: 1) c/a/b 2) reset 3) turning the machine off 4) unplugging the machine 5) pouring Coke on the keyboard 6) dropping the machine 7) etc... What trapping c/a/b really does is make it harder for the support programmer to deal with the machine, while not making it any harder for the user (intentionally or not) to do something "bad". (This probably doesn't belong in this [technical] conference at all, but that is my $0.86 worth)
hagins@gamecock.rtp.dg.com (Jody Hagins) (01/30/91)
In article <valley.665079050@gsbsun>, valley@uchicago (Doug Dougherty) writes: |> nather@ut-emx.uucp (Ed Nather) writes: |> |> (DD) >> |> (DD) >> My $.02 worth. I always thought this was a dumb idea. I mean all you |> (DD) >> do is force the pern to find the reset switch when (N.B., not "if"!) the |> (DD) >> machine locks up. [...] |> |> >You are making an incorrect assumption, that the only time you want to trap |> >this combination is when the machine "locks up." Be aware that people use |> |> I should have been more verbose. I was hoping people would be able to |> read between the lines. My overall point is that trapping c/a/b is not |> a technical issue at all; it is a training issue. You need to train |> your users that there are a few things they shouldn't do when using your |> software; the following lists some, but by no means all, of these things: |> |> 1) c/a/b |> 2) reset |> 3) turning the machine off |> 4) unplugging the machine |> 5) pouring Coke on the keyboard |> 6) dropping the machine |> 7) etc... |> |> What trapping c/a/b really does is make it harder for the support |> programmer to deal with the machine, while not making it any harder for |> the user (intentionally or not) to do something "bad". |> |> (This probably doesn't belong in this [technical] conference at all, but that |> is my $0.86 worth) |> This brings up the debate of what is expected of the user. In general, I have come to assume that all users are brain dead, and completely incompenent. This assumption (the only safe assumption to ever make when writing software) keeps me at the keyboard an extra 10-20 percent doing extra testing, and error trapping. However, it does keep the users happy, which, in turn keeps them coming back for more. By the way, I do NOT trap c/a/d (or cntrl-alt-panic as i have come to know it). The way I figure it, I cant trap the power switch, which could do the same, if not worse, damage, so I don't trap the sequence either. The only thing it protects you from is a malicious user, which in that case, you pay to have your system secured, which would include keyboard locking, etc. -- Jody Hagins hagins@gamecock.rtp.dg.com Data General Corp. 62 Alexander Dr. RTP, N.C. 27709 (919) 248-6035 Nothing I ever say reflects the opinions of DGC.
nather@ut-emx.uucp (Ed Nather) (01/31/91)
In article <1991Jan29.164715.20309@dg-rtp.dg.com>, hagins@gamecock.rtp.dg.com (Jody Hagins) writes: > > This brings up the debate of what is expected of the user. [...] > >By the way, I do NOT trap c/a/d (or cntrl-alt-panic as i have come to know it). > The way I figure it, I cant trap the power switch, which could do the same, > if not worse, damage, so I don't trap the sequence either. You're thinking like a programmer, not like a user. To a user, there's a world of difference between the keyboard and the on/off switch, even though they may have the same net effect on your program. One criterion I apply to real-time data acquisition programs I write is simple: there should be nothing the user can do at the keyboard to stop or bomb the program. It isn't easy to do, but it allows you to tell that to the user. They are often afraid that an unintended keystroke can lose a lot of their work. In my racket (observational astronomy) the loss could be severe --- maybe a whole night's data on a hard-to-get-at major telescope. We often use the computer in very dim light, at 3 in the morning, and accidental keystrokes are commonplace. I consider *every* user brain-dead under those conditions, including myself. -- Ed Nather Astronomy Dept, U of Texas @ Austin
valley@uchicago (Doug Dougherty) (01/31/91)
hagins@gamecock.rtp.dg.com (Jody Hagins) writes: >|> >|> I should have been more verbose. I was hoping people would be able to >|> read between the lines. My overall point is that trapping c/a/b is not >|> a technical issue at all; it is a training issue. You need to train >|> your users that there are a few things they shouldn't do when using your >|> software; the following lists some, but by no means all, of these things: >|> >|> 1) c/a/b >|> 2) reset >|> 3) turning the machine off >|> 4) unplugging the machine >|> 5) pouring Coke on the keyboard >|> 6) dropping the machine >|> 7) etc... >|> >|> What trapping c/a/b really does is make it harder for the support >|> programmer to deal with the machine, while not making it any harder for >|> the user (intentionally or not) to do something "bad". >|> >|> (This probably doesn't belong in this [technical] conference at all, but that >|> is my $0.86 worth) >|> >This brings up the debate of what is expected of the user. In general, >I have come to assume that all users are brain dead, and completely >incompenent. This assumption (the only safe assumption to ever make when >writing software) keeps me at the keyboard an extra 10-20 percent doing >extra testing, and error trapping. However, it does keep the users happy, >which, in turn keeps them coming back for more. >By the way, I do NOT trap c/a/d (or cntrl-alt-panic as i have come to know it). >The way I figure it, I cant trap the power switch, which could do the same, >if not worse, damage, so I don't trap the sequence either. The only thing it >protects you from is a malicious user, which in that case, you pay to have >your system secured, which would include keyboard locking, etc. I agree completely with your last paragraph. Exactly the point. (BTW, it is c/a/d, not c/a/b. For some reason, I was thinking control/alt/break...)
mlord@bwdls58.bnr.ca (Mark Lord) (01/31/91)
<> This brings up the debate of what is expected of the user. [...] <> <>By the way, I do NOT trap c/a/d (or cntrl-alt-panic as i have come to know it). <> The way I figure it, I cant trap the power switch, which could do the same, <> if not worse, damage, so I don't trap the sequence either. < <You're thinking like a programmer, not like a user. To a user, there's a world <of difference between the keyboard and the on/off switch, even though they may <have the same net effect on your program. Hmm.. perhaps there is merit in both views. So why not do both? HYPERDSK does this sort of thing: It traps c/a/d and beeps the first time you press it, while it hastily attempts to flush the cache. When pressed a second time, after the beep warning, c/a/d does what we (users) expect it to do: it reboots MSDOS from scratch. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
leonard@qiclab.scn.rain.com (Leonard Erickson) (02/16/91)
valley@uchicago (Doug Dougherty) writes: >I should have been more verbose. I was hoping people would be able to >read between the lines. My overall point is that trapping c/a/b is not >a technical issue at all; it is a training issue. You need to train >your users that there are a few things they shouldn't do when using your >software; the following lists some, but by no means all, of these things: Sorry, but you are assuming that the programmer has any say about the training of the users! Part of my job is user support, and most of the problems can be traced to the fact the users *don't* get adequate training. And management won't listen. Also, *we* are the support programmers. I can't think of a situation where trapping ctrl-alt-del during critical portions of a program would be a support problem to us. On the other hand, if a user reboots in the middle of a fileupdate, guess who gets to clean up the mess? And if we complain that they shouldn't have let someone ignorant enough to do that near the machine, *we* get in trouble. We are supposed to make the program idiot proof. They won't bother trying to keep idiots away from it. <sigh> -- Leonard Erickson leonard@qiclab.uucp personal: CIS: [70465,203] 70465.203@compuserve.com business: CIS: [76376,1107] 76376.1107@compuserve.com