Newsgroups: comp.windows.ms
Path: utzoo!utgpu!watserv1!sunee!gpsteffl
From: gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler)
Subject: Re: timer interrupts
Message-ID: <1991Mar26.200102.3117@sunee.waterloo.edu>
Followup-To: comp.windows.ms.programmer
Keywords: interrupts tsr
Organization: Gold Disk Inc.
References: <1991Mar25.194839.19820@qualcomm.com>
Date: Tue, 26 Mar 1991 20:01:02 GMT
Lines: 59

In article <1991Mar25.194839.19820@qualcomm.com> antonio@qualcomm.com (Franklin Antonio) writes:
>I have a TSR that hooks itself into the timer interrupt.  It does this
>so that it can control some real-time hardware.  Works fine with DESQview,
>but not with Windows.  Windows is doing something funny with the timer
>interrupt.  Does anybody know how windows deals with the timer interrupt?

Windows virtual machine handler for the timer programms the timer for
a fixed rate callback.  When the callback happens, all of the active
high priority virtual machines will be given a simulated interrupt.
(hey I could be wrong, but then again this sounds right :-)

One of the high priority virtual machines contains Windows.  Thus,
Windows gets these simulated interrupts as well.  The system.drv
code handles the interrupt and provides the timer message and
callback functionality when Windows is out of an interrupt critical
section, and the active task yields if it is not the recipient of
the timer callback.  The recipient then recieves a callback which
is not during interrupt time, and merily proceeds to do it's duty.

Pretty standard stuff.  

However in DOS:

The TSR interrupt hook must receive the interrupt within some interval
so it may exactly control some hardware.  Unfortunately, unless the
virtual machine has set the minimum timer latency, the virtual machine
may receive the timer interrupts at non-precise timings.

We would hope the virtual timer device (vtd) will map all attempts at
programming the timer clock to its internal timing tables, and 
make the fixed rate timer interrupt happen at the slowest interval 
allowable by all of the virtual machines.  Thus, the virtual machine
that programms the timer for the fastest rate will indeed receive
interrupts close to it's time, whereas others will receive interrupts
at some time which is a close multiple of the currently programmed
timer rate such that they receive the appropriate number of 
interrupts per second. (puff puff wheeeze :-)

Assuming this to be the case, you may just have a machine which can't
process the interrupts fast enough.  I can't be sure what the cause of
the problem is without more info tho.

>A source of information describing how windows handles the timer interrupt
>is desired.  Or any related information that would make me understand
>how some of these interrupt-related system.ini parameters work.  I have
>already  read the sysini*.txt files.

Try the DDK, or the DPMI spec.  They may have more info than 
second rate hacks like me keep upstairs. :-)

As always, I can't be sure this information is accurate, or if
I am really alive, and this plastic monstrosity in front of
me actually listens to my keystrokes.  Hey, I don't have to know!

-- 
Co-Op Scum                            "Bo doesn't know software" - George Brett

"The galaxial hearth steams the sea as the sky blood red embrasses darkness"
-John Constantine (HellBlazer)                          Glenn Steffler