andrew@teslab.lab.OZ (Andrew Phillips) (11/21/90)
I noticed yesterday (Tuesday 20th) that the date under VP/ix was wrong, but the date under Xenix was correct. The MSDOS date command said it was Monday (19/11/90). The time command reported the correct time. When I booted up under native MSDOS (without Xenix) the date was correct. The same thing happened today - i.e. the date is still Monday under VP/ix. What is happening? This could play havoc with my make files!! We're using Xenix 2.3.3 and VP/ix 1.1.1. Thanks in advance for any help. Andrew. -- Andrew Phillips (andrew@teslab.lab.oz.au) Phone +61 (Aust) 2 (Sydney) 289 8712
wagner@matt.ksu.ksu.edu (Larry Wagner) (11/22/90)
andrew@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. The MSDOS date command >said it was Monday (19/11/90). The time command reported the correct >time. When I booted up under native MSDOS (without Xenix) the date >was correct. >The same thing happened today - i.e. the date is still Monday under >VP/ix. What is happening? This could play havoc with my make files!! >We're using Xenix 2.3.3 and VP/ix 1.1.1. >Thanks in advance for any help. 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. Thus, every Monday my machine would be two days behind after the weekend. I reported the problem to Sun but have gotten no bug fix from them yet. I did get a DOS program from someone off the net got the UNIX date and time and updated the DOS date and time. I usually use it rather than manually typing in the new date and time. Basically what it did was make a system call to the UNIX date command, parsed it, and then updated the DOS date and time with that info. I assume Xenix with VP/ix allows UNIX commands to be run from DOS like the 386i can. If you are interested I can send you the Microsoft C source code. Larry E. Wagner USDA-ARS Wind Erosion Research Unit wagner@matt.ksu.ksu.edu
weave@brahms.udel.edu (Ken Weaverling) (11/26/90)
In article <1990Nov22.052246.11841@maverick.ksu.ksu.edu> wagner@matt.ksu.ksu.edu (Larry Wagner) writes: >andrew@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@brahms.udel.edu
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (11/26/90)
In article <16130@brahms.udel.edu> weave@brahms.udel.edu (Ken Weaverling) writes: | 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 has described this exactly correctly. And it's not a bug, in that real MS-DOS works just this way, loses two days every weekend, and if VP/ix didn't work that way some twit would say the emulation was bad. If you have some TSR hanging on the clock tick this doesn't happen, but that probably will drive the CPU offscale. I haven't tried it, nor do I feel the need to, but I have such a TSR around somewhere from DOS days at work, when we chased just this problem and found it easier to give the user a TSR to run than explain that our applications weren't causing it. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me