IM> I don't know about you, but I intend to be sending E-Mail to my great-
 IM> great-great grandkids over the Galactinet with my super-conducting 
 IM> berylium parallel processing clone from my summer home on Mars. [:)

Another adherent to the Vila school of philosophy.

 GW>> According to tests run by some of the other echo users the 2079
 GW>> thing is *NOT* a problem with OS/2 itself (by that I mean the base OS
 GW>> resident in memory) but with the support utilities provided with it.

 IM> Well, that distinction may mean something to somebody but like I said,
 IM> I  set my RTC to 2080 and OS/2 came up thinking that it was 1980. To
 IM> my way  of thinking, if there were nothing wrong with the base
 IM> operating system  then there would be no need for date windowing in
 IM> the first place. It  seems pretty obvious to me that while OS/2 won't
 IM> have a problem in the  year 2000, this is only due to a kludge and
 IM> OS/2 has a date problem.

OS/2 doesn't have a date problem, though.  Even in 16-bit OS/2 the year value
in the global infoseg is a 16-bit value that can hold values up until 65535. 
What OS/2 has is a design that is limited of necessity by the underlying PC
hardware.  You are basing your reasoning on the assumption that the RTC
hardware is "good until the year 9999".  It isn't.  It's good for exactly 100
years from any given base year.  In the case of the IBM PC/AT, that base year
is 1980, meaning that it is good until the year 2079.

This is because the majority of RTCs do not have proper century registers (due 
to the somewhat ironic fact that because of windowing fixes in operating
systems and BIOSes, hardware manufacturers have not felt compelled to produce
such chips).  An operating system that wants to work on a wide range of PC/AT
or PS/2 compatiable machines can make *no* assumptions about the location of a 
century byte, nor even assumptions about its presence in the first place.

If there were a way of determining unambiguously that there were a century
byte and where it were stored in NVRAM by the BIOS (and there are at least 3
locations that it can be in), the clock driver in OS/2 would be able to obtain 
the century byte and would not need to include a windowing fix.  But there is
no such way for all of the hardware that OS/2 is targetted to run on.  The
ACPI specification provides a means for operating systems to obtain the
location of the century byte in NVRAM, true, but the ACPI specfication is
relatively new.  Older BIOSes simply won't support it.

 ¯ JdeBP ®

--- FleetStreet 1.22 NR