VP/ix date is wrong under Xenix!

[Ken Weaverling]

In article <1990Nov22.052246.11841 at maverick.ksu.ksu.edu> wagner at matt.ksu.ksu.edu (Larry Wagner) writes:
>andrew at teslab.lab.OZ (Andrew Phillips) writes:
>
>>I noticed yesterday (Tuesday 20th) that the date under VP/ix was
>>wrong, but the date under Xenix was correct.  
>
>This is the same problem I have had with a Sun 386i I use at work (it uses
>VP/ix for DOS also).  I noticed that if there was no keyboard activity
>for more than 24 hours in a DOS window under Sunview (Sun's windowing system)
>that the date would not roll over to the next day.

The most likely reason for this lies with a *feature* of MS/DOS, not VP/ix
or Xenix. The fault lies with the logic behind the Interrupt 26 service #0

To quote some stuff my my Peter Norton's Programming Guide to the IBM PC...
 
"Service 0 (of Int 26) returns the current clock count in two registers:
the high order portion in CX and the low-order portion in DX. AL is 0
if midnight has not passed since the last clock value was read or set, and AL
is 1 if midnight has passed. The midnight signal is always reset when the
clock is read. It is the responsibility of any program using this service
to use the midnight signal to keep track of data changes. DOS programs 
normally should not use this service directly. If they do, they must
undertake the tedious chore of calculating and setting a new date."

>From my knowledge of Merge/386, he will put any DOS program to sleep that
does a keyboard read, so a stupid "Is kbd input available loop" doesn't
chew up CPU time from other UNIX process. 
 
If your DOS window is non-active for a weekend, then I theorize that VP/ix
puts it to sleep and therefore, no code can be executed after midnight by
DOS to manually update the clock. The next Monday, when you hit the
keyboard, DOS notices the midnight flag, dutifully updates the date by
ONE day, and your date is now screwed up.
-- 
>>>---> Ken Weaverling  >>>---->  weave at brahms.udel.edu