joels@tekred.UUCP (Joel Swank) (09/09/86)
I have a C program that stops the print spooler ( the PRINT command). I cannot figure out what is causing this. The spooler stops printing whin this program is in control, and resumes normally when it exits. Any Ideas? Thanks, Joel Swank Tektronix, Redmond, Oregon
gt6294b@gitpyr.UUCP (SCHEUTZOW,MICHAEL J) (09/11/86)
> >I have a C program that stops the print spooler ( the PRINT command). >The spooler stops printing >whin this program is in control, and resumes normally when it exits. > Does the C-program grab interrupt 28h? I believe that PRINT uses this interrupt to achieve a pseudo-form of multitasking. When the machine is waiting around for you to type something, it ocassionally calls int int 28h when it is safe to do so. See Best of BIX in the Sept issue of BYTE. Mike Scheutzow Trek trivia: In what state was Kirk born? Georgia Tech gt6294b@gitpyr.uucp
madd@bucsb.bu.edu.UUCP (Jim Frost) (09/12/86)
In message <729@tekred.UUCP> joels@tekred.UUCP (Joel Swank) writes: >I have a C program that stops the print spooler ( the PRINT command). >I cannot figure out what is causing this. The spooler stops printing >whin this program is in control, and resumes normally when it exits. >Any Ideas? > >Joel Swank >Tektronix, Redmond, Oregon Yup. But before we get to that, you need some information. PRINT is a neat little toy. It seems that it leaves a little resident thingy that keeps track of what file it's printing, and where it is within that file. You can assume they use the normal DOS commands for pulling in the file, because they're there. In order to know when to print, PRINT locks onto INT 28H (one of the system interrupts). It seems this little interrupt is repeatedly called by DOS whenever it isn't doing anything. This, BTW, is where your problem probably lies. Since INT 28H is one of those undocumented things, you have no way of telling what DOS considers "not doing anything." Probably whatever C you are using is ALWAYS "doing something," either actually doing something, or constantly polling for I/O (eg serial ports, keyboard, joystick, etc). This would explain why it resumes afterward, too. There's a lot more information about INT 28H (mostly from REAL hacks who tore apart PRINT and traced through the DOS code). As for a solution, if you have the C source, you could try setting up a call to INT 28 at some points within the program. This is a bad solution for several reasons -- first, you probably have to be a hack to understand how to call the interrupt table, unless that version of C has a function in some library somewhere that does it. Secondly, it's not efficient at all. A better solution (again, if you have source) is to see if there is some flag you can set/unset to allow noncritical system interrupts (like INT 28) when compiling. Turbo Pascal, for instance, disallows system buffering of the keyboard unless you set a flag (u-, I think). There may be a comparable directive in the C compiler. If you don't have source or are not too interested in doing this, then all you can do is live with the problem. I don't know of ANYONE who can make INT 28 a more critical interrupt, even if it were desirable. If you really ARE interested in this and want to know about INT 28 (or interrupts in particular), try Byte's special IBM issue (1985 in the fall, I think), and either Byte Aug. 1986 or Sept. 1986 (whichever is on the 68000 machines). The special issue has several articles on interrupts (none, unfortunately, written for C), and the other has a listing of BIX discussions of INT 28 in the back ("Best of BIX") under IBM PC's. Hope all this helps. -- +--------------------------------------+---------------------------------+ ! Jim Frost ! "You just gotta smile through ! ! UUCP: ..!harvard!bu-cs!bucsb!madd ! it" -- John Reardon ! ! ARPANET: madd@bucsb.bu.edu ! ! ! CSNET: madd%bucsb@bu-cs ! mv flames /dev/null ! ! BITNET: cscc71c@bostonu ! ! +--------------------------------------+---------------------------------+
bobm@hp-pcd.UUCP (bobm) (09/12/86)
The PRINT command works by taking over an interrupt called the 'DOS IDLE' hook (Int 28H). This hook is called by DOS whenever it is in an idle state, such as waiting for keyboard input. Every time int 28 is called, PRINT dumps a burst of characters to the printer. If you have a program that doesn't do many DOS I/O calls, Int 28 will not be called, and the spooler won't have a chance to run until you exit to DOS. Bob May hplabs!hp-pcd!bobm
perkins@bnrmtv.UUCP (Henry Perkins) (09/15/86)
> >I have a C program that stops the print spooler ( the PRINT command). > >The spooler stops printing > >whin this program is in control, and resumes normally when it exits. > > > Does the C-program grab interrupt 28h? I believe that PRINT uses this > interrupt to achieve a pseudo-form of multitasking. When the machine > is waiting around for you to type something, it ocassionally calls int > int 28h when it is safe to do so. See Best of BIX in the Sept issue > of BYTE. > More accurately, MSDOS raises INT 28H when it's in a keyboard input wait. If the C program isn't doing keyboard input, or if the C doesn't use MSDOS calls to read from the keyboard, you'd expect printing to stop. This is why I have a HARDWARE print buffer. -- {hplabs,amdahl,3comvax,okstate}!bnrmtv!perkins --Henry Perkins It is better never to have been born. But who among us has such luck? One in a million, perhaps.