Hi Ian,

On 03-Dec-99, Ian Moote wrote to GEORGE WHITE:


 IM>> Aw man! This really bites! I set my RTC to 2080 and OS/2 thought
 IM>> that it was 1980! What an abortion! So what am I supposed to do
 IM>> in 2080 -- go back to DOS? Yahoo. Don't throw out those copies of
 IM>> Himem.Sys and Mscdex, folks -- what's old will be new again!
 IM> GW>
 GW>> DOS will only get you 20 more years. It breaks in 2100 :-(
 GW>> Anyway, how many of us are likely to care in 80 years time?

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

That's OK for you, I'm single and have no children...
The only people who are recorded as reaching the age I'd be in 2080 if
I was still alive then are characters recorded in the early chapters of
the Bible :-).

 IM> And no, I'm not kidding! [;)

:-)

 IM>> I'm not even going to say any more about it because this _really_
 IM>> ticks me off.
 IM> GW>
 GW>> I expect OS/2 to be totally obsolete long before then,

 IM> Isn't that the kind of thinking that got us into this Y2K corner
 IM> in the first place? [;) OS/2 users  Windows users.

Not really... I'm expecting advances in the hardware platform to loose
us from the historical straightjacket of the PC platform, which while
it was a reasonable design when it had an 4.whatever MHz 8088 as it's
CPU, is totally inappropriate for the power of CPU we have now. Any
version of OS/2 will need to be proted to that platform, and klundges
for external utility code (like the date windowing) can be removed
with the re-write.

 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
 GW>> base OS resident in memory) but with the support utilities
 GW>> provided with it.

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

It _is_ important. If you interrogate the date/time APIs directly you
will have the correct date and time returned, it's only the supplied
utilities that have the problem.

 GW>> If you've seen JdeBPs postings you'll have noted that the 32 bit
 GW>> OS/2 API returns time as a _64_ bit second count, which lasts for
 GW>> centuries rather than years.

 IM> Yep, saw 'em. That makes little difference when the O/S is going
 IM> to commit harikare on 01 January 2080. That makes about as much
 IM> sense to me as those clowns who use a _signed_ integer to store
 IM> hard-drive capacity.

As I keep saying, the OS will no more commit harikari than DOS does at
1/1/2000, when some of the utility programs supplied with it break.

 GW>> Anyway, let's face it, compared with the problem of C time
 GW>> _ending_ for most compilers & current versions of *NIX in 2038
 GW>> it's a _much_ longer time span (100 years as against the 68 of C
 GW>> & *NIX).

 IM> Well, yeah, but sounds suspiciously like saying, "we're not quite
 IM> as bad as everyone else". [:) One of the reasons I don't use C.

No, you've drawn the wrong conclusion from that :-(. Both are problems,
but the *NIX one is *much* more pervasive, it goes from the core *NIX
kernal, through the OS utilities and on into nearly _all_ programs for
it as they are normally written in C. And it's much closer in time...
For OS/2 the core kernal code does not have the problem, it's only the
external utilities that have the problem and they can be replaced by
third party code - indeed Jonathan has, or is in the process of,
providing alternatives that don't suffer from the problem. OS/2
programs written in C (except those compiled using the Watcom
compiler) will have the 2038 problem of course.

 IM> Anyway, question answered. Thanks a lot, George, I really
 IM> appreciate it. Take care and TTYL.

I hope I've cleard up some of your difficulties.

George

--- Terminate 5.00/Pro 
382/92