
                  OS/2 Programming                 (Fidonet)

                 Saturday, 27-Nov-1999 to Friday, 03-Dec-1999

+----------------------------------------------------------------------------+

From: George White                                      25-Nov-99 10:16:11
  To: Ian Moote                                         27-Nov-99 06:01:29
Subj: Basic Pds Y2k Ok

Hi Ian,

On 23-Nov-99, Ian Moote wrote to MURRAY LESSER:


 ML>>> All the versions of DOS and Windows that I've tested are safe
 ML>>> for Y2K, and all of my documentation implicitely indicates that
 ML>>> _all_ versions of DOS are safe for Y2K.

 ML>> You must have tested on new hardware.  DOS and the DOS-based
 ML>> versions of Windows use the BIOS driver for the real-time clock,
 ML>> and old hardware has a bug in its RTC BIOS.

But Murray, the fact that the old BIOSs can have what you (and I)
consider a bug affecting Y2K does not make DOS itself have a Y2K bug.

 IM> Perhaps I should clarify my question here. [:) I'm far less
 IM> concerned with RTC roll-over as I am with whether the O/S will be
 IM> able to accurately report dates beyond 31 December 1999. [:) Do
 IM> you know of _any_ versions of OS/2 which will have trouble doing
 IM> that?

I believe the base OS is OK in all versions > OS/2 2.0.

 ML>> Without an add-on software fix for the machine's BIOS, the
 ML>> century value for the RTC will not turn over on 1/1/2000. [...]

Murray, that's just not true. All that is needed it to update the RTC
after the century has changed from within an application. The change
then sticks, and is what I've done for my commercial code that runs
7*24.

 ML>> It is only when you shut down and reboot that you will find out
 ML>> whether or not you have the BIOS bug.

 IM> I've no wish to begin a thread/discussion or to argue with you,
 IM> but just for the sake of expressing a point of view, I disagree
 IM> with the point of view of there being a "bug" in so-called "older
 IM> hardware". My point of view here is that since the limitations of
 IM> the RTC were well-known at the time it was implemented into the
 IM> AT, and that since this limitation was well-known to those who
 IM> implemented the BIOS, and that since both the RTC and the BIOS are
 IM> both performing exactly the way that they are intended and
 IM> expected to, that there is no "bug".

 IM> JMO. [:)

I consider it a bug that, knowing the RTC hardware itself did not
update the century byte, the early BIOS writers did not include code
to do it. However it's all history now...

 ML>> The basic OS/2 operating system (at least since Warp 3) takes
 ML>> care of "buggy BIOS" machines, and the OS/2 system clock (which
 ML>> is the RTC, not a separate set of counters) will not die until
 ML>> the end of 2079 ("end of time" for OS/2 as presently written).

 IM> Is this true of _all_ versions of OS/2, that they all use the RTC
 IM> for for their TOD clock? (Is the 2079 a C thing?)

Afaiaa it is true of all versions since OS/2 2.0.
The 2079 is an OS/2 thing. Years >= 80 are considered to be 19xx,
years < 80 are considered to be 20xx. The C thing hits in 2038, when
for most compilers the time counter goes negative (Watcom C uses an
unsigned counter which is good to 2106).

George

--- Terminate 5.00/Pro 
 * Origin: A country point under OS/2 (2:257/609.6)

+----------------------------------------------------------------------------+

From: George White                                      25-Nov-99 10:39:17
  To: Thomas Seeling                                    27-Nov-99 06:01:29
Subj: decompiling INF?

Hi Thomas,

On 20-Nov-99, Thomas Seeling wrote to All:

 TS> i have lost the source code for INF files of a project. Is there a
 TS> possibility to decompile an INF file so that I can enhance and
 TS> recompile

Look for INFCNB79, which converts .INF files to text. It should be
somewhere on Hobbes.
Another possibility is TOTEXT40 by the same author.

Unfortunately neither is available from my boss and I don't have them
to upload :-(.

George

--- Terminate 5.00/Pro
 * Origin: A country point under OS/2 (2:257/609.6)

+----------------------------------------------------------------------------+

From: MIKE RUSKAI                                       26-Nov-99 20:35:00
  To: JONATHAN DE BOYNE POLLARD                         27-Nov-99 12:32:29
Subj: "Paging Peter Knapper! ..

Some senseless babbling from Jonathan De Boyne Pollard to Mike Ruskai
on 11-18-99  09:45 about "Paging Peter Knapper! .....

 JDBP>> runs of zero bytes.  LX executables generally do not.  (I say
 JDBP>> "generally", because if they use Watcom C/C++ the linker doesn't
 JDBP>> support compression, alas.  This is a deficiency in Watcom's
 JDBP>> linker, and an unfortunate example of the "jack of all trades,
 JDBP>> master of none" adage.)  This is, of course, visible in the
 JDBP>> comparative sizes of Win32 and 32-bit OS/2 executables. 
 
 MR> FYI, folks, one needn't rely on the compression abilities of a linker
 MR> in OS/2 to compress an executable.
 MR>
 MR> There's a utility called LxLite which you can use to compress or
 MR> recompress an executable.

 JDBP> Since I use the Watcom linker myself, I'm interested.  Where ? Hobbes
 JDBP> ? DevCon ?

ftp://hobbes.nmsu.edu/pub/os2/archiver/lxlt121.zip
ftp://hobbes.nmsu.edu/pub/os2/archiver/lxlt121src.zip

The second file is the source code.

Mike Ruskai
thannymeister@yahoo.com


... You still run?  Only when chased.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
 * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)

+----------------------------------------------------------------------------+

From: George White                                      26-Nov-99 15:16:14
  To: Murray Lesser                                     28-Nov-99 06:01:14
Subj: Basic Pds Y2k Ok

Hi Murray,

On 19-Nov-99, Murray Lesser wrote to Fred Springfield:

<snip>

 ML>> In case there is anyone out there besides me who is still
 ML>> using the vintage-1990 MS BASIC PDS v 7.1 compiler running as a
 ML>> "native OS/2" application (not in a VDM!):

I've got it on floppy somewhere... It'll probably need an
archeological dig through my stuff to find it though :-).

 ML>> I made a small test of the DATE$ function (compiled and linked
 ML>> for both real (VDM) and protected (native OS/2) modes with my
 ML>> system clock cranked up a year.  The full source code of TEST.BAS
 ML>> was: PRINT DATE$. Both versions returned 11-16-2000, something
 ML>> that was not really expected!

Wow! :-)

 ML> REXX is a great programming tool for quick and dirty jobs, or even
 ML> for jobs that spend most of their activity manipulating text
 ML> files, but I would not use it as a complete substitute for BASIC
 ML> PDS, even though there are things that are easier to do in REXX
 ML> than in any other language that I know: anything that "needs" the
 ML> REXX PARSE statement. But I prefer PL/I to any other language that
 ML> I know for "real" text-mode applications.  I tried "porting" a few
 ML> BASIC PDS programs to C (before I began to learn PL/I), but gave
 ML> up; C is just too clumsy a language to be useful for programs with
 ML> a lot of text manipulation, Kernighan and Ritchie to the contrary
 ML> notwithstanding.

But the IBM pricing for PL/I puts it outside my pocket :-(.

C is a useful general purpose language for many purposes, but for
string handling it's a pain, and it's lack of built in number
crunching capabilities is a limitation for other applications.

 ML> FS>But, surprise, surprise.  How do you run it as an OS/2
 ML> application?

 ML> You have to remember that "native OS/2" for the BASIC PDS compiler
 ML> (and protected-mode applications written in it) are 16-bit
 ML> text-mode OS/2 programs, because the only version of OS/2 that
 ML> Microsoft recognized at the time was 1.0.  However, since IBM is a
 ML> very strong believer in backward compatibility, 16-bit OS/2
 ML> programs run fine, unchanged, in 32-bit OS/2.

The "Getting Started" manual says OS/2 V1.1 or higher is required.

 ML> It has been over six years since I installed BASIC PDS to run in
 ML> "protected mode" and I'm not sure that I could do it today, since
 ML> I seem to have lost any "getting started" documentation that came
 ML> with the compiler.  I suppose, if I had to, I would try by
 ML> starting with SETUP.EXE on the first distribution diskette,
 ML> telling it to load the BINP directory as well as the others.  (A
 ML> small test this morning indicated that SETUP would run in a VDM.)

I've still got my copy of "Getting Started" for Microsoft PDS 7 :-).
I've just dug it out and, yes, _all_ the installation is done via
SETUP.EXE. Isn't SETUP a bound program? Given the fact that DOS
support back then was via the "penalty box" I would have expected it
to be bound. There is no useful information about installation in the
Getting Started manual other than the suggestion that all
installations are done to new directories as it says "Note that Setup
may replace existing files.". The only other useful information is
about adding the path to the DLLs (it says \BC7\BINP) to LIBPATH and
either adding the contents of NEW-VARS.CMD to config.sys or running
the file from the command line before invoking the compiler.

Aside. I checked the spelling of "invoke", and this is the dictionary
definition.

"1. to call upon (an agent, esp. God or another deity) for help,
inspiration etc. 2. to appeal to (an outside agent or authority) for
confirmation, corroboration, etc. 3) to implore or beg (help, etc.).
4.to summon (a spirit, demon, etc); conjure up."

It struck me as most apt :-).

George

--- Terminate 5.00/Pro 
 * Origin: A country point under OS/2 (2:257/609.6)

+----------------------------------------------------------------------------+

From: David Noon                                        27-Nov-99 19:06:16
  To: Jonathan de Boyne Pollard                         28-Nov-99 06:01:14
Subj: Packing executables

Hi Jonathan,

Replying to a message of Jonathan de Boyne Pollard to MIKE RUSKAI:

 MR>> FYI, folks, one needn't rely on the compression abilities of a linker
 MR>> in OS/2 to compress an executable.  There's a utility called LxLite
 MR>> which you can use to compress or recompress an executable.

 JdBP> Since I use the Watcom linker myself, I'm interested.  Where ?
 JdBP> Hobbes ? DevCon ?

There is a simpler utility called REPACK.EXE that has been on the DevCon CD's
for about 4 years now. It will decompress a .EXE or .DLL, or compress it using 
either /EXEPACK:1 or /EXEPACK:2 compression algorithms. I think it installs
with the DTK, otherwise it will be with the general developer tools.

Regards

Dave
<Team PL/I>

--- FleetStreet 1.24.1
 * Origin: The man who broke the bank at Monte Carlo (2:257/609.5)

+----------------------------------------------------------------------------+

From: Mario Semo                                        19-Nov-99 08:09:09
  To: Fred Springfield                                  28-Nov-99 10:51:06
Subj: Environment Variables

Hallo Fred!

Antwort auf eine Message von Fred Springfield an All:

 FS> I recently installed VACPP v3.0 on my system, which has Warp 4 + FP10,
 FS> Lotus S/S for OS/2, and VA Basic.

 FS> In the config.sys there are conflicting SET statements put in by these
 FS> 3 programs for TMP, SMTMP, SOMBASE, and SOMRUNTIME.

 FS> Do I need to consolidate these some how to eliminate the duplication 
 FS> and/or conflicts?  If so, what is the best way to do it?

a) do you still know the old statements? if so, please post the old and the
new ones
b) where on you machine have you installed SOM? there is one version installed 
with WAPR4, and one with VACPP. as i remember, the VACPP version is
incomplete, and older as the OS2 version. 
c) do you plan to USE SOM in your apps (dont do it)
d) cursious, you didnt mention SOMIR and all of the other SOM variables. and
PATH, and libpath. ... VACPP put itself, as i remember, on the first ,
leading, position of path and libpath (e.g.) and so SOM references (.DLL,
.EXE) are resolved via VACPP (but , as i said, VACPP is incomplete and is a
SOM 2.1beta, while OS2 WARP4 has SOM 2.1.4 installed. so, accepting vacpp in
the leading position, backgrades your SOM version.

i have 3 versions of SOM installed, and these are:

Directory of I:\os2 (SOM 2.1.4)

 5.02.96  15.36      24928           0  SOMDD.EXE
 5.02.96  15.36      22816           0  SOMDSVR.EXE

13.08.96   9.29      88763           0  SOM.DLL
16.08.96   1.49     267470           0  SOMD.DLL
 5.02.96  15.38      40084           0  SOMEM.DLL
 5.02.96  15.38      87628           0  SOMIR.DLL
 5.02.96  15.38      23106           0  SOMS.DLL
 5.02.96  15.38      32878           0  SOMSEC.DLL
 5.02.96  15.38      30484           0  SOMTC.DLL
 5.02.96  15.38      81044           0  SOMU.DLL
 5.02.96  15.38      81700           0  SOMUC.DLL

 9.08.96   2.49       6384           0  SOMDCLS.DAT
 9.08.96   2.49       6844           0  SOMDCLS.TOC
 9.08.96   2.49       1012           0  SOMDIMPL.DAT
 9.08.96   2.49         60           0  SOMDIMPL.TOC

 5.02.96  15.38      15056           0  SOMD.MSG
 5.02.96  15.38        780           0  SOME_OS2.MSG
 5.02.96  15.38       3718           0  SOMK.MSG

Directory of F:\ibmcpp\bin\som (VACPP SOM 2.1beta)

20.10.94  10.00       1426           0  SOMCORBA.CMD
27.04.95  16.05     330472           0  SOMCPP.EXE
20.10.94  10.00      45440           0  SOMDCHK.EXE
27.04.95  16.05      37952           0  SOMDD.EXE
27.04.95  16.05      34928           0  SOMDSVR.EXE
20.10.94  10.00       1556           0  SOMENV.CMD
27.04.95  16.05     147600           0  SOMIPC.EXE
27.04.95  16.05     106668           0  SOMOPC.EXE
20.10.94  10.00       1456           0  SOMSTARS.CMD
20.10.94  10.00       1060           0  SOMXH.CMD

 6.07.95   8.57     447164           0  SOM.DLL
27.04.95  16.05     151102           0  SOMC.DLL
27.04.95  16.05     430862           0  SOMD.DLL
20.10.94  10.00       8941           0  SOMDBG.DLL
27.04.95  16.05     160500           0  SOME.DLL
27.04.95  16.05      59764           0  SOMEM.DLL
27.04.95  16.05     132892           0  SOMIR.DLL
27.04.95  16.05      31138           0  SOMS.DLL
27.04.95  16.05      39027           0  SOMST.DLL
27.04.95  16.05      40420           0  SOMTC.DLL
27.04.95  16.05     125684           0  SOMU.DLL

Directory of F:\som21\LIB  SOM toolkit (SOM 2.1.2)

 2.10.95  11.54     130955           0  som.dll
 2.10.95  11.54     155710           0  SOMC.dll
 2.10.95  11.54     182854           0  SOMCD.dll
20.10.94  10.00      80393           0  SOMCT.dll
23.01.96   0.41     505049           0  somd.dll
20.10.94  10.00       8941           0  SOMDBG.dll
 2.10.95  11.54     160196           0  SOME.dll
 2.10.95  11.54      59700           0  SOMEM.dll
 2.10.95  11.54     132044           0  SOMIR.dll
20.10.94  10.00     183156           0  SOMP.dll
 2.10.95  11.54      31138           0  SOMS.dll
 2.10.95  11.54      33443           0  SOMSA.dll
 2.10.95  11.54      55278           0  SOMSEC.dll
 2.10.95  11.54      39027           0  SOMST.dll
20.10.94  10.00      32101           0  SOMST32.dll
 2.10.95  11.54      42432           0  SOMTC.dll
 2.10.95  11.54     126228           0  SOMU.dll
 2.10.95  11.54     145812           0  SOMUC.dll
       40 file(s)    3031341 bytes used





Servus, Mario!

--- FleetStreet 1.21 PR#2
 * Origin: LC/32 Development Team, http://www.kirchnersoft.com (2:310/14.11)

+----------------------------------------------------------------------------+

From: Ian Moote                                         29-Nov-99 09:59:00
  To: GEORGE WHITE                                      30-Nov-99 21:01:14
Subj: Basic Pds Y2k Ok

GW> I believe the base OS is OK in all versions > OS/2 2.0.

Greater than v2.0? If you know that v2.0 os "no-good" then that will 
answer my question. Can you tell me what the problem was with v2.0?


GW> IM> Is this true of _all_ versions of OS/2, that they all use the
GW> IM> RTC for for their TOD clock? (Is the 2079 a C thing?)
GW>
GW> Afaiaa it is true of all versions since OS/2 2.0. The 2079 is an
GW> OS/2 thing. Years >= 80 are considered to be 19xx, years < 80 are
GW> considered to be 20xx.

What?! I don't understand this. DOS is good until 2099, being limited, 
really, only by the directory structure, but surely to gawd OS/2 is good 
until at _least_ then! No, this doesn't sound right. I've got to check 
this out. Hold on...

...

Aw man! This really bites! I set my RTC to 2080 and OS/2 thought that it 
was 1980! What an abortion! So what am I supposed to do in 2080 -- go 
back to DOS? Yahoo. Don't throw out those copies of Himem.Sys and 
Mscdex, folks -- what's old will be new again!

I'm not even going to say any more about it because this _really_ ticks 
me off.


GW> The C thing hits in 2038, when for most
GW> compilers the time counter goes negative (Watcom C uses an unsigned
GW> counter which is good to 2106).

Heh... okay, thanks a lot. Take care and TTYL!

---
  User (n.):  technical term used by programmers;  qv. idiot.                
        
                                                                      
---
  User friendly: Needs 12 megs of RAM and 86 megs of HD space.               
         

--- AdeptXBBS v1.11y (FREEWare/2)
 * Origin: Moote Pointe (1:2424/140)

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    28-Nov-99 14:28:04
  To: Mike Ruskai                                       30-Nov-99 21:01:14
Subj: "Paging Peter Knapper! ..

Hello Mike,

26 Nov 99 20:35, MIKE RUSKAI wrote to JONATHAN DE BOYNE POLLARD:

MR> ftp://hobbes.nmsu.edu/pub/os2/archiver/lxlt121.zip
MR> ftp://hobbes.nmsu.edu/pub/os2/archiver/lxlt121src.zip

the first zip file I've here was in the 800 KB range in size.

since the first file I have also contains the second file (same filename, as
far as I can see identical contents) it seems to me unnecessary to download
also the second file.

I've converted both to RAR format:

17-08-97 23:10        343.483      0 a---  lxlt121.rar
21-08-97  2:01        360.200      0 a---  lxlt121src.rar

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... Window Error: Unable to exit windows.  Try the door.
--- GoldED/2 3.0.1
 * Origin: Windows98 is a graphic DOS extender (2:280/5143.7)

+----------------------------------------------------------------------------+

From: Fred Springfield                                  30-Nov-99 01:01:19
  To: Mario Semo                                        30-Nov-99 21:01:14
Subj: Environment Variables

MS>  FS> I recently installed VACPP v3.0 on my system, which has Warp 4 +
FP10,
MS>  FS> Lotus S/S for OS/2, and VA Basic.
MS> 
MS>  FS> In the config.sys there are conflicting SET statements put in by
these
MS>  FS> 3 programs for TMP, SMTMP, SOMBASE, and SOMRUNTIME.
MS> 
MS>  FS> Do I need to consolidate these some how to eliminate the duplication 
MS>  FS> and/or conflicts?  If so, what is the best way to do it?
MS> 
MS> a) do you still know the old statements? if so, please post the
MS> old and the  new ones b) where on you machine have you installed SOM?
MS> there is one version installed  with WAPR4, and one with VACPP. as i
MS> remember, the VACPP version is  incomplete, and older as the OS2
MS> version.  c) do you plan to USE SOM in your apps (dont do it) d)
MS> cursious, you didnt mention SOMIR and all of the other SOM
MS> variables. and  PATH, and libpath. ... VACPP put itself, as i
MS> remember, on the first ,  leading, position of path and libpath
MS> (e.g.) and so SOM references (.DLL,  .EXE) are resolved via VACPP
MS> (but , as i said, VACPP is incomplete and is a  SOM 2.1beta, while
MS> OS2 WARP4 has SOM 2.1.4 installed. so, accepting vacpp in  the
MS> leading position, backgrades your SOM version.
 
Hi Mario-

Thanks for your input.  One of the IBM developers recommended that I
be sure to put the VACPP dll's after the OS/2 dll'l in the LIBPATH, and
also the similar thing for the PATH statement, because the OS/2 stuff is
newer.

No, I do not plan to use SOM in any of my programs.

However, I still have a conflict with the SET SOMRUNTIME statement
which is generated by VACPP and Lotus S/S, and points to different
directories.

Fred Springfield
Plymouth, MN


  KWQ/2 1.2i  If at first you don't succeed, try again--harder.

--- ProBoard v2.16 [Reg]
 * Origin: RiverWorks * ProBoard Beta Site * V34+ * (1:282/4093)

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         25-Nov-99 09:28:13
  To: Ian Moote                                         30-Nov-99 21:01:14
Subj: OS/2 kernel immunity from the Century Bug

 IM> Perhaps I should clarify my question here. [:) I'm far less concerned 
 IM> with RTC roll-over as I am with whether the O/S will be able to 
 IM> accurately report dates beyond 31 December 1999. [:) Do you know of 
 IM> _any_ versions of OS/2 which will have trouble doing that?

16-bit OS/2 (/i.e./ version 1.x) provides only a means for directly reading
the RTC hardware, Dos16GetDateTime().  It returns the date and time as a
broken-down structure, the members of which are either UCHARs or USHORTs.  The 
`Year' field, in particular, is a `USHORT' meaning that the data structure can 
cope with years up until the year 65535.

The 16-bit OS/2 kernel, therefore, can quite happily report dates up to the
limit imposed by the PC hardware and firmware (with the "windowing" fix that
is most commonly applied by BIOS manufacturers), which is 2079-12-31 .

32-bit OS/2 (/i.e./ version 2.0 and later) is similarly limited by the PC
hardware and firmware, but *it* reports dates as a 64-bit number, counting the 
seconds since the start of the POSIX Epoch (1970-01-01 00:00:00 GMT).  This is 
via the new (relatively speaking) 32-bit system API function
Dos32QuerySysInfo().  (The Dos32GetDateTime() function is still there, for
backwards compatibility and ease of porting 16-bit applications, but this is
really the wrong way to obtain the system time on 32-bit OS/2, since it hits
the clock hardware directly.) This means that in theory, were the hardware and 
firmware encumbrances not there, the 32-bit OS/2 kernel could report dates up
until the year 584,000,000,000 (roughly) to applications.

Operating system kernels are generally the wrong place to look for Year 2000
problems.  Kernels generally don't have much to do with dates and times, other 
than attaching them to files and reporting the current system date+time to
applications.  The main area where the Century Bug rears its ugly head is in
applications programs.  The version of Windows File Manager that ships with
OS/2 2.1, for example, uses two digits for a year when displaying file lists
and cannot handle displaying years after 1999 (it displays non-digit ASCII
characters in the year field).

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         25-Nov-99 10:02:16
  To: Eddy Thilleman                                    30-Nov-99 21:01:14
Subj: PROMPT $I in PMCMD

 JP>> I'm looking for a solution that is 32-bit.  Therefore I'm looking for
 JP>> a solution that uses the ordinary 32-bit Presentation Manager API.
 JP>> There must be an efficient way of drawing fixed-width text in
 JP>> multiple colours using the GPI.

 ET> Have you thought about DIVE?

Not really.  It's an interesting thought.  But I'm actually having a hard time 
tackling the original problem.  Now that I've upgraded my hardware, the
problem is almost unnoticable (whereas on a 486 with VGA it was very
noticable), and so it's difficult to test any fixes for it that I implement to 
determine whether or not they make any difference.  (-:

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         27-Nov-99 12:09:10
  To: Murray Lesser                                     30-Nov-99 21:01:14
Subj: BIOS Y2k Bugs

 ML> I surmise (JdeBP probably knows) that the OS/2 CLOCK$ drivers read 
 ML> only the two low-order digits of the RTC clock year, and effectively 
 ML> put the two upper digits into the CMOS "century byte" by using 
 ML> windowing:  Any year shown as greater than 79 gets 19 in that byte; 
 ML> any year less than 80 gets 20.  

Excerpted from the `calc_year_sec' routine in CLOCK01.ASM off the OS/2 Warp 4
DDK:

------------------------------------------------------------------------
DATEOK:
; if year is over 20 centry ( year < 80 )
;    year += 100
        XOR     AH,AH                   ; AX = LOWER PART OF YEAR
        CMP     AL,80                   ; Is it 20xx?
        JGE     calc20                  ; No, Add only 1900
        ADD     AX,100                  ; Yes, add extra 100
; year += 1900
; save on stack
calc20: ADD     AX,1900                 ; AX = Year and century
        MOV     century_year,ax         ;
        SUB     AX,1980                 ; Get years since 1980
------------------------------------------------------------------------

This routine is called from `FIXISEG', which is the routine that reads from
the RTC registers and writes into the (16-bit) global infoseg.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

+----------------------------------------------------------------------------+

From: Jonathan de Boyne Pollard                         29-Nov-99 11:07:03
  To: Ian Moote                                         30-Nov-99 21:01:14
Subj: Clocked!

 IM> Is this true of _all_ versions of OS/2, that they all use the RTC for 
 IM> for their TOD clock? 

On a PC, what else *can* they use ?

Indeed, you'll be hard pressed to find *any* general purpose operating system
on any platform (apart from very old versions of DOS) that *doesn't* use
real-time clock hardware for its system clock.  

Even operating systems such as Xinu use RTC hardware of some sort.

 IM> Is the 2079 a C thing?

No.  The limits of 32-bit implementations of the C language and the C++
language are 2038-01-19 and 2106-02-07, respectively, depending from whether
the underlying type of `time_t' is signed or unsigned.

The limits of 64-bit implementations of the C language and the C++ language
are somewhat higher.

The year 2079 limitation is due to the "windowing fix" employed to solve the
problem that the PC's RTC chip in most PCs does not update the century byte in 
NVRAM when the year byte rolls over from 99 to 00.  The original RTC chip that 
was used didn't *have* a century byte.  On most PCs the area where the century 
is stored is not one of the RTC registers, but is just an ordinary NVRAM area. 
 The windowing fix works on the assumptions that years 80 to 99 are in the
20th century and years 00 to 79 are in the 21st century, and patches the
century byte accordingly.

Of course, this is a textbook case of a software bodge to work around a bad
(or at least exceedingly shortsighted) piece of hardware design.

  JdeBP 

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

+----------------------------------------------------------------------------+

From: Rob Basler                                        30-Nov-99 10:26:00
  To: Jonathan De Boyne Pollar                          30-Nov-99 21:01:14
Subj: sendto() doesn't work on

JDBP> RB>      /* Bind the UDP socket to the server address. */
JDBP> RB>      client.sin_family      = AF_INET;    /* Server is
JDBP> RB> in Internet Domain */
JDBP> RB>      client.sin_port        = 0;          /* Any port in a storm */
JDBP> RB>      client.sin_addr.s_addr = INADDR_ANY; /* Server's
JDBP> RB> Internet Address    */
JDBP> RB>      if (bind(s, (struct sockaddr *)&client, sizeof(client)) < 0) {
JDBP> RB>          return(-1);
JDBP> RB>      }

JDBP>What that is actually doing is binding an address to the *local* end of
th
JDBP>socket, not the remote end.  Your comments are wrong.

You're right, the comments were lifted verbatim from one of the toolkit
example files.

JDBP>Given the address that you are binding to the client end, I
JDBP>have to ask:  Is it the *server* end that is receiving the
JDBP>"no route to host" errors ?

I'm sending out a broadcast and then waiting for a response on the same
socket.  It is the broadcast call that is failing with the No route to
host error.  If I specify an address for the call to the server rather
than using a broadcast, it works as expected.

I find it most odd that it works in Warp 4 but not in WSeB.  You'd think
that they would have tested broadcast calls in the 4.1 TCP/IP stack.

Rob.
___
 X SLMR 2.1a X This tagline is umop apisdn

--- Maximus/2 3.01
 * Origin: Frog Hollow Port Moody BC 604-469-0264/0284 (1:153/290)

+----------------------------------------------------------------------------+

From: Ian Moote                                         01-Dec-99 07:23:00
  To: JONATHAN DE BOYNE POLLARD                         01-Dec-99 10:22:08
Subj: Clocked!

JP> IM> Is this true of _all_ versions of OS/2, that they all use the
JP> IM> RTC for for their TOD clock?
JP>
JP> On a PC, what else *can* they use ?

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


JP> Indeed, you'll be hard pressed to find *any* general purpose
JP> operating system on any platform (apart from very old versions of
JP> DOS) that *doesn't* use real-time clock hardware for its system
JP> clock.

Not to be contradictory, but I think that you and I probably have 
different definitions of both "general purpose" and "very old". [:)


JP> Even operating systems such as Xinu use RTC hardware of some sort.

"Of some sort" leaves your butt covered pretty good. [:) Lots of room 
for later justifications. [:)


JP> IM> Is the 2079 a C thing?
JP>
JP> No.  The limits of 32-bit implementations of the C language and the
JP> C++ language are 2038-01-19 and 2106-02-07, respectively, depending
JP> from whether the underlying type of `time_t' is signed or unsigned.

As has been explained, but thank you for the precise dates.


JP> The limits of 64-bit implementations of the C language and the C++
JP> language are somewhat higher.

Understandably. [:)


JP> The year 2079 limitation is due to the "windowing fix" employed to
JP> solve the problem that the PC's RTC chip in most PCs does not update
JP> the century byte in NVRAM when the year byte rolls over from 99 to
JP> 00.

Because of my job I would be very, very interested in hearing any 
factual information concerning an RTC used in a PC which _does_ update 
the century byte.


JP> The original RTC chip that was used didn't *have* a century
JP> byte.

Again, if you have any factual information regarding RTC's which _do_ 
directly employ a century byte, I would be interested in hearing about 
it.


JP> On most PCs the area where the century is stored is not one
JP> of the RTC registers, but is just an ordinary NVRAM area.

Yes, I have quite a bit of experience with that, thank you.


JP> The
JP> windowing fix works on the assumptions that years 80 to 99 are in
JP> the 20th century and years 00 to 79 are in the 21st century, and
JP> patches the century byte accordingly.

Very, very sad. DOS is good until 2099. The RTC/CMOS itself is good up 
to the year 9999. Too bad that IBM felt that they had to break that.


JP> Of course, this is a textbook case of a software bodge to work
JP> around a bad (or at least exceedingly shortsighted) piece of
JP> hardware design.

Yes, I agree. And I've heard that criticism of the AT's RTC before. 
Could you give me the part number for an RTC which was readily available 
in 1983 that tracked real years -- "1983" instead of just "83"?

Thanks for the reply and the additional information. Take care and TTYL.

---
  User-friendly (adj.):  trivialized, slow, incapable, boring.               
         

--- AdeptXBBS v1.11y (FREEWare/2)
 * Origin: Moote Pointe (1:2424/140)

+----------------------------------------------------------------------------+

From: Ian Moote                                         01-Dec-99 07:23:00
  To: JONATHAN DE BOYNE POLLARD                         01-Dec-99 10:22:08
Subj: OS/2 kernel immunity from

JP> 16-bit OS/2 (/i.e./ version 1.x) provides only a means for directly
JP> reading the RTC hardware, Dos16GetDateTime().  It returns the date
JP> and time as a broken-down structure, the members of which are either
JP> UCHARs or USHORTs.  The `Year' field, in particular, is a `USHORT'
JP> meaning that the data structure can cope with years up until the
JP> year 65535.

Excellent!! Directly and unequivocally answers my question! Thank you 
very much! [:)

You did raise another interesting point, however:

JP> (The Dos32GetDateTime() function is still there, for backwards
JP> compatibility and ease of porting 16-bit applications, but this is
JP> really the wrong way to obtain the system time on 32-bit OS/2, since
JP> it hits the clock hardware directly.)

Are you saying that DOSQuerySysInfo() does not get its information 
directly from the clock? If not, how does it keep track of the time?


JP> Operating system kernels are generally the wrong place to look for
JP> Year 2000 problems.

[:))) Yeah, I know. But in my work I can't afford to approach my job in 
a lacadaisical fashion. I've got to know the facts with as little doubt 
as possible.

Thanks for all the info. Take care and TTYL.

---
  Using a TNC is another way to really use a C=64.                        

--- AdeptXBBS v1.11y (FREEWare/2)
 * Origin: Moote Pointe (1:2424/140)

+----------------------------------------------------------------------------+

From: Will Honea                                        01-Dec-99 03:46:01
  To: Fred Springfield                                  01-Dec-99 03:46:01
Subj: Environment Variables

Fred Springfield wrote to Mario Semo on 11-30-1999

FS> 
FS> Thanks for your input.  One of the IBM developers recommended that
FS> I be sure to put the VACPP dll's after the OS/2 dll'l in the
FS> LIBPATH, and also the similar thing for the PATH statement, because
FS> the OS/2 stuff is newer. 

Fred, don't overlook the SOMIR line in config.sys.  I forgot that one
the last time I installed and couldn't figure out why I was having
'wierd' errors - until I happened across it one day.

With Warp 4, it backlevels SOM support which is central to the WPS
stuff.

Will Honea <whonea@codenet.net>
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Will Honea                                        01-Dec-99 21:52:01
  To: Ian Moote                                         01-Dec-99 21:52:01
Subj: Clocked!

Ian Moote wrote to JONATHAN DE BOYNE POLLARD on 12-01-1999

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. 

For the sake of completeness, the RTC is also sync'd by a
read/write/read anytime the set clock API's are called.  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).

Will Honea <whonea@codenet.net>
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: MIKE RUSKAI                                       01-Dec-99 17:42:00
  To: JONATHAN DE BOYNE POLLARD                         03-Dec-99 00:48:13
Subj: Clocked!

Some senseless babbling from Jonathan De Boyne Pollard to Ian Moote
on 11-29-99  11:07 about Clocked!...

[snip]

 IM> Is the 2079 a C thing?

 JDBP> No.  The limits of 32-bit implementations of the C language and the
 JDBP> C++ language are 2038-01-19 and 2106-02-07, respectively, depending
 JDBP> from whether the underlying type of `time_t' is signed or unsigned.

 JDBP> The limits of 64-bit implementations of the C language and the C++
 JDBP> language are somewhat higher.

This strikes me as something of an understatement.

A signed 64-bit integer would make the C timestamp function until the
universe is about 20 times older than it currently is, long after the sun
and earth are gone.

Using the same integer as a millisecond counter would last for over 292
million years.

Mike Ruskai
thannymeister@yahoo.com


... Be careful what you ask for. You never know who's lurking.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
 * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)

+----------------------------------------------------------------------------+

From: Roy J. Tellason                                   02-Dec-99 10:19:21
  To: MIKE RUSKAI                                       03-Dec-99 00:48:13
Subj: Clocked!

MIKE RUSKAI wrote in a message to JONATHAN DE BOYNE POLLARD:

 JDBP> The limits of 64-bit implementations of the C language and the C++
 JDBP> language are somewhat higher.

 MR> This strikes me as something of an understatement.

Yeah,  it struck me the same way...    :-)

--- 
 * Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)

+----------------------------------------------------------------------------+

From: George White                                      01-Dec-99 08:34:26
  To: Ian Moote                                         03-Dec-99 00:48:13
Subj: Basic Pds Y2k Ok

Hi Ian,

On 29-Nov-99, Ian Moote wrote to GEORGE WHITE:


 GW>> I believe the base OS is OK in all versions > OS/2 2.0.

 IM> Greater than v2.0? If you know that v2.0 os "no-good" then that
 IM> will answer my question. Can you tell me what the problem was with
 IM> v2.0?

Sorry, I was careless there :-(. Replace ">" by ">=" :-).

 IM>> Is this true of _all_ versions of OS/2, that they all use the RTC
 IM>> for for their TOD clock? (Is the 2079 a C thing?)
 IM> GW>
 GW>> Afaiaa it is true of all versions since OS/2 2.0. The 2079 is an
 GW>> OS/2 thing. Years >= 80 are considered to be 19xx, years < 80 are
 GW>> considered to be 20xx.

 IM> What?! I don't understand this. DOS is good until 2099, being
 IM> limited, really, only by the directory structure, but surely to
 IM> gawd OS/2 is good until at _least_ then! No, this doesn't sound
 IM> right. I've got to check this out. Hold on...

 IM> ...

 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 in
 IM> 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!

DOS will only get you 20 more years. It breaks in 2100 :-(
Anyway, how many of us are likely to care in 80 years time?

 IM> I'm not even going to say any more about it because this _really_
 IM> ticks me off.

I expect OS/2 to be totally obsolete long before then, and the only
real interest will be in museums (Smithsonian? Science Museum?) where,
if they actually run the machines, having them set to a date
appropriate to their age rather then the current date wouldn't be a
problem.

According to tests run by some of the other echo users the 2079 thing
is *NOT* a problem with OS/2 itself (by that I mean the base OS
resident in memory) but with the support utilities provided with it.
If you've seen JdeBPs postings you'll have noted that the 32 bit OS/2
API returns time as a _64_ bit second count, which lasts for centuries
rather than years.

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

George

--- Terminate 5.00/Pro 
 * Origin: A country point under OS/2 (2:257/609.6)

+----------------------------------------------------------------------------+

From: Fred Springfield                                  02-Dec-99 10:24:16
  To: Will Honea                                        03-Dec-99 00:48:13
Subj: Environment Variables

WH> FS> 
WH> FS> Thanks for your input.  One of the IBM developers recommended that
WH> FS> I be sure to put the VACPP dll's after the OS/2 dll'l in the
WH> FS> LIBPATH, and also the similar thing for the PATH statement, because
WH> FS> the OS/2 stuff is newer. 
WH> 
WH> Fred, don't overlook the SOMIR line in config.sys.  I forgot that
WH> one the last time I installed and couldn't figure out why I was
WH> having 'wierd' errors - until I happened across it one day.
WH> 
WH> With Warp 4, it backlevels SOM support which is central to the WPS
WH> stuff.
 
Thanks.  Guess I missed that one, but someone kindly put a copy of
SOM.IR in my root (c:\) when I installed Warp 4, which is probably
why I haven't seen any weird stuff.

Looks like I drew a full house this time -:)

Fred Springfield
Plymouth, MN


  KWQ/2 1.2i  

--- ProBoard v2.16 [Reg]
 * Origin: RiverWorks * ProBoard Beta Site * V34+ * (1:282/4093)

+----------------------------------------------------------------------------+

From: Murray Lesser                                     02-Dec-99 16:19:00
  To: Will Honea                                        02-Dec-99 16:19:00
Subj: Clocked!

(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
<Team PL/I>
___
 * MR/2 2.25 #120 * Stay alive!  Learn something new every day.

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Ian Moote                                         03-Dec-99 06:55:00
  To: GEORGE WHITE                                      03-Dec-99 13:20:23
Subj: Basic Pds Y2k Ok

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

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

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


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

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


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

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

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


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

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

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

---
  Vegetarianism:  Just another excuse to be picky with food.                 
       

--- AdeptXBBS v1.11y (FREEWare/2)
 * Origin: Moote Pointe (1:2424/140)

+----------------------------------------------------------------------------+

From: Eddy Thilleman                                    02-Dec-99 08:36:18
  To: Jonathan De Boyne Pollard                         03-Dec-99 13:20:23
Subj: PROMPT $I in PMCMD

Hello Jonathan,

25 Nov 99 10:02, Jonathan de Boyne Pollard wrote to Eddy Thilleman:

ET>> Have you thought about DIVE?

JP> Not really.  It's an interesting thought.  But I'm actually having a
JP> hard time tackling the original problem.  Now that I've upgraded my
JP> hardware, the problem is almost unnoticable (whereas on a 486 with VGA
JP> it was very noticable), and so it's difficult to test any fixes for it
JP> that I implement to determine whether or not they make any difference.

True. If you still have your 486, you can test on the 486.

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... WindowError:00E Window open, do not look in.
--- GoldED/2 3.0.1
 * Origin: Windows98 is a graphic DOS extender (2:280/5143.7)

+----------------------------------------------------------------------------+

From: Will Honea                                        03-Dec-99 01:15:00
  To: Fred Springfield                                  03-Dec-99 01:15:00
Subj: Environment Variables

Fred Springfield wrote to Will Honea on 12-02-1999

FS> Thanks.  Guess I missed that one, but someone kindly put a copy of
FS> SOM.IR in my root (c:\) when I installed Warp 4, which is probably
FS> why I haven't seen any weird stuff.
FS> 
FS> Looks like I drew a full house this time -:)

That kinda depends of WHICH copy of SOM.IR got put there <g>. 
Actually, the SET SOMIR= line defines the search order ahead of any
other path statements.
 
Will Honea <whonea@codenet.net>
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

From: Murray Lesser                                     03-Dec-99 20:17:00
  To: George White                                      03-Dec-99 20:17:00
Subj: Basic Pds Y2k Ok

(Excerpts from a message dated 12-01-99, George White to Ian Moote)

Hi George--

GW>On 29-Nov-99, Ian Moote wrote to GEORGE WHITE:

 IM>> Is this true of _all_ versions of OS/2, that they all use the RTC
 IM>> for for their TOD clock? (Is the 2079 a C thing?)
 IM> GW>
 GW>> Afaiaa it is true of all versions since OS/2 2.0. The 2079 is an
 GW>> OS/2 thing. Years >= 80 are considered to be 19xx, years < 80 are
 GW>> considered to be 20xx.

 IM> What?! I don't understand this. DOS is good until 2099, being
 IM> limited, really, only by the directory structure, but surely to
 IM> gawd OS/2 is good until at _least_ then! No, this doesn't sound
 IM> right. I've got to check this out. Hold on...

 IM> ...

 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 in
 IM> 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!

    Come 2080, Ian is going to be very surprised when he attempts to set
his DOS system clock to 1-1-2080.  When he reboots, it will tell him
that the date is 1-1-1980!  And it won't give him the nice warning OS/2
does (error 237, invalid date/time) when he tries to set a date after
2079 from the command line.

GW>DOS will only get you 20 more years. It breaks in 2100 :-( Anyway,
  >how many of us are likely to care in 80 years time?

    It will last 20 more years only if he sets his date prior to
1-1-2080 and never shuts down.  The minute he reboots his system, he's
back to the "century window" effect when the system tries to read the
RTC.  Unless there is a completely new DOS on completely new hardware
before then.  If that comes to pass, I wouldn't mind betting that there
also will be a completely new OS/2 :-).  But I'm with you: I don't
expect a completely new OS/2 on completely new hardware in the
foreseeable future.

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * Prediction is very difficult, especially about the future

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


+----------------------------------------------------------------------------+

+============================================================================+
