Xref: utzoo alt.msdos.programmer:1324 comp.sys.ibm.pc.programmer:200 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!crdgw1!sagittarius!dixon From: dixon@sagittarius.crd.ge.com (walt dixon) Newsgroups: alt.msdos.programmer,comp.sys.ibm.pc.programmer Subject: Re: idling in the interpreter Message-ID: <5689@crdgw1.crd.ge.com> Date: 2 Mar 90 02:44:50 GMT References: <25EDB1B8.4B34@deimos.cis.ksu.edu> Sender: news@crdgw1.crd.ge.com Reply-To: dixon@sagittarius.crd.ge.com (walt dixon) Followup-To: alt.msdos.programmer Distribution: usa Organization: General Electric Corp. R&D, Schenectady, NY Lines: 100 In the quoted article Myron A. Calhoun writes: >In article pas@lcs.mit.edu \ >(Paul A. Selk: >>Does anyone know of a bulletproof way for a TSR to tell whether DOS (assume >>2.x or 3.x) is idling in the command interpreter, or executing a program? [text deleted] >>a lengthy graphics program. (Ever try generating the Mandelbrot set on a \ >>4.77 >>MHz XT with no FPU? I thought so.) >> >>Any leads will be duly appreciated. > >Quoting from chapter 16 of a preliminary version of "A Textbook on the >8086 Family" by William B. Giles, Copyright 1989, to be published by [text deleted] > > "DOS keeps a one-byte flag, which is usually called the InDOS flag > or the DOS Active byte. The value of this flag at any instant > equals the number of calls to INT 21h functions which are currently > in process of execution. In particular, if the value is zero no > DOS function is presently active and so DOS functions can be safely > called. Finding the value of the InDOS Flag is easy: a call to > function 34h of INT 21h returns the address of the flag in es:bx." > >Furthermore (a paragraph or two later): > > "... But even when DOS is busy, it may not be executing a non- > interruptible section of code; during such "safe" periods, DOS > makes regular calls to INT 28H." > > "The sole reason for the existence of INT 21h is to provide > programmers with another method of determining whether it is safe > to execute DOS functions. If INT 28h is active, DOS is in a safe > condition." > > "A number of the traditional DOS functions (01h through 0Ch) must > wait for user input and, during such waiting periods, they call > INT 28h repeatedly. In particular, while the DOS prompt is being > displayed and DOS is calling function 01h, the INT 28h method can > be used to determine when it is safe to execute DOS function calls." > >To actually use the above requires a "trick" almost like that of >writing device drivers. When your TSR determines it needs to do >something, usually it should just set an internal flag to remind >itself of that fact. Then it can make periodic tests (by taking >over the timer interrupt) and/or take-over INT 28h to determine >when it is safe to actually do the desired work. While the above information is essentially correct, it requires some elaboration. The int 21h dispatcher works with three different stacks. The way in which the dispatcher manipulates these stacks severely hampers re-entrency. (1) One must record the critical section flag address (int 21h ah=34h) when a tsr starts up. It is potentially disasterous to issue this request at random times because its processing can cause a stack switch. (2) The address of the critical error flag must also be recorded. In dos 3.x it is adjacent to the critical section flag. Before processing a critical error, dos decrements the critical section flag and increments the critical error flag. (3) When DOS issues an int 28h, it is safe to make int 21h requests with ah > 0ch. Requests in the ah=1h to 0ch are "character" i/o reqests and are serviced on one stack; those ah>0ch are "disk" i/o requests and are serviced on a different stack. Any attempt to issue int 21h ah=1 to 0ch could result in trashing a dos stack. (4) Some of the "character" i/o functions are output functions. Int 28h gets called periodically when dos is writing characters (every fourth character if memory serves me correctly). This may be an inopportune time for a screen saver to kick in. (5) Doing I/O behind DOS's back (in an isr) requires some careful preparation even if it is safe to carry out. One must establish critical error and break handlers and change the current PSP. Walt Dixon {arpa: dixon@crd.ge.com } {us mail: ge crd } { po box 8 } { schenectady, ny 12301 } {phone: 518-387-5798 } Newsgroups: alt.msdos.programmer,comp.sys.ibm.pc.programmer Subject: Re: idling in the interpreter Summary: Expires: References: <25EDB1B8.4B34@deimos.cis.ksu.edu> Sender: Reply-To: dixon@sagittarius.crd.ge.com (walt dixon) Followup-To: Distribution: usa Organization: General Electric Corp. R&D, Schenectady, NY Keywords: Walt Dixon dixon@crd.ge.com