🚀 go-pugleaf

In article <710@nih-csl.nih.gov> bert@helix.nih.gov (Bert Tyler) writes:
> somebody wrote...
>> >After some testing, apparently there is a bug with screenpeace.
>> >If you were to leave your computer on over the weekend without touching
>> >it until monday (i.e., leave it friday afternoon, and come in monday)
>> >, the date would be wrong. It would say Saturday. 
>>
>Actually, this "fix" could only make the problem worse.
> 
>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.  If you want to ensure that you never
cross two midnights without DOS doing a BIOS 1A call, and thereby eliminate
the date bug, you can do it easily by running a program that does just 
about any DOS call in a loop.  For example, you can do the DOS call that
returns time of day, or any function that causes same to be called.  You can 
throw away the result if you like.


>We traced our immediate problem down to the fact that we had our screen
>display package showing (and constantly updating) the time-of-day on
>the screen.  We already had a ten-second delay loop in the program
>(we didn't want to burden the server more than we had to), so I added

You didn't mention what this screen display package does in this ten
second loop, but my guess is that it doesn't do any DOS calls.  Any
program that sits in a loop without doing any DOS calls longer than
two midnights causes the problem.  Of course, if your program does BIOS 1A
calls to get time in this loop, then you've got TWO problems!

>some logic that checks the time at the start of each delay loop - and
>if it's after 11:59:30PM, calculates how many cycles through a nested
>"for{}" loop burns up one second and promptly invokes it sixty times,
>preventing the screen display package from getting control again until
>it is safe.

it just doesn't have to be this complicated.