pas@lcs.mit.edu (Paul A. Selkirk) (03/02/90)
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? I have determined, through much pain and disassembly, that DOS uses service 0A (buffered string input) to get the next command, but other programs use that as well. I can get by on this knowledge, but I would prefer something a little more certain. For the record, I am writing a screen-saver TSR that will only trigger when DOS is idling. There are dozens of screen-savers, but I need one that won't kill 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. paul
CMH117@psuvm.psu.edu (Charles Hannum) (03/02/90)
I have a screen-blanker that will not destroy graphics screens, and can be
restored by simply pressing a Shift key, or Ctrl or Alt. If anyone would
like a copy, send me email, and I'll ship it out next week (when I can get
to it).
BTW: It also automatically parks hard disks.
Virtually,
- Charles Martin Hannum II "Klein bottle for sale ... inquire within."
(That's Charles to you!) "To life immortal!"
cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..."
c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."mac@harris.cis.ksu.edu (Myron A. Calhoun) (03/02/90)
In article <PAS.90Mar1120125@saffron.lcs.mit.edu> pas@lcs.mit.edu (Paul A. Selkirk) writes: >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? >I have determined, through much pain and disassembly, that DOS uses service >0A (buffered string input) to get the next command, but other programs use that >as well. I can get by on this knowledge, but I would prefer something a little >more certain. >For the record, I am writing a screen-saver TSR that will only trigger when DOS >is idling. There are dozens of screen-savers, but I need one that won't kill >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 MacMillan Publishing Company in October, 1990: (I reviewed it for MacMillan and am using it in a class! Any typo's are probably mine.) "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. Hope this helps. --Myron. -- #------------------------------------------------------------------------- # Myron A. Calhoun, Ph.D. E.E.; Associate Professor (913) 539-4448 home # INTERNET: mac@harris.cis.ksu.edu (129.130.10.2) 532-6350 work # UUCP: ...{rutgers, texbell}!ksuvax1!harry!mac 532-7004 fax
hinton@netcom.UUCP (Greg Hinton) (03/02/90)
In article <PAS.90Mar1120125@saffron.lcs.mit.edu> Paul A. Selkirk writes: > >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? > > .... rest omitted .... I think you can accomplish what you want by using three undocumented DOS functions: 1) int 21h function 34h -- Get DOS Busy Flag. on return, ES:BX will point to DOS Busy Flag; if this byte is nonzero, a DOS function is in progress. 2) int 28h -- DOS Safe Interrupt. this interrupt is called by DOS whenever it's sitting idle, waiting for keystrokes. 3) int 21h function 62h -- Get Current PSP. on return, BX will contain the current PSP segment. Prior to DOS 3.00, use function 51h. When your TSR first executes, get the address of the DOS Busy Flag & store it for future use (you don't want to have to call function 34h each time). Also latch onto interrupt 28h, so you'll be called when DOS is idle. Then, each time your TSR is activated later, check the DOS Busy Flag byte. If it's zero, call Get Current PSP and peek around in its address space to see if it's COMMAND.COM. I haven't tried any of this, but it seems to me that it should work. Let me know how it goes.
trier@solarium.scl.cwru.edu (Stephen Trier) (03/02/90)
There are two ways to find out, and you really need to do both. The first
way, which is the most reliable, is to hook into interrupt 28h, sometimes
known as the "DOS-Idle" interrupt. MS-DOS calls this whenever it is waiting
for some event, like a keystroke. *Almost* all the MS-DOS functions are
safe to use at this point. (I'm not sure which ones aren't.) This interrupt
is used by the print.com print spooler. I also used it for my Printscreen
TSR I'm working on; it buffers the screen in memory until DOS-Idle tells it
that it's safe to write to the disk. Be sure to pass on the interrupt by
calling whoever had to vector before you, or else a lot of other TSR's will
die when yours is installed.
The other flag to check is the "DOS-Busy" flag. You can find out its
location by calling int 21h, function 34h. The flag address will be returned
in the ES:BX pair. This flag is 1 if MS-DOS is active, and 0 if it isn't.
Watch out though, since according to the flag, MS-DOS is active when it's
at the command prompt! That's why you may need to use both techniques.
<=> Stephen Trier sct%seldon@skybridge.SCL.CWRU.Edu
{sun,att,decvax}!cwjcc!skybridge!seldon!sct
sct@po.CWRU.Edudixon@sagittarius.crd.ge.com (walt dixon) (03/02/90)
In the quoted article Myron A. Calhoun writes: >In article <PAS.90Mar1120125@saffron.lcs.mit.edu> 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: <PAS.90Mar1120125@saffron.lcs.mit.edu> <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
darcy@druid.uucp (D'Arcy J.M. Cain) (03/03/90)
In article <PAS.90Mar1120125@saffron.lcs.mit.edu> pas@lcs.mit.edu (Paul A. Selkirk) writes: > >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? > >I have determined, through much pain and disassembly, that DOS uses service >0A (buffered string input) to get the next command, but other programs use that >as well. I can get by on this knowledge, but I would prefer something a little >more certain. > >For the record, I am writing a screen-saver TSR that will only trigger when DOS >is idling. There are dozens of screen-savers, but I need one that won't kill >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. > > paul How about a way of turning screen saver on and off instead. You can have an interupt which turns screen saver on and off then write a utility which calls the interupt which you can run before your program. You can also have a keyboard hook to turn it on and off asynchronous to the system state. In cases where you have access to source code you can turn off the saver within a program just for the parts where this is important. I'd suggest something like the following AH = 0 Turns off screen saver AH = 1 Turns on screen saver AH = FF Returns 1234H or something unique to determine presence. I would have it also return the current active state so that programs could restore the system when necessary. -- D'Arcy J.M. Cain (darcy@druid) | Thank goodness we don't get all D'Arcy Cain Consulting | the government we pay for. West Hill, Ontario, Canada | (416) 281-6094 |
webb@uhccux.uhcc.hawaii.edu (Thomas Webb) (03/03/90)
In article <25EDB1B8.4B34@deimos.cis.ksu.edu> mac@harris.cis.ksu.edu (Myron A. Calhoun) writes: >In article <PAS.90Mar1120125@saffron.lcs.mit.edu> pas@lcs.mit.edu (Paul A. Selkirk) writes: >>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? > > "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." > [lots of interesting stuff deleted] The Waite Group's MS-DOS Developer's Guide, second edition, goes into the area of using the above function and int 28h. Neither of these functions is documented, so you pay your money and take your risks... Anyway, according to the Waite Group there are 'some peculiarities regarding the DOS busy flag in various versions of MS-DOS. Under MS-DOS 2.10, the byte immediately after the DOS busy flag must be set to 00 to permit the PRINT.COM interrupt to be called. For MS-DOS 3.0 and 3.1 (except COMPAQ DOS 3.0), the byte before the DOS busy flag must be zero; for COMPAQ DOS 3.0 the byte 01AAh before it must be zero.' (pp744-745). Any typos in the above are probably mine, also, I should note that I haven't actually tried to use the features described here, but I have found the MS-DOS Developer's guide to be quite reliable... Hope this isn't too misleading, -tom -- =============================================================================== webb@uhccux.uhcc.Hawaii.edu "The first duty in life is to assume a pose. What the second is, no one has yet discovered." -Oscar Wilde
bert@gufalet.UUCP (Bert Bos) (03/06/90)
In article <1990Mar2.022448.9490@usenet.ins.cwru.edu> trier@SCL.CWRU.Edu (Stephen Trier) writes: >The first >way, which is the most reliable, is to hook into interrupt 28h, sometimes >known as the "DOS-Idle" interrupt. MS-DOS calls this whenever it is waiting >for some event, like a keystroke. *Almost* all the MS-DOS functions are >safe to use at this point. (I'm not sure which ones aren't.) According to a book I have (Michael Hyman; Memory resident utilities, interrupts, and disk management with MS & PC DOS; MIS, 1987) it is save to use DOS function calls with numbers above 12 at this point.