Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!tektronix!gvgpsa!gvgspd!mrk From: mrk@gvgspd.UUCP (Michael R. Kesti) Newsgroups: comp.sys.ibm.pc Subject: Re: unexpected "TSR's" Message-ID: <311@gvgspd.UUCP> Date: Sun, 11-Oct-87 14:26:42 EDT Article-I.D.: gvgspd.311 Posted: Sun Oct 11 14:26:42 1987 Date-Received: Tue, 13-Oct-87 00:55:45 EDT References: <307@gvgspd.UUCP> <1254@bsu-cs.UUCP> Reply-To: mrk@gvgspd.UUCP (Michael R. Kesti) Organization: Grass Valley Group, Grass Valley, CA Lines: 55 Summary: I WAS WRONG! 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: >> >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