Path: utzoo!mnetor!uunet!pyrdc!grebyn!umd5!phil
From: phil@umd5.umd.edu (Philip Shafer)
Newsgroups: comp.sys.ibm.pc
Subject: Dos/TSR/Multitasking interaction
Message-ID: <2418@umd5.umd.edu>
Date: 4 Mar 88 15:51:29 GMT
Reply-To: phil@umd5.umd.edu (Philip Shafer)
Organization: University of Maryland, College Park
Lines: 57
Keywords: DOS TSR tasking background

DOS/TSR/Multitasking interaction

    I have a problem with DOS. Who doesn't?

    I have just written a background tasker for the IBM-PC.  It is part
of work done at the University of Maryland under contract to IBM.  I
have a few questions which I'm hoping that someone can help me with. 
Let me describe my program. 

    The tasker maintains tasks in a ring, scheduled round-robin.  Tasks
are forked and killed from this ring.  Tasks make explicit calls to the
tasker to yield the CPU to the next task, but the tasker realizes that
the foreground DOS application will not be kind enough to yield. 
Therefore it must preempt the foreground task and steal the CPU away
from it. 

    Initially the only task is the foreground DOS shell.  The tasker
grabs some interrupts, TSRs itself, and begins stealing cycles from the
foreground task.  Driven by the timer IRQ, the tasker jumps in and
checks to see if it is 'safe' to force a yield of the CPU.  'Safe' is
defined as follows: we are safe if we are not inside a dangerous
interrupt, or if we are inside an explicitly safe one.  My list of
dangerous interrupts are: Disk/diskette (13h), System services (15h),
Printer (17h), Critical error (24h), PCLan hook (2Ah), and PC
ASI/Netbios (5Ch).  My list of explicitly safe interrupts are: Keyboard
(16h) and Video (10h).  So, if a timer interrupt happens are the PC is
in INT 13h, the tasker will leave things alone.  If, however, the PC is
in INT 10h, even if it got there through INT 24h, the tasker will yield
the CPU to the next task.  Note that there is a user configurable
quantum which represents the minimum number of ticks which the
foreground task will get before background intervention. 

    My questions deal with the DOS interface.  I was listing Dos
services (21h) as one of my dangerous interrupts, but found a great deal
of trouble dealing with DOS as a simple interrupt.  A user program can
do a gets() (INT 21h func 0Ah), have the user type '^C', have DOS do a
CtrlBreak (INT 23h), and go on performing everyday life-type activities
(ie.  longjmp() to the top of a loop).  This example is annoying but
solvable.  The one the I'm having trouble with is user programs that
exec other programs, as I have no way (that I know of) to determine when
DOS stops being DOS and starts being the exec'ed program.  I sure there
are dozens of other twisted, tainted, horrid beyond belief cases that I
have not yet begun to think of (please let me know of any). 

    Which brings me (finally) to my real question: What kinds of
problems am I in for if I don't trap INT 21h?? Since my tasks are
TSR-based, and realize that they cannot use DOS, BIOS, or any common
other resource, the only type of problems that I really need to avoid
are timing-dependant ones.  Are there any others??

    I'd appreciate any help I can get. Thanks,
        phil

#   phil@umd5.umd.edu       # University of Maryland, College Park
#   shafer@umdd.bitnet      # IBM@UOM, Pc/Ip project
#   I tried to make a signature, but the disk was spinning
#   so fast I could hardly write (my pencil kept breaking)