dmb@wam.umd.edu (David M. Baggett) (03/02/90)
In article <178@raider.MFEE.TN.US> dlh@raider.MFEE.TN.US (Dana L. Holt) writes: > > I have a program that hooks into the print screen vector and works >fine unless I try to format a disk etc.. I can select menu items ok but when >I try to copy a file etc it locks up. Do I need to disable an interrupt or >something? Do you think a program like this would be useful? It can copy, >delete files folders, toggle system config (ex. Write verify, etc..),do >disk functions! And much more.. Would you find it useful? > dlh@raider.MFEE.TN.US How exactly are you stealing the "print screen vector"? One possible way to do this is to install a VBI that runs before the OS VBI and watches for the print screen flag at $4EE (int). (When the flag is zero, you do your stuff, then set the flag back to -1 and jump through the old VBI vector.) If this is what you're doing, your problems may be caused by the fact that the Bios, Xbios, and GEMDOS are not reentrant. If the user presses ALT-Help and your VBI routine interrupts the "foreground" process (i.e., the program currently running) while a Bios, Xbios, or GEMDOS call is in progress, things will be royally screwed up when you do any OS traps in your code. One way to prevent this is to look at the information placed on the stack when the VBI interrupt occurred. Check the PC on the stack against the global system variables membot and memtop ($432 and $436 resp.) to be sure that you're only interrupting non-OS code. My experiments with this sort of thing have led me to believe that this is NOT very reliable. In particular, with TOS 1.2 I occasionally got strange behavior from the GEMDOS where I would get "Sorry your disk is write protected" alert boxes until I rebooted. With rainbow TOS this doesn't happen. Hmmm... Dave Baggett dmb@cscwam.umd.edu | dmb@TIS.COM