[Coco] cprep19 __FILE__ fix?

[Michael Furman]

On May 25, 2011, at 12:53 PM, Willard Goosey wrote:

> On Tue, May 24, 2011 at 10:12:09PM -0700, Stephen H. Fischer wrote:
>> The __DATE__ should (must) be changed to return a date in the 2xxx range as 
>> it is "Today's" date.
> 
> OK, easy enough.  But someone who's good at binary patching and/or
> disassembling things should fix Krieder's ctime() properly.  And that,
> btw, would not be me.  I'm not very good with 6x09 assembler.


Willard, I looked into this a few months ago.  Off the top of my haead:

1) I have some source for the Krieder C library, but when I assembled it, it was not exactly the same as binary copies floating around.  This reduces my confidence that the resulting clib after hacking will actually work properly, and makes it difficult to generate a patch that will always work.  The date command returns the correct year.

2) clib's asctime function had some contribution to the problem but the details escape me ATM.

3) I took a look at Nitros9's date command and it has some Y2Kish stuff there but it's not clear if it works correctly.  The algorithm there seemed a bit convoluted or worked the problem backwards (from my perspective) for some unknown reason (to optimize it? for 8-bit math apparently?).  The comment in date.asm is from Grandpa Gene:
*   5      1996/09/25  Gene Heskett
* Made Y2K compliant.

4) It appears that Nitros9 keeps a 1-byte year, so this is what one would expect F$Time to return.  According to OS9Defs: 
D.Time         equ       .                   System Time
D.Year         rmb       1

I'll try to fill in the rest of details from my previous investigation of this issue later this evening.

The result was that to fix UUCPBB (Which reported the year as 19111 in some places and 111 in others) I basically changed any occurrence of '19%d', year to '%d', 1900+year.  This was a hack that doesn't address the real lower level problem.