Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!ucsd!qualcom.qualcomm.com!antonio
From: antonio@qualcomm.com (Franklin Antonio)
Newsgroups: comp.windows.ms
Subject: timer interrupts
Keywords: interrupts tsr
Message-ID: <1991Mar25.194839.19820@qualcomm.com>
Date: 25 Mar 91 19:48:39 GMT
Organization: Qualcomm Inc., San Diego, CA
Lines: 26

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?

There is a funny clue in the system.ini parameters.  There is one called
TimerCriticalSection.  Doc says it tells windows to go into a critical
section around timer interrupt code.  I'm not sure exactly what they
mean by that.  Which timer interrupt code?  In windows?  In virtual
'86 machines running DOS windows?  Interrupt code in a TSR loaded before
windows?

Article in March BYTE says to set this param nonzero to make some network
TSRs work.  They don't say why.  How did the author find this out?
I tried it.  What the heck... it looks possibly related, so i experiment.
Didn't help.

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.

I will note that interrupt handling is completely documented in DESQview,
and is straightforward and nonmysterious.  The TSR in question, for example,
works fine there, and even better, I know why.  How do i get to the same
place with windows?