
                  OS/2 Programming                 (Fidonet)

                 Saturday, 04-Dec-1999 to Friday, 10-Dec-1999

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

From: Will Honea                                        04-Dec-99 00:56:01
  To: Murray Lesser                                     04-Dec-99 00:56:01
Subj: Clocked!

Murray Lesser wrote to Will Honea on 12-02-1999

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

From painful experience I can tell you that Borland wasn't the only
offender.  MSC 4/5/6 all did this as did Watcom 10.0 - 10.6.  I had to
code a workaround to detect the midnight event from the elapsed time
counter then make sure the date had incremented properly.  Real
nuisance!

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


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

From: George White                                      02-Dec-99 05:32:03
  To: Ian Moote                                         04-Dec-99 06:00:04
Subj: Clocked!

Hi Ian,

On 01-Dec-99, Ian Moote wrote to JONATHAN DE BOYNE POLLARD:

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

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

As most (I believe all) PCs made these days have the RTC integrated
into the chipset with the BIOS also stored in the chipset it becomes
difficult to separate chipset solutions from BIOS solutions :-(.
Although I can see no reason for not making it a hardware solution.

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

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

I can dig out from data sheets RTCs that do support a century byte if
you want. It is doubtful if many will be compatible with the PC RTC.

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

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

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

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

The RTC is only good to 28th February 2100, thereafter it will be
wrong every century year _except_ the years divisible by 400.

 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.

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

Sorry, I can't help there :-(. I don't have stock lists from then
around any more, I needed the space :-).


George

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

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

From: Jonathan de Boyne Pollard                         02-Dec-99 10:26:27
  To: Rob Basler                                        04-Dec-99 06:00:04
Subj: sendto() doesn't work on

 RB> I'm sending out a broadcast and then waiting for a response on the
 RB> same socket.  It is the broadcast call that is failing with the No
 RB> route to host error.  If I specify an address for the call to the
 RB> server rather than using a broadcast, it works as expected.
 RB>
 RB> I find it most odd that it works in Warp 4 but not in WSeB.  You'd
 RB> think that they would have tested broadcast calls in the 4.1 TCP/IP
 RB> stack.

I find it hard to believe that broadcast doesn't work, too.  (-:

You've checked the basics, haven't you ?  You've checked that you've
configured a broadcast address for that interface in TCP/IP configuration, for 
example, yes ?

Try pausing the application after the call to bind() but before the call to
sendto() and using `netstat -s' to look at the socket address.  Try sending an 
ICMP datagram to the same broadcast IP address using `ping'.

  JdeBP 

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

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

From: Jonathan de Boyne Pollard                         02-Dec-99 11:41:26
  To: Ian Moote                                         04-Dec-99 06:00:04
Subj: Clocked!

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

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

 IM> DOS uses internal counters. It only reads the RTC when it boots. 

It still uses the RTC, though.  I didn't realise that you meant "use" with the 
implicit qualification "once, at boot time".  I thought that you meant "use".  
(-:

 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.

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

I don't remember offhand (although I am confident that I have the information
somewhere), but I vaguely recall that it was MS-DOS 3.2 or thereabouts when we 
no longer had to enter the date and the time explicitly when the system was
booted because DOS read them from the RTC hardware.

I'm sure that Murray will know what version of PC-DOS was designed for the
PC/AT.  (-:

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

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

Xinu was perhaps a bad example to choose, since its original implementation,
as described in Comer's book, doesn't use a RTC since the hardware platform
doesn't have one (although it does have a heartbeat interrupt).  It has been
updated since the book was published, though, and ported to other platforms,
most notably Xinu386 for the PC.

I've replied to the non-programming part of your message, where you asked
about clock chips with proper century registers, in the OS2HW echo.

  JdeBP 

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

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

From: Jonathan de Boyne Pollard                         02-Dec-99 11:42:06
  To: Ian Moote                                         04-Dec-99 06:00:04
Subj: OS/2 kernel immunity from the Century Bug

 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.)

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

DosQuerySysInfo() can reasonably only do one of two things.  Either the kernel 
has a 64-bit integer which it initialises from the RTC at boot time and
updates once per second thereafter and whenever an application explicitly sets 
the clock time (which is the way that I'd do it), or it calculates the 64-bit
integer on the fly from the information contained in the 16-bit global
infoseg.

I couldn't tell you which it does without access to the source of the OS/2
kernel, which I don't have.

  JdeBP 

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

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

From: Murray Lesser                                     04-Dec-99 13:02:00
  To: George White                                      04-Dec-99 13:02:00
Subj: Clocked!

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

Hi George--

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

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

GW>The RTC is only good to 28th February 2100, thereafter it will be
  >wrong every century year _except_ the years divisible by 400.

    The cheap RTC chips used in the AT, and in most PCs since, don't
even know what century it is, which is the source of this discussion.
Ian's claim that "the RTC/CMOS itself is good up to the year 9999" is
due only to his belief that there was never a design error ("bug") in
that part of BIOS that read the RTC and handled the century byte in
CMOS.  My experience is that even with the "fixed" BIOS in my newest PC
(that recognizes 1-1-2000) IBM took the easy way out and inserted the
"window" fix instead of going back and redoing the whole RTC firmware.
(I can't speak for other BIOS builders, but there is an easy test to
check for how the bug was fixed in your machine: boot to real DOS, set
the system clock to 1-1-2080, and reboot.  If you get 1980, your BIOS
was "fixed" with the window!)

    However, even assuming a better BIOS fix that won't die at the end
of 2079 (irrespective of what operating system is in use), I think you
have misspoke yourself.  If the firmware for this RTC doesn't know the
400 rule for century leap years (the DOS CLOCK$ driver didn't know it as
of 1991, the last time I disassembled one), it will display March 1,
2100 as February 29th.  From then on, the clock will be a day behind the
real world until the day it displays as February 29, 2200, which will be
March 2, 2200 in real time!  It will then be two days behind the rest of
the real world until the next century rolls around, etc.  Of course, it
won't lose another day during the years divisible by 400, but it will
never be correct after that first error!  Under these assumptions, it
will be wrong on all days, not just during century years, after February
28, 2100 :-(.

     Of course, those future system architects and programmers who
design the future PC (including its firmware) along with the future
software architects and programmers who design and implement the super
operating systems that will run on the super PC, may do everything right
the first time.  But I don't think that I will wait around to see if it
actually happens :-).

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * The saddest words: it might have been.

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


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

From: Will Honea                                        04-Dec-99 00:56:01
  To: Murray Lesser                                     04-Dec-99 00:56:01
Subj: Clocked!

Murray Lesser wrote to Will Honea on 12-02-1999

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

From painful experience I can tell you that Borland wasn't the only
offender.  MSC 4/5/6 all did this as did Watcom 10.0 - 10.6.  I had to
code a workaround to detect the midnight event from the elapsed time
counter then make sure the date had incremented properly.  Real
nuisance!

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


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

From: Roy J. Tellason                                   04-Dec-99 11:56:19
  To: Will Honea                                        05-Dec-99 01:56:05
Subj: Clocked!

Will Honea wrote in a message to Ian Moote:

 WH> To this day there are problems with DOS sessions playing games 
 WH> with time set/read at mifnight under OS/2 (and NT for that 
 WH> matter).

I have noticed that happening here on occasion,  and wondered what the heck
was going on when the bbs missed the midnight maintenance event...

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

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

From: Fred Springfield                                  04-Dec-99 15:08:00
  To: Will Honea                                        05-Dec-99 01:56:05
Subj: Environment Variables

WH> FS> Thanks.  Guess I missed that one, but someone kindly put a copy of
WH> FS> SOM.IR in my root (c:\) when I installed Warp 4, which is probably
WH> FS> why I haven't seen any weird stuff.
WH> FS> 
WH> FS> Looks like I drew a full house this time -:)
WH> 
WH> That kinda depends of WHICH copy of SOM.IR got put there <g>. 
WH> Actually, the SET SOMIR= line defines the search order ahead of
WH> any other path statements. 

Oh yes--after further checking, I see that the one in the root must be
a stub, because it is very small, only 32 bytes in size. The one in
c:\os2\etc is about 480k, which must be the main one, and it is 2 yrs
newer and 100k larger than the one in the f:\ibmcpp\etc directory.

I did some rearranging of the DLL order and started getting SYS3175
hangs, but after putting all the OS/2 stuff up front in the order, as
well as in the SET SOMIR statement, everything straightened out--so now
I am going to leave it that way.

Thanks for the tutorial.

Fred Springfield
Plymouth,MN


  KWQ/2 1.2i  Hope makes a good breakfast, but a poor dinner.

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

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

From: Ian Moote                                         05-Dec-99 10:30:00
  To: MURRAY LESSER                                     05-Dec-99 13:33:05
Subj: Basic Pds Y2k Ok

ML> Come 2080, Ian is going to be very surprised when he attempts to set
ML> his DOS system clock to 1-1-2080.

Not likely. I'm not your typical uninformed, smoke-blowing FidoNetter. 
IOW, I tried this years ago and I tried it again before I posted.


ML>  When he reboots, it will tell him
ML> that the date is 1-1-1980!

Actually it told me that the date was 1-1-2080. Thanks for the 
"warning", however.

(Of course OS/2 won't work, as you might expect, but the BIOS still 
reports 2080 and DOS and Windows will still work.)


ML> It will last 20 more years only if he sets his date prior to
ML> 1-1-2080 and never shuts down.  The minute he reboots his system,
ML> he's back to the "century window" effect when the system tries to
ML> read the RTC.  Unless there is a completely new DOS on completely
ML> new hardware before then.

Just out of curiosity, do any of yous guys actually verify your "facts" 
before you post? I mean, I know that the only prerequisite qualification 
to post on FidoNet is a modem and an opinion (or sometimes just an 
attitude), but this kind of back-handed reply isn't exactly a glowing 
recommendation for Freedom Of Speech.

And isn't going to make you any friends. 'Know what I mean?

Thanks for the info which you provided previously. I do appreciate it. 
Take care and TTYL.

---
  B.S.:  coloquialism; "blowing smoke".                        

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

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

From: Ian Moote                                         05-Dec-99 10:30:00
  To: JONATHAN DE BOYNE POLLARD                         05-Dec-99 13:33:05
Subj: Clocked!

I'm trying to answer your posts all in a single message. In the absense 
of some explanation on your part, I'm moving this reply _back_ into the 
[OS2PROG] conference from where the thread originated. If you wish to 
move the discussion into another conference it is customary on FidoNet 
to include a brief explanation at the head of the message for the 
benefit of the echo participants.


JDBP> Very few hardware manufacturers have produced "PC-compatible" RTCs
JDBP> with proper century registers, which is, of course, the correct
JDBP> way to solve the problem.

Agree 100% with that!


JDBP> Some have, though.
JDBP> 
JDBP> According to its data sheet (which is, alas, short on details),
JDBP> the AMD 645 peripheral bus controller, which is one of those all-
JDBP> in-one "South Bridge" chips, implements a proper century register
JDBP> at location 0x7F in NVRAM.

7Fh?! Well, that certainly doesn't fall into _my_ definition of "PC-
Compatible".


JDBP> If AMD were simply saying that "by convention, the century byte is
JDBP> stored here", one would expect it not to be at location 0x7F, but
JDBP> at one of the locations (such as 0x32) where the century byte *is*
JDBP> conventionally stored.

Well... I've _heard_ of CMOS' which store their century byte (and other 
information) at a location other than 32h (or other than conventional), 
but I've never actually seen one, nor documentation on one. At what 
other "conventional" locations can the century byte be found?


JDBP> IM> Very, very sad. DOS is good until 2099.
JDBP> 
JDBP> If you discount those portions of DOS written in the C language,
JDBP> which will break in 2038;

Uh... well I suppose that's good theory, but how many portions of DOS 
suffer from that limitation? DOS (the versions which I've had here) 
correctly reports dates up to 31 December 2099, and correctly creates 
and reports file dates up to the same date. It would seem to me, 
therefore, that there are precious few "portions of DOs written in the C 
language" which actually suffer from this shortcoming of the C language.


JDBP> and if you discount the fact that most modern BIOSes will
JDBP> implement the same windowing fix as the OS/2 CLOCK01.SYS device
JDBP> driver does, meaning that the year 2079 limitation will be applied
JDBP> before DOS even gets a look-in.

Possibly, although I don't think you've enough of a sample to properly 
justify that "most modern BIOSes will". [:)


JDBP> IM> The RTC/CMOS itself is good up to the year 9999.
JDBP> 
JDBP> I disagree.

Can't say I'm surprised. [:)


JDBP>  Since the RTC doesn't have a century register, the RTC
JDBP> is really only "good" up until the year 99.

I think you're just being argumentative here. You're obviously a very 
highly educated person and I did say "RTC/CMOS". I'm certain you knew 
exactly what I meant. [:)


JDBP> If it doesn't properly increment a century register when the year
JDBP> number wraps from 99 to 00, because it doesn't *have* one, that
JDBP> doesn't qualify as "good" in my book.

You're certain free and welcome to write whatever you please in your 
book, but this simply sounds like the logic of the argumentative.

I reiterate, the design is such that it was understood that the RTC did 
not have a century byte. The century byte was provided in CMOS to be set 
by the "user". Each byte has a range of 00 to 99 BCD. Ergo, the RTC/CMOS 
is good until the the year 9999. Claiming otherwise, simply because the 
RTC by itself doesn't actually have control of the _existing_ century 
byte, simply ignores the existing facts and is simply being contrary for 
the sake of contrariness itself. 


JDBP> It's also worth noting that there isn't a standard place for the
JDBP> byte holding the century.

I disagree. (This _is_ Fight-O-Net, after all! [;) Since I've never seen 
a CMOS which didn't store it's century byte at 32h, I don't believe it's 
worth noting at all. It's a dubious fact which seems to have little to 
do with the discussion other than to introduce FUD. My experience is 
that the century byte is always stored at 32h. This may not be a de jure 
standard, but since it is followed so widely I think that we can call it 
a de facto standard.

IMO, of course. I've been repairing and upgrading clones professionally 
since about 1990.

I understand that there are proprietary pseudo-clones which may store 
their CMOS information in a format different from the de facto 
"standard", but these machines are notorious for not working with off-
the-shelf versions of DOS, and typically come with their own customized 
versions of DOS, Windows, or whatever operating system with which they 
ship.


JDBP> Because of this, the APCI standard, for example, provides a
JDBP> mechanism by which BIOSes can tell operating systems where the
JDBP> century byte is actually located in NVRAM.

I'm not familiar with this standard. Can you elaborate? Who is APCI? I'd 
support a standard such as this.


JDBP> IM> Too bad that IBM felt that they had to break that.
JDBP> 
JDBP> IBM *didn't* break it, though. The RTC design was already broken,
JDBP> inasmuch as it wasn't suitable for use as the RTC chip in a
JDBP> personal computer design that was to last for at least two
JDBP> decades. IBM didn't break the RTC design at all.

In your opinion.

More pedantism. The design worked as intended before the abortion and 
would allow a user to set any date up until the year 9999. Now the user 
is artificially and unnecessarily hobbled to 2079. I think that you and 
I have differing definitions of "break" as used in this context. Or as I 
said at the beginning of this discussion, perhaps you've suddenly 
developed a very flexible definition of "break". [;)


JDBP> It was an off the shelf part that was already designed that way.
JDBP> IBM *could* have picked another chip, from some other
JDBP> manufacturer, which *did* have a century register.

Well, I asked you this before, but please name such a chip which was 
_readily_ available in 1984.


JDBP> Indeed IBM, being IBM, could have manufactured such a chip itself
JDBP> if no such chip were available from a third party.

Non sequitur. That does not fit the historical facts as we know them. I 
wasn't into clones at the time and was a little young to even be 
employed by IBM, but it seems pretty obvious that the design philosophy, 
for whatever reason, was to use off-the-shelf components. It's all well 
and good, sitting up here at the end of 1999 after seeing the PS/2's, 
Blue Lightnings, PS/1's, etc., to cite what IBM _could_ have custom 
manufactured, but really all that matters is what their philosophy was 
for PC design _at the time_. And at the time we know that the philosophy 
was not to redesign anything, but to use off-the-shelf components.


JDBP> IBM didn't break anything. The design was already broken, in that
JDBP> it *wasn't* good up until the year 9999, but only up until the
JDBP> year 99. What IBM did was to choose poorly.

Again, this is all just argumentative. You're doing a lot of fast 
talking to justify your position in this discussion, a position which 
may or may not be your actual point of view or belief.

Take care and TTYL.

---
  Very funny Scotty -- now beam down my clothes!                        

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

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

From: Ian Moote                                         05-Dec-99 10:30:00
  To: WILL HONEA                                        05-Dec-99 13:33:05
Subj: Clocked!

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

Well, that goes without saying. [:)


WH> There are also several int 21 calls that force a read of the RTC and
WH> reset the internal timer to reflect the number of (computed) clock
WH> ticks since midnight.

Several? Other than GetTime and GetDate?


WH>  Some of these are in fact the source of the DOS problem
WH> of not incrementing the day if you hit the clock routines just right
WH> during the midnight roll-over.  To this day there are problems with
WH> DOS sessions playing games with time set/read at mifnight under OS/2
WH> (and NT for that matter).

Ahhhhh. (Are you reading this, Roy!? [:) This is something which has 
been noticed about DOS by some people for quite some time. Few people 
seem to have a reason for it, however. Thanks for the info.

Take care and TTYL.

---
  Very good, Einstein, but next time show your work.                        

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

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

From: Ian Moote                                         05-Dec-99 10:30:00
  To: GEORGE WHITE                                      05-Dec-99 13:33:05
Subj: Clocked!

GW> IM> Because of my job I would be very, very interested in hearing
GW> IM> any factual information concerning an RTC used in a PC which
GW> IM> _does_ update the century byte.
GW>
GW> As most (I believe all) PCs made these days have the RTC integrated
GW> into the chipset with the BIOS also stored in the chipset it becomes
GW> difficult to separate chipset solutions from BIOS solutions :-(.

Uh, well... true, but from an electrical point of view it would still 
work the same way. From the point of view of the machine it makes little 
diffence whether there are individual BIOS ((E)PROM) and RTC components, 
or whether these components are just smaller parts of a VLSI chipset.

From the Systems programmer's point of view, however, there is a big 
difference between the RTC component (integrated or not) updating its 
own century byte and the BIOS (integrated or not) updating the century 
byte. If the BIOS is going to do it then you either have to use that 
short-sighted, crapola, misbegotten windowing technique, or use a 
technique which would determine whether it's appropriate to update the 
century byte or not. (Actually, not too difficult to implement. Probably 
less code than the windowing technique. Would require at least one bit 
from the CMOS, however.)


GW> Although I can see no reason for not making it a hardware solution.

Nor can I. That would be the preferable method, IMO. These days I can't 
even see why it could not be backward compatible with the current 
design.


GW> I can dig out from data sheets RTCs that do support a century byte
GW> if you want. It is doubtful if many will be compatible with the PC
GW> RTC.

Well, that's a consideration -- backward compatibility. One attribute of 
the PC is backward compatibility. I'm in favour of a hardware solution, 
but if given the choice between a hardware solution and backward 
compatibility I think I'd choose backward compatibility. Afterall, you 
only have to make a small adjustment every century. For gosh's sake -- 
it's hardly even worth worrying about.


GW> The RTC is only good to 28th February 2100, thereafter it will be
GW> wrong every century year _except_ the years divisible by 400.

Uh... Ah! Yes, you're right! I hadn't thought about that. So I guess 
it's wrong _twice_ every hundred years -- one adjustment within ten 
months of the other. [:)


GW> IM> Yes, I agree. And I've heard that criticism of the AT's RTC
GW> IM> before. Could you give me the part number for an RTC which was
GW> IM> readily available in 1983 that tracked real years -- "1983"
GW> IM> instead of just "83"?
GW>
GW> Sorry, I can't help there :-(. I don't have stock lists from then
GW> around any more, I needed the space :-).

Well... a little rhetorical that question was. [:) IIRC the first 
digital IC was put into production around 1974, for the U.S. space 
program I think. We don't re-invent digital circuits any more than we 
re-invent code to perform binary multiplication. When someone coughed up 
a decent digital RTC, that circuit was licenced and re-used in a myriad 
applications. Remember that things were changing very quickly in those 
days. IC's meant ease of implementation, and the closer your product 
could emulate another the more it would be used. The RTC in question 
tracked a single-byte year, but nobody believed that we'd still be using 
it in 1999.

The PC has an excuse -- backward compatibility. VCR's, nuclear reactors, 
and Hubble reactors don't have that excuse. [:)

Anyway, take care and TTYL.

---
  VGA:  Very Good Adapter.                        

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

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

From: Will Honea                                        05-Dec-99 13:31:00
  To: Ian Moote                                         05-Dec-99 13:31:00
Subj: Clocked!

Ian Moote wrote to WILL HONEA on 12-05-1999

IM> Ahhhhh. (Are you reading this, Roy!? [:) This is something which
IM> has  been noticed about DOS by some people for quite some time. Few
IM> people  seem to have a reason for it, however. Thanks for the info. 

You should save Murray Lesser's excellent reply on that topic.  I
would have saved several handfuls of hair had I seen his 1990 article
at that time!

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


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

From: Will Honea                                        05-Dec-99 15:05:01
  To: Ian Moote                                         05-Dec-99 15:05:01
Subj: Clocked!

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

IM> I reiterate, the design is such that it was understood that the
IM> RTC did  not have a century byte. The century byte was provided in
IM> CMOS to be set  by the "user". Each byte has a range of 00 to 99
IM> BCD. Ergo, the RTC/CMOS  is good until the the year 9999. Claiming
IM> otherwise, simply because the  RTC by itself doesn't actually have
IM> control of the _existing_ century  byte, simply ignores the existing
IM> facts and is simply being contrary for  the sake of contrariness
IM> itself. 

Ian, the PC RTC was made a defacto standard in the IBM AT, circa 1984.
 IBM chose the Motorola MC146818 chip which I have used in hardware
designs since the early 80's.  The original 6818 was touted to be the
'univeral' clock as it accomodated both the Motorola 68xx and the Intel
bus timing and specs (almost).  The original chip had several problems,
one of the minor ones being incorrect Y2K leap year detection - and a
bunch of those are still in the pipeline lo these many years later. 
The 146818 was replace in the late 80's by the 146818A which had
significant performance and power enhancements.  Dallas Semi and
Hitachi licensed the part and Dallas extended some of the functions as
well as adding an integral battery.  The original 6818 had some
problems with the year update, but my spec sheet for the part shows
that the the part "Counts Seconds, Minutes, and Hours of the Day",
"Counts Days of the Week, Date, Month and Year".  If it doesn't, then I
have several thousand units in the field which are gonna generate a
FLOOD of irrate phone calls come 1/1/2000.  Tests have shown that the
part DOES keep the year at offset 10. The whole date/time array is
stored at offsets 0-10 in the part.  A fair number of the 6818 parts
from Hitachi have a problem with Feb 29, 2000 so we have included a
software 'kludge' to take care of that but the part itself keeps on
ticking.  Interestingly enough, even the flawed parts keep the
day-of-week right: they just won't roll over the 28 -> 29th.

So much for the original part: it DOES keep the year and count it but
as a 2 digit value.  Even if you use binary values in the date/time
registers (an option) the circuit still rolls from 99 - 00.  Otherwise,
even legacy software would have no problem: add 1900 to the value and
you are good to 2155.  As for the built-in clock functions in the
integrated controllers, they are supposed to be faithful emulations of
the 6818.  They may extend the functions, but they are licensed to
perform exactly as the 6818 design.  Enhancements include added RAM
(that's where your BIOS settings are stored) and some additional alarm
functions.  BTW, the alarm functionality is fully available - but I
don't know of anyone else who uses it.  I use it for a 'tell em you're
alive' event in my instrumentation designs so that the monitor up on
the snow shed reports in once every week or so even in the summer.

The use of offset 32h for century storage is a convention that
evolved.  Add-in boards for the XT used whatever they felt like but
IBM's dominance in the PC market (at the time) pretty well defined
their choice as the standard.  Did they make an error?  Depends on your
definition of error.  The design lifetime of the AT was on the order of
5 years.  Low battery conditions were common early on and a battery
failure rendered the PC brainless - it lost the CMOS setup - so the
reset value of year 00 was chosen to indicate battery loss and
potential corruption.  Later BIOS's used the battery indicator flag in
the clock to make a more intelligent decision but why worry when the
product was destined for the scrap heap in 6-7 years anyway?

IM> IMO, of course. I've been repairing and upgrading clones
IM> professionally  since about 1990. 

I've got a good 10 year lead on you.  I was designing those same
'clones' when the first PC came out and I still design and produce
equipment using the same structures - altho it's more of a 'grab 3
parts, add memory' exercise today.

I'm not aware of any major PC maker today writing custom BIOS's.  They
will all take a licensed verion of AWARD or AMI - the survivors - and
add whatever unique hardware interfaces are needed but the essential
BIOS is pretty much vanilla.  I normally use AWARD and the only mods I
make are to accomodate A/D and D/A functions where it's more efficient
than to do the entire function from the app.  I also initialize the
built-in modems if included on the board but I can even buy the video
routines as part of the package.

The clock routines are not broken.  They are Working As Designed
(WAD).  You may bitch about the design specs but (as you might guess
from the times above) I could care less about what happens after 2079. 
If my customers are so damned cheap that they haven't upgraded by then,
tough.  The NEMA enclosures will probably have rotted anyway.  More
importantly, if I or my successors have not made sufficient
improvements in the products so as to warrant replacement by then (to
include necessary functionality) I can assure you that this business
will be dead even before I am.

Finally, I have some questions for you:  How many pre-1990 PC's are in
active use today? (yes, Linda, I know!)  How many of todays 'killers'
will be functional in 2038, much less 2079?  The spec'd lifetime for
data on EPROMS is 10 years, BTW, and the myriad electrolytic capacitors
in your PC have a similar MTBF.
 
Will Honea <whonea@codenet.net>
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


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

From: Will Honea                                        05-Dec-99 15:11:02
  To: Ian Moote                                         05-Dec-99 15:11:02
Subj: Clocked!

Ian Moote wrote to GEORGE WHITE on 12-05-1999

IM> Well... a little rhetorical that question was. [:) IIRC the first 
IM> digital IC was put into production around 1974, for the U.S. space
IM>  program I think. We don't re-invent digital circuits any more than
IM> we  re-invent code to perform binary multiplication. When someone
IM> coughed up  a decent digital RTC, that circuit was licenced and
IM> re-used in a myriad  applications. Remember that things were
IM> changing very quickly in those  days. IC's meant ease of
IM> implementation, and the closer your product  could emulate another
IM> the more it would be used. The RTC in question  tracked a
IM> single-byte year, but nobody believed that we'd still be using  it
IM> in 1999. 

I used a prototype LORAN set in 1963 where Collins Radio used early TI
techniques to reduce the beast to the size of a pack of cigarettes -
but could find room for all the knobs.  The 7400 series IC's were
commercially available by at least 1969 - I paid an arm and a leg for
some of them to use in a research project.  You history is a bit skewed
- and the industry is slower in some areas than even you believed.

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


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

From: Ian Moote                                         05-Dec-99 13:40:00
  To: MURRAY LESSER                                     06-Dec-99 00:14:21
Subj: Clocked!

ML> The cheap RTC chips used in the AT, and in most PCs since, don't
ML> even know what century it is, which is the source of this
ML> discussion.

Actually, the source of this discussion was my very simple question as 
to whether there was any version of OS/2 which would choke on 01 January 
2000. After having some smoke blown up my ... er, in my face concerning 
my old equipment, RTC hardware, and alleged "bugs" in my BIOS, Jonathan 
de Boyne Pollard answered my question.


ML> Ian's claim that "the RTC/CMOS itself is good up to the
ML> year 9999" is due only to his belief that there was never a design
ML> error ("bug") in that part of BIOS that read the RTC and handled the
ML> century byte in CMOS.

Not true. Why would you prefer people to believe that?


ML> My experience is that even with the "fixed"
ML> BIOS in my newest PC (that recognizes 1-1-2000) IBM took the easy
ML> way out and inserted the "window" fix instead of going back and
ML> redoing the whole RTC firmware. (I can't speak for other BIOS
ML> builders, but there is an easy test to check for how the bug was
ML> fixed in your machine: boot to real DOS, set the system clock to
ML> 1-1-2080, and reboot.  If you get 1980, your BIOS was "fixed" with
ML> the window!)

My BIOS _correctly_ reports that the date is 2080. I believe you were 
telling me that this correct reporting of the date was because my older 
BIOS' is buggy. The newer BIOS', such as yours, which have fixed this 
"bug" report the wrong date on 2080.

Do I have that straight now? Very convincing.


ML> However, even assuming a better BIOS fix that won't die at the end
ML> of 2079

A "better" fix? Is there something wrong with the current "fix"? _My_ 
old "buggy" BIOS is going to correctly report the date in 2080 and 
beyond. Just out of curiosity, where's the bug? What makes you think 
that a BIOS which _correctly_ reports the date in 2080+ needs to be 
"fixed" so that it _won't_ correctly report the date in 2080+?


ML> If the firmware for this RTC doesn't
ML> know the 400 rule for century leap years (the DOS CLOCK$ driver
ML> didn't know it as of 1991, the last time I disassembled one), it
ML> will display March 1, 2100 as February 29th.  From then on, the
ML> clock will be a day behind the real world until the day it displays
ML> as February 29, 2200, which will be March 2, 2200 in real time!  It
ML> will then be two days behind the rest of the real world until the
ML> next century rolls around, etc.  Of course, it won't lose another
ML> day during the years divisible by 400, but it will never be correct
ML> after that first error!  Under these assumptions, it will be wrong
ML> on all days, not just during century years, after February 28, 2100
ML> :-(.

I envy you your computer. I've never seen a computer as maintenance-free 
as yours. I can only imagine the technology which has gone into your 
CMOS battery... [:*)

Sarcasm aside, you can spend a lot of time redesigning the RTC to 
account for the 400 year rule (why bother?) and taking into account the 
1000 year rule (why bother?) and to automatically adjust for all those 
additional multi-millenial rules that you've not mentioned yet (why 
bother?) as well as the occasional leap second adjustments (why bother), 
but why bother? Why bother overdesigning an RTC which is usually only 
accurate to within several seconds a day (+6min/yr @ 1s/d) and for which 
the battery needs to be replaced every five or six years?

It's a tempest in a teapot!! Why bother worrying about a once-in-a-
century adjustment on a device which needs _constant_ adjustment 
anyway!?! This topic, and the oversensitivities which accompany it, 
approach the ridiculous!

It's my _considered_ opinion that discussion of alleged Y2K-related 
hardware "problems" and "bugs" is little more than an excuse for self-
important, non-professional (as well as unprofessional) propeller-heads 
to stir up the chamber-pot.

Not meaning you, of course. You are well known in these parts for being 
very helpful and knowledgable on many facets of hardware and software 
(particularly of OS/2) and of freely and openly sharing your knowledge 
equally with everyone.


ML> Of course, those future system architects and programmers who design
ML> the future PC (including its firmware) along with the future
ML> software architects and programmers who design and implement the
ML> super operating systems that will run on the super PC, may do
ML> everything right the first time.  But I don't think that I will wait
ML> around to see if it actually happens :-).

Perhaps atomic clocks with a well-shielded thermo-electric power 
source...? [;)

Nothing's perfect. My worries tend more toward issues of _real_ import 
to the industry and my hobby, such as those regarding the limitations of 
ATA. And of USB -- the clone PC implementation of the C=64 peripheral 
interface.

Take care and TTYL.

---
  Wanna see me make bubbles with my spit?                        

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

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

From: Ron Nicholls                                      05-Dec-99 17:42:00
  To: Fred Springfield                                  05-Dec-99 17:42:00
Subj: Environment Variables

FS> WH> With Warp 4, it backlevels SOM support which is central to the WPS
FS> WH> stuff.
FS>  
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> 
Well I don't have it in mine- what's it do?

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


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

From: David Van Hoose                                   05-Dec-99 12:32:00
  To: All                                               06-Dec-99 09:49:04
Subj: HPFS

Who all was doing research on the HPFS editing?

-Dave

--- PCBoard (R) v15.4 (OS/2) 250 Beta
 * Origin: Destiny BBS: 1-850-477-1262 (1:3612/333)
382/92

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

From: Roy J. Tellason                                   05-Dec-99 16:47:17
  To: Ian Moote                                         06-Dec-99 09:49:05
Subj: Clocked!

Ian Moote wrote in a message to WILL HONEA:

WH>  Some of these are in fact the source of the DOS problem
WH> of not incrementing the day if you hit the clock routines just right
WH> during the midnight roll-over.  To this day there are problems with
WH> DOS sessions playing games with time set/read at mifnight under OS/2
WH> (and NT for that matter).

 IM> Ahhhhh. (Are you reading this, Roy!? [:) 

Silly question!  :-)  You should in fact have seen my reply to that post by
the time this gets there...

 IM> This is something which has been noticed about DOS by some 
 IM> people for quite some time. 

Referring back to a thread in TECH some time ago,  I guess.

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

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

From: George White                                      04-Dec-99 10:48:03
  To: Ian Moote                                         06-Dec-99 09:49:05
Subj: Basic Pds Y2k Ok

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 
 * Origin: A country point under OS/2 (2:257/609.6)
382/92

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

From: MIKE RUSKAI                                       05-Dec-99 19:26:00
  To: DAVID VAN HOOSE                                   06-Dec-99 09:49:05
Subj: HPFS

Some senseless babbling from David Van Hoose to All
on 12-05-99  12:32 about HPFS...

 DVH> Who all was doing research on the HPFS editing?

I've been doing some poking around in that area.  I'm currently seeing if
I can't write an undelete that works faster than the one in GTU 3.0.

Mike Ruskai
thannymeister@yahoo.com


... Arguing logic with a programmer can get you hexed.

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

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

From: MIKE RUSKAI                                       05-Dec-99 19:28:00
  To: EDDY THILLEMAN                                    06-Dec-99 09:49:05
Subj: PROMPT $I in PMCMD

Some senseless babbling from Eddy Thilleman to Jonathan De Boyne Pollard
on 12-02-99  08:36 about PROMPT $I in PMCMD...

 ET> Hello Jonathan,

 ET> 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.

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

Among nerds, "upgrading" usually entails gutting one machine and stuffing
the entrails in the shell of a more powerful one.

For example, except for the first one, I've never purchased a complete PC.
I've bought only parts since.

Mike Ruskai
thannymeister@yahoo.com


... Captain, I sense a million minds staring at my cleavage.

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

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

From: Rob Basler                                        05-Dec-99 22:15:00
  To: Jonathan De Boyne Pollar                          06-Dec-99 09:49:05
Subj: sendto() doesn't work on

JDBP> RB> I'm sending out a broadcast and then waiting for a response on the
JDBP> RB> same socket.
JDBP> RB>
JDBP> RB> I find it most odd that it works in Warp 4 but not in WSeB.

JDBP>I find it hard to believe that broadcast doesn't work, too.  (-:

JDBP>You've checked the basics, haven't you ?  You've checked
JDBP>that you've configured a broadcast address for that
JDBP>interface in TCP/IP configuration, for example, yes ?

Unfortunately the TCP/IP configuration notebook doesn't work.  Hasn't
worked for ages.  Any configuration has to be done manually with the
configuration files.  When I start the notebook it gives me a java null
pointer error and quits.  I have asked in usenet but nobody has a
solution (although a number of others have the same problem.)

JDBP>Try pausing the application after the call to bind() but
JDBP>before the call to sendto() and using `netstat -s' to look
JDBP>at the socket address.

Under WSEB I get

                              AF_INET Address Family:
  SOCK   TYPE       FOREIGN          LOCAL         FOREIGN         STATE
                     PORT             PORT            HOST
======  =====      ==========      ==========      ==========
========
    11 STREAM               0            6804         0.0.0.0  LISTEN
    12 STREAM            6804           49158       127.0.0.1  ESTABLISH
    13  DGRAM               0            6805         0.0.0.0  UDP
    14 STREAM           49158            6804       127.0.0.1  ESTABLISH
  2074  DGRAM               0               0         0.0.0.0  UDP

Under Warp 4 I get:

SOCK     TYPE        FOREIGN          LOCAL        FOREIGN     STATE
                        PORT           PORT           HOST
====  =========  =============   =============   =============
=============
634 STREAM         1280            6804       127.0.0.1 ESTABLISHED
633 DGRAM             0            6805         0.0.0.0 UDP
632 STREAM         6804            1280       127.0.0.1 ESTABLISHED
631 STREAM            0            6804         0.0.0.0 LISTEN

I don't know what this means, but under WSeB I get an extra UDP port.
FYI 6805 is the port number of the UDP port that is supposed to accept
broadcasts.  6804 is my console application which displays messages
from the running applications.  This is with the two server applications
running, but no client connected to them.

Rob.
___
 X SLMR 2.1a X Ratings: G:Guns/PG-Plenty of guns/PG-13:more than 12 guns

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

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

From: David Van Hoose                                   06-Dec-99 06:41:00
  To: Mike Ruskai                                       06-Dec-99 09:49:05
Subj: HPFS

-> I've been doing some poking around in that area.  I'm currently
-> seeing if I can't write an undelete that works faster than the one in
-> GTU 3.0.

Cool. Is it possible that you could share your research on
the subject? I am wanting to create a boot loader that does
everything using sector IO.

-Dave

--- PCBoard (R) v15.4 (OS/2) 250 Beta
 * Origin: Destiny BBS: 1-850-477-1262 (1:3612/333)
382/92

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

From: Ian Moote                                         06-Dec-99 13:16:00
  To: GEORGE WHITE                                      06-Dec-99 15:54:18
Subj: Basic Pds Y2k Ok

GW> GW>> According to tests run by some of the other echo users the 2079
GW> GW>> thing is *NOT* a problem with OS/2 itself (by that I mean the
GW> GW>> base OS resident in memory) but with the support utilities
GW> GW>> provided with it.
GW>
GW> IM> Well, that distinction may mean something to somebody but like I
GW> IM> said, I set my RTC to 2080 and OS/2 came up thinking that it was
GW> IM> 1980.
[...]
GW> It _is_ important. If you interrogate the date/time APIs directly
GW> you will have the correct date and time returned, it's only the
GW> supplied utilities that have the problem.

Oh! Well I think I misunderstood you! When I played with the date I only 
noticed that the WarpCenter date was 1980; I didn't check the date from 
the command line. You consider WarpCenter to be a utility? I'll check 
the command line date when I get home.

So what you're telling me here is that an API call (QuerySysInfo or 
similar) will return the correct system date, correct?


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

As long as that's all the problem we see, I won't mind that. I just 
don't want to be wasting my time writing software that I'm not going to 
be able to use 81 years from now!


GW> IM> Well, yeah, but sounds suspiciously like saying, "we're not
GW> IM> quite as bad as everyone else". [:) One of the reasons I don't
GW> IM> use C.
GW>
GW> No, you've drawn the wrong conclusion from that :-(. Both are
GW> problems, but the *NIX one is *much* more pervasive, it goes from
GW> the core *NIX kernal, through the OS utilities and on into nearly
GW> _all_ programs for it as they are normally written in C. And it's
GW> much closer in time...

Ah, okay. Yeah, I see where you're coming from on that one now. 


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

Yes; thank you for taking the time. I misunderstood you on several 
points. I appreciate it.

Take care, George, and TTYL.

---
  Wanted:  A good vegetarian stuffing recipe for turkey.                     
   

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

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

From: Ian Moote                                         06-Dec-99 13:16:00
  To: ROY J. TELLASON                                   06-Dec-99 15:54:18
Subj: Clocked!

RT> WH>  Some of these are in fact the source of the DOS problem of
RT> WH> not incrementing the day if you hit the clock routines just
RT> WH> right during the midnight roll-over.

[...]

RT> IM> This is something which has been noticed about DOS by some
RT> IM> people for quite some time.
RT>
RT> Referring back to a thread in TECH some time ago,  I guess.

It's something that I and others have noticed on occasion as well. I do 
remember that thread, however, and tried to keep a very close eye on a 
DOS machine which was running fairly constantly here at the time. Didn't 
see anything, though. The insights posted here would explain why -- very 
little C software was running on that machine. [:)

Take care and TTYL.

---
  Wanted:  Dragon slayer.  No experience expected.                        

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

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

From: Murray Lesser                                     06-Dec-99 16:52:01
  To: Will Honea                                        06-Dec-99 16:52:01
Subj: Clocked!

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

Hi Will--

WH>Enhancements include added RAM (that's where your BIOS settings are
  >stored) and some additional alarm functions.  BTW, the alarm
  >functionality is fully available - but I don't know of anyone else
  >who uses it.  I use it for a 'tell em you're alive' event in my
  >instrumentation designs so that the monitor up on the snow shed
  >reports in once every week or so even in the summer.

    The BIOS in the first IBM laptop (the IBM Convertible) enabled the
RTC alarm function.  The "new" BIOS interrupt functions were used for
setting the alarm and putting the machine into "suspend" mode, to be
awakened at the alarm time.  I wrote my first "traveling alarm clock"
program (in C plus some inline assembled calls to the "new" BIOS
interrupts) for the Convertible, in 1988.

    Starting with the IBM L40-SX, a program named PS2.EXE has been
available for all IBM laptops I have owned; the functions in this
program can be called by the "system" command available in most
programming languages, or directly from REXX.  For example, from my
current version of WAKEUP.CMD (for my ThinkPad 365XD, running under Warp
4 FixPak 5):

    "@ps2 on" alarm "> null"    /* Set "wake-up" Time */
    "@PS2 sus > null"           /* Put into "suspend" mode */

    The OS/2 version of PS2.EXE for the ThinkPad 365XD came from the IBM
OS/2 Device Driver Pak.  (A Win95 version for the same machine, along
with that operating system, came preinstalled on the machine's hard
drive; I wiped the drive clean and installed Warp 4.)

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * Fidonet is almost like having a social life

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


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

From: Murray Lesser                                     06-Dec-99 17:06:02
  To: Ian Moote                                         06-Dec-99 17:06:02
Subj: Facts?

(Excerpts from a message dated 12-05-99, Ian Moote to Murray Lesser,
   original topic: Basic Pds Y2k Ok):

Hi Ian--

IM>Just out of curiosity, do any of yous guys actually verify your
  >"facts" before you post? I mean, I know that the only prerequisite
  >qualification to post on FidoNet is a modem and an opinion (or
  >sometimes just an attitude), but this kind of back-handed reply
  >isn't exactly a glowing recommendation for Freedom Of Speech.

    Just to satisfy your curiosity: I always attempt to "verify" my
"facts" before I post.  What I sometimes forget is that some operational
"facts" (as verified by experiment) are hardware (or operating system
version) dependent, and what works (or doesn't work) on the machines I
have (or had) may not perform in the same manner on your machines.  (I
think it might be well if you also tried to remember this "fact.")

    Verifying historical "facts" is a little more difficult.  I have
quite a library of computer-related texts, and try to cite such
references for those of you who wish to look further into the matter.
However, I share George's problem of lack of space.  It is a truism that
the reference text I haven't looked at for ten years and so threw out
last month, is needed today :-).

    But verifying the past from recollection is very difficult,
especially for me since I started programming automatic digital
computing engines in 1948, and my recollections have tended to get
fuzzier as the years whiz by.  (Those engines weren't even called
"computers" in 1948; they were called "calculators."  I do have several
references verifying that "fact" [computer history is one of my
hobbies]).  I try to indicate such personal recollections with "IIRC."

    But, unfortunately, many of us old-timers suffer from an overgrown
sense of the facetious.  It appears that you, and many other youngsters,
are unable to tell the difference between fact and obvious (to us)
fancy, unless the fancy is well labeled with ":-)" (or equivalent)
markers.  Sorry about that, but I don't know if anything can be done
about it in the near future.  Eventually, we has-beens will all die off,
thereby leaving the world to those of you who have only a digital sense
of humor :-).

    I agree with you that several of the frequenters of this echo are
not overly conscientious about verifying their "facts" before posting,
which is too bad.  But it is not hard to recognize those amongst us who
aren't very fussy about what they post, and to ignore them.  IMO, it
serves no useful purpose to make sophomoric remarks about their efforts.

IM>And isn't going to make you any friends. 'Know what I mean?

    See tagline :-).

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * With friends like this, who needs enemies

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


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

From: Fred Springfield                                  07-Dec-99 17:08:02
  To: Ron Nicholls                                      10-Dec-99 06:58:06
Subj: Environment Variables

RN> FS> WH> With Warp 4, it backlevels SOM support which is central to the WPS
RN> FS> WH> stuff.
RN> FS>  
RN> FS> Thanks.  Guess I missed that one, but someone kindly put a copy of
RN> FS> SOM.IR in my root (c:\) when I installed Warp 4, which is probably
RN> FS> why I haven't seen any weird stuff.
RN> FS> 
RN> Well I don't have it in mine- what's it do?

I don't know, but whatever it is it can't be very important because
it's only 32 bytes in size.  It's probably a placemarker or something
because the SOM.IR which does the real work is 480k bytes and is in one
of the OS2 directories.

Fred Springfield
Plymouth, MN


  KWQ/2 1.2i  Hope makes a good breakfast, but a poor dinner.

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

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

From: Ian Moote                                         08-Dec-99 12:29:00
  To: MURRAY LESSER                                     10-Dec-99 06:58:06
Subj: Facts?

ML> Hi Ian--

Hey, dude! [:)


ML> IM>Just out of curiosity, do any of yous guys actually verify your
ML> >"facts" before you post? I mean, I know that the only prerequisite
ML> >qualification to post on FidoNet is a modem and an opinion (or
ML> >sometimes just an attitude), but this kind of back-handed reply
ML> >isn't exactly a glowing recommendation for Freedom Of Speech.
ML>
ML> Just to satisfy your curiosity: I always attempt to "verify" my
ML> "facts" before I post.  What I sometimes forget is that some
ML> operational "facts" (as verified by experiment) are hardware (or
ML> operating system version) dependent, and what works (or doesn't
ML> work) on the machines I have (or had) may not perform in the same
ML> manner on your machines.

I can understand that. I see a great many machines, on a weekly basis, 
of varying vintages and capabilities. What I sometimes forget is that 
some people tend to judge the situation of others based upon their own 
very limited experiences.


ML> (I think it might be well if you also tried to remember this
ML> "fact.")

Oh you do? I see.

Take a look at my quote above. "...this kind of backhanded reply...". 
You realize that I was refering to your message to George (was it?) that 
(paraphrased) "Ian is going to get a big surprise when his DOS doesn't 
work in 2080..."

Now just hold on for a moment here. It was you and I who were engaged in 
discussion so why did you not post that to me? I've been on FidoNet for 
many years and I know exactly what this is all about. You don't like 
what I have to say so you go running to a buddy, make a comment about 
how inaccurate I am, hoping that your buddy will come back with a reply 
which appears to "support" your position, and that will politically 
strengthen your position in this thread and in this conference. 
Essentially, "winning" a "discussion" by weight of numbers rather than 
based on the truth -- the facts.

Ersatz, a "backhanded reply". 

I'm not here to carve out a niche for myself or to disturb the pecking 
order. If you had an issue with what I said _to you!_ regarding DOS and 
2080 then you sould have replied to me directly, not indirectly.

I don't mind you presenting an agressive discussion if you want (and if 
civil), but if you don't want to reply to me directly, please don't 
reply at all. I don't appreciate backhanded remarks such as that and I 
doubt that many others would either.

I think it might do well if you also tried to remember this "fact".


ML> Verifying historical "facts" is a little more difficult.

Sorry; you lost me here.


ML> However, I share George's problem of lack of space.  It is a
ML> truism that the reference text I haven't looked at for ten years and
ML> so threw out last month, is needed today :-).

[:))) Isn't that always the case! [;) I've got a major space problem 
here as well.


ML> But verifying the past from recollection is very difficult,
ML> especially for me since I started programming automatic digital
ML> computing engines in 1948,

Uh... we're not going to start into this "I was flying starships when 
your grandfather was in diapers" stuff, are we? I had enough of that 
last year.


ML> (Those engines weren't even called
ML> "computers" in 1948; they were called "calculators."  I do have
ML> several references verifying that "fact"

1) Yes, I remember.

2) No, I don't want you to "verify" this. I don't need your attitude.


ML> But, unfortunately, many of us old-timers suffer from an overgrown
ML> sense of the facetious.

Yes, I know. I got a belly full of it last year in the [Tech] 
conference.


ML>  It appears that you, and many other youngsters,

::cough:: Excuse me, son?

So tell me, kid -- how old am I? [:) If you want to start making 
jouvenile references to age, I feel I should warn you that I know a 
great many. [;)


ML> Eventually, we has-beens will all die off, thereby leaving the world
ML> to those of you who have only a digital sense of humor :-).

Smiley or no, I'm becoming kind of offended by this turn of the 
discussion. I fail to see what relevance either of our ages have here. 
Unless, of course, you're attempting to postulate an excuse for your 
poor attitude, in which case it may be relevant.


ML> I agree with you that several of the frequenters of this echo are
ML> not overly conscientious about verifying their "facts" before
ML> posting, which is too bad.

It's not just this conference, or FidoNet in general. There are a great 
many people in our society who are very unsatisfied and unfulfilled. 
They crave respect as much as you and I. They speak up even when they 
don't really know the answer because they fear that their silence will 
make them appear unknowledgable. When you sit down and think about it, 
it's very sad, really.


ML> But it is not hard to recognize those amongst us who aren't very
ML> fussy about what they post, and to ignore them. IMO, it serves no
ML> useful purpose to make sophomoric remarks about their efforts.

I disagree here. You wouldn't put up with an incompetant teacher 
teaching your children, but you put up with an incompetant poster 
posting incorrect "facts" to the conference? You want these people 
spewing B.S. around Fido? The result will be trashed hard-drives, the 
purchase of equipment that won't work on your computer, perhaps even an 
incorrect home electrical installation. No, I don't agree. The sooner we 
let these people know that they're full of crap and put them in their 
place the sooner they'll either get a girlfriend or run off to the 
Internet where they're easier to spot!

Actually, I suppose that I should say, "in principle I don't agree." My 
aforementioned experience in [Tech] last year has shown me that you 
can't beat the FidoNet Old Boys Club. I give up. FidoNetters can B.S. 
each other all day and night -- just don't ask me to accept what's said 
as rote.

(After re-reading the above, you may misunderstand me as saying that it 
was you who was the incompetant poster. That wasn't my intention but I 
don't really have the time to attempt to re-word.)


ML> IM>And isn't going to make you any friends. 'Know what I mean?
ML>
ML> See tagline :-).
[...]
ML> --Murray <Team PL/I> ___ * MR/2 2.25 #120 * With friends like this,
ML> who needs enemies

[:) Well, that's your perogative, Murray. Perhaps you think, at your 
age, that you have "earned" a right to be ornery, or that making new 
friends is a waste of time. My mother died at 54. My opinion is that you 
never know when it's gonna hit and that you should make the most of what 
you've got right now. You've got time on this planet to make more 
friends, but your time is too precious to put up with the B.S.'ers and 
those who only want to steal your time from you. [;)

Looking forward to a long and mutually productive relationship, Murray. 
[:) Take care and TTYL.

---
  Warning!  The tech support people are even dumber than you!                
        

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

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

From: Francois Thunus                                   08-Dec-99 23:46:00
  To: Ian Moote                                         10-Dec-99 06:58:06
Subj: Facts?

Hello Ian!

08 Dec 99 12:29, Ian Moote wrote to MURRAY LESSER:

 IM> You want these people spewing B.S. around Fido? The result will be
 IM> trashed hard-drives, the purchase of equipment that won't work on
 IM> your computer, perhaps even an incorrect home electrical
 IM> installation.

Just for the record: don't forget solar spots.

                             -= Francois =-
                      Francois(at)telematique(dot)org
                       http://www.telematique.org/ft

Vulcans worship peace above all.

--- GoldED 3.0.1
 * Origin:  Xara Sto Pragma ! Gasperich - Luxembourg -> (FidoNet 2:270/25.2)
251/25

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

From: Eddy Thilleman                                    08-Dec-99 11:49:13
  To: Mike Ruskai                                       10-Dec-99 06:58:06
Subj: PROMPT $I in PMCMD

Hello Mike,

05 Dec 99 19:28, MIKE RUSKAI wrote to EDDY THILLEMAN:

MR> For example, except for the first one, I've never purchased a complete
MR> PC. I've bought only parts since.

My current system is my first I bought completely in parts and put it
together. My previous systems where more or less pre-built, with the first
completely pre-built and with every new system I put more and more together
myself.

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

... The crows seemed to be calling his name, thought Caw.
--- GoldED/2 3.0.1
 * Origin: Windows98 is a graphic DOS extender (2:280/5143.7)

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

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