Technical Notes Database […]
Show full quote
Technical Notes Database
TN839C.txt :How does DOS update the Date at Midnight ?
Category :DEBUG TOOLS
Platform :All
Product :TD 2.0
Description:
MIDNIGHT UPDATE: How does DOS update the DATE at Midnight ?
-----------------------------------------------------------
When BIOS detects that it is midnight, it clears out the tick-counter (unsigned long at location 0x40:0x6C) to start a new day and sets the midnight flag (unsigned int at location 0x40:0x70) to 1. The calendar of the PC, however, is maintained by the CLOCK$ device. When one asks DOS for the time or date (i.e. at the DOS prompt or via INT 0x21, Func. 0x2A/0x2Ch), the latter passes the request to the CLOCK$ device. The device uses the BIOS Function 0x1A to fulfill the request. When called upon, BIOS always returns the contents of the midnight flag in register AL and then resets the flag to zero if necessary. The CLOCK$ device verifies the value in register AL after calling BIOS and adjusts the calendar date if necessary. Then DOS merely returns to the user the answer received from the CLOCK$ device.
However, the above scenario has two major loopholes:
(i) What if somebody other than the CLOCK$ device (i.e. Other than DOS) were to call the BIOS function 0x1A just after midnight?
(ii) What if a machine were to remain running but unattended for two days or more with no requests for the date/time being made to DOS?
Both of the above would result in an incorrect date on the computer. In the first case mentioned above, the caller of INT 0x1A will be notified that Midnight just passed by but the calendar will not be updated since the CLOCK$ device is out of the loop.
BIOS does not treat the Midnight Flag as a counter which must be incremented for each midnight passed by. It merely sets the flag to 1 for each midnight passed. Therefore in the second case above, the CLOCK$ device (if eventually called upon) will be unable to properly identify the actual number of midnights gone by.
What are the solutions ?
------------------------
For the first case mentioned above, direct calls to BIOS for the current date/time should be avoided and DOS should be called instead. This is unfortunately easier said than done. For example, applications performing asynchronous processing must constantly monitor the time which is, at best, difficult to do via DOS calls given the non-reentrant nature of the latter.
For the second case mentioned above, one workaround would be to use a TSR which constantly monitors the Midnight Flag. Once the latter is set, a call to DOS for the current Date is made by the TSR after determining that it is safe to do so. This would ensure that the calendar gets updated when the PC is running but left unattended.
What if my TSR makes calls to BIOS INT 0x1A in the background ?
----------------------------------------------------------------
(According to a message posted in the IBMPRO Forum on CIS, there is a commercial utility which sends faxes at regular intervals and uses BIOS to monitor the time ) ?
In this case the TSR may intercept every call to the BIOS INT 0x1A and determine (via the DOS BUSY FLAG ?) whether the call is actually being made via a DOS call [ To be absolutely certain, the TSR could also TRAP INT 21h ] and if the call is not done via DOS, the TSR can verify the Midnight Flag and take appropriate steps by calling DOS if necessary.
NOTE: The current version of the Borland C++' startup code makes a call to the BIOS Interrupt 0x1A. Running a BC++ application just after midnight may prevent the Calendar Date from being properly updated. Users which do not call any of the C/C++ clock() related functions, can safely comment out lines 264-267 from c0.asm and create a new copy of the startup code object if necessary.
Reference:
7/2/98 10:42:13 AM
