Simtel MSDOS - Coast to Coast/simteldosarchivecoasttocoast.iso/info/dateroll.fix

Internet Message Format | 1994-03-07 | 11KB

Path: rutgers!ucla-cs!wales
From: [e-mail] (Rich Wales)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Looking for TSR to fix date (LONG)
Date: 15 Sep 88 19:59:03 GMT
Reply-To: [e-mail] (Rich Wales)

In article <[e-mail]> [e-mail] (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: [e-mail] (R.D.Eager)
Subject: Re: Date not advancing at midnight on my clone
Message-ID: <[e-mail]>
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

           [e-mail]
           rde@ukc
           ...!mcvax!ukc!rde

           Phone: [phone] ext 7589

========================================================================

From: [e-mail] (Jari Salminen)
Subject: DOS 3.20 bug
Message-ID: <[e-mail]>
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:  [e-mail]
Helsinki University of Technology      !
Otakaari 5 A                           !
SF-02150 Espoo,  Finland               !   tel:   [phone]

========================================================================

From: [e-mail] (Steve Manes)
Subject: Re: Standard date bug
Summary: The BIOS Timer Bug
Message-ID: <[e-mail]>
Date: 23 Nov 87 08:04:06 GMT
Organization: The Big Electric Cat, NYC, NY

In article <[e-mail]>, [e-mail] (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: [e-mail] (Don Simoneaux)
Subject: Re: Standard date bug
Summary: fix for date bug
Message-ID: <[e-mail]>
Date: 1 Dec 87 04:49:50 GMT
Organization: The Unix(R) Connection, Dallas, Texas

In article <[e-mail]>, [e-mail] (Steve Creps) writes:
> In article <[e-mail]> [e-mail] (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:  [phone]
    3605 Interlaken Dr.
    Plano, TX 75075        USENET:  ...ihnp4!killer!dons

========================================================================
-- Rich Wales // UCLA Computer Science Department // [phone]
   3531 Boelter Hall // Los Angeles, California 90024-1596 // USA
   [e-mail]      ...!(uunet,ucbvax,rutgers)!cs.ucla.edu!wales
   "No, the name of my ship is the _Lollipop_.  It's a good ship."