[comp.windows.ms] Bug with Screenpeace

wluo@brahms.amd.com (Wilbur Luo) (12/04/90)

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. 

In other words, the date changes correctly Friday night, but it seems
that Screenpeace disconnects the 'hooks' that control the date until
you touch the computer again. Since you need that 36 hours of not
touching the computer, you can see this happen on weekends.
(Note, the time is correct). 

This has happened (consistently) to some 386 machines. We haven't
tried it on 286's. We ran 3 machines with Win and Screenpeace, 4 with
Windows only, and 3 with Dos only. All 3 running Screenpeace
came back messed up.

Are there any patches for this?

-W

spolsky-joel@cs.yale.edu (Joel Spolsky) (12/04/90)

In article <1990Dec3.162131.27441@amd.com> wluo@brahms.amd.com (Wilbur Luo) writes:
>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. 

This is not a bug with ScreenPeace. It is a bug with MS-DOS. It has
been a known bug with MS-DOS since about 1981...

The bug is that if you do not query the time for two date changes,
only one date change will occur. The problem results because when the
timer interrupt, keeping track of seconds passing, wraps around from
2359 to 0000, a flag is set to indicate that the date should be
incremented. The date is not actually incremented until you actually
check the time, presumably so that timer interrupts take a fixed
amount of time, even at midnight, to complete. I guess somebody
thought that this would be important for real-time systems. The
problem is that as there is only one bit reserved to indicate a date
change, _two_ date changes are not treated correctly unless there is
at least one clock read between them.

One fix would be to leave the windows Clock running which should query
the time occasionally and prevent this problem. 

Joel Spolsky
spolsky@cs.yale.edu

wluo@brahms.amd.com (Wilbur Luo) (12/05/90)

I've heard about this bug with the incorrect date in DOS, but I couldn't get 
it to repeat over the weekend, whereas machines that ran Screenpeace DID
show the incorrect date.

Are you sure it's not Screenpeace?

-W