antonio@qualcomm.com (Franklin Antonio) (03/26/91)
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?
gpsteffl@sunee.waterloo.edu (Glenn Patrick Steffler) (03/27/91)
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