Announcement

**Michael Mattias** · 22 Dec 2005, 02:11 PM

Performing a flush command after every log is not an option, that would make the app too slow.

So make logging an option. If progam hangs, reboot. Then start program again, this time with logging enabled. When it hangs this time, you have your log files.

Fringe benefit: "normal mode" operation will speed up, since you will no longer be logging.

**Roger Garstang** · 22 Dec 2005, 05:16 PM

KEY 15, Chr$(&H0C,&H53,&H73)
ON KEY(15) GoSub YourFileSub
KEY(15) On

Keep in mind though any ON KEY / ON ERROR code you add adds to the
file size since it checks after pretty much every command.

And of course if the app is ran in Windoze this does nothing since
it has the keys trapped above your app/dos window.

------------------
If you aim at nothing...you will hit it.

[This message has been edited by Roger Garstang (edited December 22, 2005).]

**Michael Mattias** · 24 Dec 2005, 09:50 AM

My idea is this: when users press these keys because an app hangs, i want to flush the filebuffers first so that my files are ok/close

Wait a minute.

What makes you think that if your program is hung you'd be able to 'flush the filebuffers' anyway?

After all, your program is not responding!

**Roger Garstang** · 24 Dec 2005, 06:07 PM

If hung, one of two things would happen:

1. Key capture wouldn't occur and sys would just reboot.
2. If loop or whatever it is hung up on contains the inserted
check for the keys the keypress would GOSUB out and execute the
other code. I used the above code in an old DOS menu system I used
in school and it seemed to capture the keys no matter what I was doing.

I ended up taking out the capture since kids would just do it in the
middle of class to annoy me since it did a GOSUB to a function that
made an annoying alarm sound with a tone going up and a tone going
down at the same time. Made my app a lot smaller doing away with it.

------------------
If you aim at nothing...you will hit it.

**Tom Kuurstra** · 28 Dec 2005, 07:44 AM

Ok, bit more 'splaining seems to be in order.
First, disabling logging is not an option, one of the reasons the app runs is
to produce a log. Second, when the app hangs it doesn't really hang. As i said
earlier, this app communicates with hardware on a low level, so when the app hangs
it's not 'hanging' perse, the app waits for a return status from the (failing)
hardware. At this point the user (after having waited for some time) tends to press
the wretched ctrl-alt-del combo. Anyways, by now i'm led to believe that this is not
achievable, the on key trick would slow down the app way too much. Besides, it's checked
after every statement so if a statement is waiting for a result the on key thingy
wouldn't trigger anyway. So i'm going to try something else. Thanks for the input
anyways.

Kind regards,

Tom

------------------
[URL=http://www.DiyDataRecovery.nl]

**Tom Kuurstra** · 28 Dec 2005, 07:56 AM

Something else just sprang to mind: since PB buffers file data, wouldn't
it be possible to let PB flush those buffers just a bit more often? Is it
possible to set the buffersize for the PB file buffer? Using a flush command
after every log command is a bit much, there has to be a way that i can get PB
to log a bit more often without slowing the app too much. Thanks!

------------------
[URL=http://www.DiyDataRecovery.nl]

**Michael Mattias** · 28 Dec 2005, 08:24 AM

>.. when the app hangs it doesn't really hang...

Well, I'm glad that's been clarified. I guess that means all the suggestions you've received about handling a 'hanging' program can be deposited directly into the dumpster now.

But I digress....

the app waits FOR a RETURN STATUS FROM the (failing) hardware. At this point the user (after having waited for some time) tends to press the wretched ctrl-alt-del combo...

It sounds like your application design was blindsided by the (then-unknown) user reaction to certain application conditions and you need to deal with that (now-known) reaction in your program.

Maybe you can do so fairly quickly and inexpensively by adding an explicit 'give up/stop waiting' user action to that particular procedure.

Or even more simply, maybe you could handle 'user control' by displaying a "this may take a moment" warning to the user? Or simpler still, provide better user training and/or documentation.

Do you still risk the user pressing the (Big Red) Button? Sure. But you can't handle every possible contingency. Best you can do is minimize the probabilty the user will do The Wrong Thing.

(FWIW, this is another example of asking for help with HOW before asking for help with WHAT).

**Tom Kuurstra** · 3 Jan 2006, 05:03 AM

I guess that means all the suggestions you've received about handling a 'hanging'
program can be deposited directly into the dumpster now

If i would have received any advice on how handle a -hanging- app, then yes. But since
i didn't i think the damage is relatively minor.

I'm sorry my linguistic skills are not adequate. I realise that asking for a specific
solution to a specific problem/scenario is tricky without offering all the background
info, but i didn't find it necessary to explain the entire context. Apparently i was
wrong there.

About all the other advice given in that last posting; i've been doing this
for some time now and obviously all those suggestions have either been incoorporated
or ruled out as unusable. Again, i don't wish to explain the whole project so just take
my word for it.

(FWIW, this is another example of asking for help with HOW before asking for help with WHAT)

I agree, but i don't see the harm in that. Maybe my particular question wasn't tailor-made
for a person that has read the book on 'how to post a question in a forum that is populated
by knowledgeable people' but that was never the aim of this exercise.

Thanks to everyone for helping me with this.

**Hubert Brandel** · 17 Jan 2006, 04:29 AM

Hi,

CTRL+ALT+DEL was in DOS Times a reboot command.

I was very angry that NT uses this to login,
because after that many working PCs were rebooted
by error with other OS.

The reason why MS unsed this cobination is, that
NOT the software is interupted, it is a CPU interupt.
So no virus or hook can change the logon prozess.

I do not think there is any possible way to
get into this prozess.

Bye
Hubert

------------------

**Paul Dixon** · 17 Jan 2006, 04:27 PM

The keyboard only has 1 hardware interrupt for all keypresses. Ctl-Alt-Del is handled no differently to any other key sequence as far as priority of hardware interrupts is concerned.
When the keyboard hardware interrupt routine (INT9) sees the Ctl-Alt-Del combination, it calls the software interrupt INT19h.
Both Int9 and Int19h are potentially interceptable by changing the interrupt vectors.

This is the DOS forum so I assume the code is running in DOS and has full access to these vectors without the usual hiderance imposed by Windows.
INT19h would be the easiest to intercept as the determining of when Ctl-Alt-Del has been pressed is done for you but would risk getting called at the wrong time if any application attempts a warm-boot using Int19h.

However, having quickly read through this thead, I'd have thought a better thing to do was to reprogram the interface with the hardware so it times out and reports aproblem long before the user gets fed up waiting OR to give an onscreen indication of progress so the user sees that the machine hasn't crashed.

Paul

PS It's also possible to disable the keyboard. If that's done then Ctl-Alt-Del is also disabled.. but the user is then likely to hit the reset button next.
You can disable the keyboard by writing &had to i/o port 64h and re-enable it by writing &hae to that same port.

[This message has been edited by Paul Dixon (edited January 17, 2006).]

Announcement

intercept ctrl-alt-del

intercept ctrl-alt-del

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment