Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!att!pacbell.com!ames!haven!adm!lhc!nih-csl!helix.nih.gov
From: bert@helix.nih.gov (Bert Tyler)
Newsgroups: comp.windows.ms
Subject: Re: Screenpeace and the system date
Message-ID: <717@nih-csl.nih.gov>
Date: 7 Dec 90 03:48:47 GMT
Sender: news@nih-csl.nih.gov
Organization: National Institutes of Health, Bethesda
Lines: 23

> >I wrote a small test program which simply ran a tight loop invoking
> >interrupt 1Ah (AX = 0) to read the time-of-day clock, and found that
> >this program reliably prevented the system date from incrementing.
> 
> Your tried to fix the problem at the wrong level.  The only way to make
> sure that DOS gets the correct info from BIOS 1A is to NEVER call this
> function yourself.  Let DOS do it.
>
> it just doesn't have to be this complicated.

I'm sorry, apparantly I didn't word my original message very clearly.  What I
was trying to accomplish was to point out what another canned program (in
this case, ScreenPeace) was probably doing, and using as an example
a case I had run into where a canned package I was using was doing the
same thing to my programs.  ScreenPeace has to be using *some* sort of
clock-watching logic to decide when to blank the screen, and is is apparantly
doing it in some fashion that stops the date-advance.  I was not by
any means attempting to recommend this particular "fix" for any problem.
 
(On the other hand, the fix I described made the problem go away with
a minimum of fuss and without resorting to a major rewrite of the
application, which is fixing the problem at the "right level" in my
book <grin>.)