mrk@gvgspd.UUCP (Michael R. Kesti) (10/10/87)
Since I have begun to use Bob Frolick's AT program, I have discovered that
some programs (notably Procomm and TurboC) appear to attach themselves to
DOS in TSR fashion. Especially, they reassign the vector for interrupt 16
(keyboard services) in the course of their execution, and do *NOT* restore
this vector upon termination. This causes failure of AT, as it compares the
code pointed to by this vector to determine whether it is already installed.
When this vector is changed, it fails to recognize itself, and re-installs
itself, losing any previously scheduled events!
I am happy to report, however, that I have found a work around for this
problem. In both cases (Procomm and TurboC, that is), I was already using
batch files to invoke these programs, and have found that the TSR management
utilities INSTALL and REMOVE, recently published in PC Magazine; along with
FAKEY, recently posted here, could be used to advantage in them. INSTALL
saves the current state of the interrupt vectors and free memory prior to
TSR installation , so that REMOVE may later be used to restore the system to
the state it was in prior to the installation, effectively removing the TSR
in question. FAKEY provides a means to supply keystrokes to susequently
invoked programs when run from batch files. The fundamental scheme goes
something like this: Suppose Procomm is invoked from CALL.BAT. CALL.BAT
would include:
echo off
install procomm
.
.
. other commands, as required
.
.
:end
fakey "\r"
remove
cls
The invocation of INSTALL need not include the program name parameter
("procomm" in this example), but is a convenience. INSTALL does its thing
with the vectors and free memory specs, then, upon execution of the commands
following the label "end", REMOVE is used to restore the system. The FAKEY
invocation is used to automagically supply the affirmative response to
REMOVE's prompt "Press ESC to abort or ENTER to remove procomm".
The only caveat to all this is that you must not invoke AT or REMOVE while
"shelled out" of Procomm, TurboC, or what-have-you; but this should be
fairly easy to live with (at least it is for me!).
I hope that this information saves at least one of you fine people some
grief! If need be, I would be happy to (re?)post INSTALL, REMOVE, and
FAKEY. Just let me know if this is justified.
--
===================================================================
Michael Kesti Grass Valley Group, Inc.
P.O. Box 1114 Grass Valley, CA 95945
UUCP: ...!tektronix!gvgpsa!gvgspd!mrkdhesi@bsu-cs.UUCP (Rahul Dhesi) (10/10/87)
In article <307@gvgspd.UUCP> mrk@gvgspd.UUCP (Michael R. Kesti) writes: >Since I have begun to use Bob Frolick's AT program, I have discovered that >some programs (notably Procomm and TurboC) appear to attach themselves to >DOS in TSR fashion. Especially, they reassign the vector for interrupt 16 >(keyboard services) in the course of their execution, and do *NOT* restore >this vector upon termination. I doubt very much that Turbo C traps INT 16h without restoring it. That would cause chaos, and Turco C hasn't caused chaos on my system so far. >This causes failure of AT, as it compares the >code pointed to by this vector to determine whether it is already installed. >When this vector is changed, it fails to recognize itself, and re-installs >itself, losing any previously scheduled events! This is purely AT's fault. A program that traps a keyboard interrupt must always be prepared to have other programs trap it too. Programs that claim exclusive use of vectors such as the keyboard software interrupt are using a bad programming technique. (Aside: Prokey used to use this bad programming technique and would therefore not work with SideKick. David Rose, the author, refused to fix it. One Sunday morning, in a fit of exasperation, Phillippe Kahn declared he would write his own keyboard enhancer. The rest is history.) The correct technique for a terminate-and-stay-resident program to avoid loading itself twice is to trap an unused interrupt vector (or MS-DOS function call), and install a service routine that returns a known value. Then, when it is loaded, the TSR program first calls this vector and examines the return value. Return values for unused interrupt vectors and MS-DOS calls are usually well-defined though not always well-documented. If the value returned is that expected to be returned by an already-installed TSR program, the newly-loaded program prints a message and gracefully exits. For safety's sake, allow the user to change the value of the unused vector used in case other software happens to use the value you choose. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
mrk@gvgspd.UUCP (Michael R. Kesti) (10/11/87)
In article <1254@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <307@gvgspd.UUCP> mrk@gvgspd.UUCP (Michael R. Kesti) writes: >> <My complaints concerning Procomm's and TurboC use of int 16> >I doubt very much that Turbo C traps INT 16h without restoring it. >That would cause chaos, and Turco C hasn't caused chaos on my system so >far. After reading Rahul's article, I set out to prove that I was really seeing the effect I claimed. I first used SYMDEB and PCMAP (another PC Magazine program that was part of the article that gave us INSTALL and REMOVE) to record the state of my machine after a normal reboot, that is, after the installation of the TSR's that I normally use, and INSTALL via my autoexec. I then ran PROCOMM and TurboC in turn, recording the state of the machine after their invocations in the same manner. In order to prevent the restoration that I had described in my original arcticle, I invoked these programs directly, rather than using the batch files with which I normally invoke them. And what did I find? NO DIFFERENCES!!! So, wiping the egg off my face, I set out to find the cause of my original problem, and discovered that both of my batch files use KEY-FAKE (Note that this is *NOT* FAKEY, the program that I had suggested using in my original article. They are similiar, but definitely not the same program). Now, I had not thought of KEY-FAKE as a TSR, but, of course it is. Because I had not INSTALLed KEY-FAKE in my autoexec, it changed the int 16 vector at the time the batch files ran, and *THIS* is what caused AT to fail. >This is purely AT's fault. > >A program that traps a keyboard interrupt must always be prepared to >have other programs trap it too. Programs that claim exclusive use of >vectors such as the keyboard software interrupt are using a bad >programming technique. Rahul, we are in complete agreement here, now that I have seen what happens when this technique is used. In my own defense, I didn't write AT. I do, however, through Mr. Frolick's kindness, have a listing of AT, and will probably attempt to fix this problem. (Bob - when (and if) I fix this, may I have your permission to post my version?) In conclusion, I *REALLY* thought that I had seen a genuine problem with PROCOMM and TurboC, and I was only trying to be helpful. I am normally very careful to not post misinformation, and honestly believed that I was not doing so in this case (I don't like to mislead people and I *HATE* having to use the line I have in the summary field of this posting 8-).) I apologize for any inconvenience this has caused anyone. Hey, if nothing else, though, I have learned one more way that this brain damaged operating system can burn the less than fully paranoid programmer and/or user :-) ! -- =================================================================== Michael Kesti Grass Valley Group, Inc. P.O. Box 1114 Grass Valley, CA 95945 UUCP: ...!tektronix!gvgpsa!gvgspd!mrk