Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!bu-cs!bucsb.bu.edu!madd
From: madd@bucsb.bu.edu.UUCP (Jim Frost)
Newsgroups: net.micro.pc
Subject: Re:  why does program stop print spooler?
Message-ID: <482@bucsb.bu.edu.UUCP>
Date: Thu, 11-Sep-86 18:42:41 EDT
Article-I.D.: bucsb.482
Posted: Thu Sep 11 18:42:41 1986
Date-Received: Thu, 11-Sep-86 21:44:12 EDT
Organization: Boston Univ Comp. Sci.
Lines: 67

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             !                                 !
+--------------------------------------+---------------------------------+