(Excerpts from a message dated 12-01-99, Will Honea to Ian Moote)

Hi Will--

IM> DOS uses internal counters. It only reads the RTC when it boots.
IM> It only  writes the RTC when you set the system time. 

WH>For the sake of completeness, the RTC is also sync'd by a
  >read/write/read anytime the set clock API's are called...

    That little nuisance was added in DOS 3.3 (1987)!  It broke a number
of my home-grown DOS utilities that depended on the complete separation
of the two clocks (except at boot), including the one that corrected the
DOS system clock for the rate (drift) of the RTC.  So I patched the DOS
CLOCK$ driver to eliminate the unwanted connection (see my piece
"Computing Time in C" in the Jan/Feb 1990 issue of Programmer's
Journal).  I later wrote an assembled TSR (never published) that
intercepted this unholy alliance and also provided a cure for the
portion of the "DOS Lost Day" problem that was caused by programs
compiled with the Borland DOS compilers.

HW>                                             ...  There are
  >also several int 21 calls that force a read of the RTC and reset the
  >internal timer to reflect the number of (computed) clock ticks since
  >midnight.  Some of these are in fact the source of the DOS problem of
  >not incrementing the day if you hit the clock routines just right
  >during the midnight roll-over.  To this day there are problems with
  >DOS sessions playing games with time set/read at mifnight under OS/2
  >(and NT for that matter).

    The so-called "DOS Lost Day" problem wasn't usually due to DOS,
especially if you were using a version of DOS later than 3.2 and didn't
leave your system to run unattended on a 24/7 basis.  (See my piece:
"The Midnight Vampire" in Programmer's Journal for Nov/Dec 1991).  The
"lost day" is more likely to be due to running DOS programs around
midnight that were written in C and compiled by compilers that use BIOS
API INT 1Ah, AH=00 to read the time from the system clock, instead of
using the appropriate DOS INT 21h API.  When INT 1Ah, AH=00 is called,
it reads the DOS system clock and resets the BIOS data-area midnight
overflow flag to zero.  If that interrupt was called by DOS, the DOS
CLOCK$ driver used the presence of the flag (before reset!) to update
the DOS system clock date; if the interrupt was called directly from a
running program, the date word was not updated.  Thus, BIOS INT 1Ah was
intended to be used by the operating system only.  But some DOS C
compiler writers apparently did not know this :-(.  The Borland Turbo C
compiler was especially egregious in this respect: it called INT 1Ah,
AH=00 during the startup routine, thereby deleting any BIOS data-area
midnight overflow flag before the program could even ask for the date!
The "lost day" problems you cite are much more likely to have been the
result of the C compiler used (or to improper assembly language
programming) than to DOS, itself :-(.

    I have never experienced the "lost day" problem when running any of
my remaining DOS programs under OS/2 in a VDM, possibly because the only
ones that may have been written in C are the two that I didn't write
myself.  However, if you say so, I have no reason for disbelief :-).

    Regards,

        --Murray

___
 * MR/2 2.25 #120 * Stay alive!  Learn something new every day.

--- Maximus/2 2.02