wales@valeria.cs.ucla.edu (Rich Wales) (09/16/88)
In article <350@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) asks about the "date rollover" problem on a PC running DOS 3.3 (i.e., the date doesn't get advanced at midnight). I believe this problem is due to a combination of DOS and the system's ROM BIOS. My system, for instance -- an XT clone with the Award BIOS (Version "XT 2.03") -- exhibited this particular problem with MS-DOS 3.2 -- but *not* with MS-DOS 3.1 or 3.3. I'm enclosing below a few messages which were sent out a while back about this problem. Use this material at your own risk, of course. Actually, there are *TWO* related problems known with regard to the proper advancing of the date. One is the problem you mentioned (i.e., the date doesn't change at midnight). The other problem (obviously seen only by people who don't have the first problem, or have it only intermittently) is that if the system is left continuously idle over two or more consecutive midnights, the date gets advanced by only one day. This latter problem has to do with the fact that DOS records the passage of a new day by *setting* (*not* incrementing) a flag that is supposed to get noticed the next time the system does something. ======================================================================== From: rde@ukc.ac.uk (R.D.Eager) Subject: Re: Date not advancing at midnight on my clone Message-ID: <2666@eagle.ukc.ac.uk> Date: 8 Mar 87 17:43:17 GMT Organization: U of Kent at Canterbury, Canterbury, UK I had this problem on MS-DOS 2.11 on a British PC clone. I also managed to fix it, but the nature of the fix means that it works ONLY for one version (and OEM implementation) of DOS. The BIOS time of day call (INT 1AH) is what DOS uses to get the time. This is used by the DOS kernel only to get the time of day. The call returns the time in CX/DX, and a flag (indicating date rollover) in AX. This flag is nonzero if the day has rolled over since the last call, and by definition is returned ONCE ONLY after a given midnight. Now, the real problem is that the OEM portion of DOS may also call the INT 1AH function, and many implementations do this to provide a timeout on disk access in order to make up for the lack of door latch status on IBM style floppy drives. The details don't matter, but a call from one of these just after midnight clears the rollover flag so that the DOS kernel never sees it. My solution was messy (and doesn't handle the case of an idle machine being left for a weekend), but it does work. First, scan thru the DOS file IO.SYS or IBMBIO.COM, looking to INT 1AH calls. Find the one that seems to do something with AX on return. Figure out from this code (easier than it sounds) the word where DOS obviously keeps the day number. Second, write a little intercept (TSR) routine for INT 1AH. Do nothing on the way in, but on the way out check AX. If it is nonzero, clear it and increment the DOS day number yourself. This WORKS. But, you need a different version for different versions and flavours of DOS (because the day number isn't always in the same place). It's a good idea to put some checks in to stop it being used on the wrong version and zapping some other word. -- Bob Eager rde@ukc.UUCP rde@ukc ...!mcvax!ukc!rde Phone: +44 227 66822 ext 7589 ======================================================================== From: jsa@kolvi.UUCP (Jari Salminen) Subject: DOS 3.20 bug Message-ID: <1139@kolvi.UUCP> Date: 25 Mar 87 15:36:21 GMT Organization: Helsinki University of Technology, Finland I noticed a really silly bug in MS-DOS 3.20 (maybe in PC-DOS 3.2 too). DOS doesn't change date after midnight !!!!!!!! ----------------------------------------------- And this is why: Code to read time (in DOS CLOCK$ device driver in IO.SYS) XOR AH,AH ; read Time-of-day from BIOS INT 1Ah MOV BX,DX ; Note! Timer-overflow-flag in AL is LOST ! MOV AX,CX ... some code to calculate time MOV AX,CS:[0E53] ; read OLD DATE ! STOSW ; and store date to buffer However, few bytes later in drive device driver in the same IO.SYS is the correct version to handle the same interrupt: XOR AH,AH INT 1Ah OR AL,AL ; check if timer overflow has occurred JZ over ; if not, skip date updating INC WORD PTR CS:[0E53] ; Update date over: ... So, if the first command you're giving just after midnight has something to do with time ('dir', file saving etc.), the date update is lost. BUT, if you change drive or give command like 'dir a:' when A: is empty, the date is updated correctly !!!!! That bug was NOT in DOS 3.1, so it seems that Microsoft has done a good job bugging DOS 3.2 (remember all those other bugs in 3.2 :-). While waiting update, we should a) never work "Round Midnight" :-) b) reboot our systems at midnight (cause this bug in DOS does not affect to real time clocks) c) write a new clock device driver for DOS 3.2 I think I'll choose c) ! Jari -- Jari Salminen ! UUCP: jsa@kolvi.UUCP Helsinki University of Technology ! Otakaari 5 A ! SF-02150 Espoo, Finland ! tel: +358 0 4512918 ======================================================================== From: manes@dasys1.UUCP (Steve Manes) Subject: Re: Standard date bug Summary: The BIOS Timer Bug Message-ID: <2049@dasys1.UUCP> Date: 23 Nov 87 08:04:06 GMT Organization: The Big Electric Cat, NYC, NY In article <7457@eddie.MIT.EDU>, nathan@eddie.MIT.EDU (Nathan Glasser) writes: > > This is a question about the standard bug that many people know > about regarding the date maintained in memory on standard > pc's and many clones. If your computer is on when midnight comes > around, the date will not be changed. I don't know whether this > always happens or only sometimes. > Does anybody have any simple solution that they've been using? Yes, although I believe that DOS 3.2 fixed this problem (I could be wrong; I still use 3.1). The problem lies in a "sticky flag" maintained by the BIOS timer in the ROM_BIOS_DATA segment. The structure of this segment is: ROM_BIOS_DATA SEGMENT @40h org 6Ch timer_low dw ? ; count up to 65535...(18.2x/sec) timer_hi dw ? ; then increment this (every hour) until... timer_ofl db ? ; we hit midnight and we inc' this. ROM_BIOS_DATA ENDS Whenever DOS calls BIOS to read the current real-time clock, it runs Interrupt 1Ah (see Tech Ref) and a single line of code that is executed during any TIME_OF-DAY "read time" call: mov timer_ofl,0 ; get overflow and reset flag In other words, every time Int 1Ah is called to read the time, whether from the DOS TIME/DATE routines or from your own homebrew to count the number of timer ticks, 'timer_ofl' is reset to zero and its previous contents returned in AL by Int 1Ah. The sticky widget: DOS needs this flag so it knows that the date has rolled over. If your application calls Int 1Ah before DOS gets it (and remember that this flag is set only ONCE every 24 hours and read only ONCE and then reset) DOS will simply roll the clock over but not the day. There are a few fixes that come to mind but the easiest by far is to write your own Int 1Ah replacement that DOESN'T reset 'timer_ofl'. Fortunately, this is an easy task since Int 1Ah doesn't do very much. What I do is use this routine whenever I need to read the timer block: push es mov ax,40h mov es,ax mov ax,word ptr es:[6Ch] mov my_timerlo,ax mov ax,word ptr es:[6Eh] mov my_timerhi,ax pop es That eliminates the problem. -- +----------------------------------------------------------------------- + Steve Manes Roxy Recorders, Inc. NYC + decvax!philabs!cmcl2!hombre!magpie!manes Magpie BBS: 212-420-0527 + uunet!iuvax!bsu-cs!zoo-hq!magpie!manes 300/1200/2400 ======================================================================== From: dons@killer.UUCP (Don Simoneaux) Subject: Re: Standard date bug Summary: fix for date bug Message-ID: <2269@killer.UUCP> Date: 1 Dec 87 04:49:50 GMT Organization: The Unix(R) Connection, Dallas, Texas In article <436@silver.bacs.indiana.edu>, creps@silver.bacs.indiana.edu (Steve Creps) writes: > In article <598@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: > >The bug *always* occurs. There's a discussion of it in Norton's Programmers > >Guide to the PC. > > I saw Norton's comment, and it says DOS 2.00 didn't consistently update > the date on the midnight signal, but that 2.10 and all other versions do. > I could still swear that it still happens in 3.2, but I haven't done any > scientific checks on this. I ran MS-DOS 2.11 on my PC compatible for two years without seeing this problem. When I upgraded to 3.2 about a year ago to make better use of my new 30 MB hard disk, it appeared. I had seen this a long time ago on a Wang PC, probably running 2.0. From what I have read, MS fixed this in going from 2.0 to 2.1 but it mysteriously reappeared in later versions. They probably fixed it again in 3.21 (I hope). I have seen a technical explanation which I am unable to repeat, but I found the following file on a bulletin board earlier this year. Put this file (CLOCKFIX.SYS) in the root directory and put the line "DEVICE = CLOCKFIX.SYS" in your CONFIG.SYS file. I believe this patches the timer tick interrupt vector to properly handle the midnight flag. I have been using this since early this year and have had no problems. UUENCODED file follows: begin 644 clockfix.sys M_____PB ,@ ] $-,3T-+)" @ ^ 6L :P!K . 9@!P ' A "$ M ' < NB1X2 "Z,!A0 R_Q04U%25E=5'@8NQ1X2 (I' CP+=QB+3Q+$?PX. M'[X: +0 _ #\/\DN #ZPBX X'K [@ <4>$@")1P,''UU?7EI96UC+)HL% MHQ8 )HM- B:+502P//;EM0 #P;EP%XO:]^&+R+!D]N<#R(/2 +< \N#T@"2 MD;L+Z??CA]&2]^,#P8/2 )*[!0#V\XK(M0"*Q)B2]_.+T(D.& "T <T:ZY S MP,T:.PX8 ',$_P86 (D.& "+P8O:T>+1T='BT=$#TQ/!DKD+Z??QB]@SP/?Q MB].YR #W\8+Z9'(#@NID]8K:T="R -'2N3P ]_&*^O;QAN!0H18 JUBKB\.K MZ3+_Q!X2 ";'1PX^ 2:,3Q#I(?\ 8 end -- Don Simoneaux Phone: (214) 964-1859 3605 Interlaken Dr. Plano, TX 75075 USENET: ...ihnp4!killer!dons ======================================================================== -- Rich Wales // UCLA Computer Science Department // +1 (213) 825-5683 3531 Boelter Hall // Los Angeles, California 90024-1596 // USA wales@CS.UCLA.EDU ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales "No, the name of my ship is the _Lollipop_. It's a good ship."