Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!bronze!yawei
From: yawei@bronze.ucs.indiana.edu (mr. yawei)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Backgroup processing (Was Re: DOS idle interrupt (INT28))
Message-ID: <1991Jan7.232348.9260@bronze.ucs.indiana.edu>
Date: 7 Jan 91 23:23:48 GMT
References: <773@csource.oz.au> <1991Jan6.005549.29246@bronze.ucs.indiana.edu> <20223@netcom.UUCP>
Distribution: comp
Organization: Indiana University, Bloomington
Lines: 28

In article <20223@netcom.UUCP> resnicks@netcom.UUCP (Steve Resnick) writes:
>[From Page 17-12 of the DESQview API Reference Manual, Version 1 (DESQview
> version 2.01)] :
>Hooking Interrupt 08H (the timer)
>The only hardware interrupt which generally has the enitre state of the task 
>set up, and therefore has no restrictions on what its interrupt handler can
>do, is the timer interrupt. This is because DESQview gives the timer interrupt
>to the currently running process. Thus, if the user has set the foreground/
>background slices to 9 and 3, then the foreground task will get nine 
>consecutive timer interrupts while it is running, and each background task 
>will get three consecutive timer ticks while it is running. This means that
>the entire task state is completely set up when it gets a timer interrupt.

Thanks for the info. I wonder why DV does not, like David Nugent pointed
out, filter the interrupt back to the correct rate? If you have an alarm
clock running in one of these partitions, it's going to be 25% slower
than normal. :-)

It can, for example, call the routine twice for one in 3 ticks to do the
compensation. The extra call needs to be caught at the bottom of the
partition (with an 'iret') so that those loaded before DV still gets 
the correct rate.

Btw, int 16h is the Bios keyboard, not video, interrupt. It seems some
earlier versions of DV may not have int 16h routed properly. -- Just my
guess, no slandering intended. :-)

yawei