[Coco] Fwd: failure notice

Tue May 12 01:51:28 EDT 2015

Here is the reason you never got my msg to your private question, Bill

----------  Forwarded Message  ----------

Subject: failure notice
Date: Monday 11 May 2015, 23:28:35
From: MAILER-DAEMON at mail.wdtv.com
To: gheskett at wdtv.com

Hi. This is the qmail-send program at mail.wdtv.com.
I'm afraid I wasn't able to deliver your message to the following 
addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<ooogalapasooo at aol.com>:
Connected to 152.163.0.67 but greeting failed.
Remote host said: 421 4.7.1 : (DYN:T1) 
http://postmaster.info.aol.com/errors/421dynt1.html
I'm not going to try again; this message has been in the queue too long.

--- Below this line is a copy of the message.

mail.wdtv.com (envelope-from <gheskett at wdtv.com>, uid 508) with 
qmail-scanner-2.01 
 (clamdscan: 0.88.7/2478. spamassassin: 3.1.7.  
 Clear:RC:0(204.111.64.149):SA:0(0.5/5.0):. 
 Processed in 3.579459 secs); 05 May 2015 02:28:34 -0000
X-Spam-Status: No, score=0.5 required=5.0
X-Spam-Level: 
Received: from unknown (HELO coyote.coyote.den) 
(gheskett at wdtv.com@204.111.64.149)
  by mail.wdtv.com with AES256-SHA encrypted SMTP; 4 May 2015 
22:28:30 -0400
From: Gene Heskett <gheskett at wdtv.com>
To: Bill Pierce <ooogalapasooo at aol.com>
Subject: Re: C Library question
Date: Mon, 4 May 2015 22:28:29 -0400
User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748)
References: <14d219039ff-1260-1ce01 at webprd-a20.mail.aol.com>
In-Reply-To: <14d219039ff-1260-1ce01 at webprd-a20.mail.aol.com>
X-KMail-QuotePrefix: > 
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201505042228.29743.gheskett at wdtv.com>

On Monday 04 May 2015 20:53:29 you wrote:
> Gene, I've tried to think of who to ask about my problem, and you and
> Willard Goosey are about the only 2 I know of still around that have
> messed with the C libraries very much. My problem.... I've been trying
> to build the Carl's clib.l and Mike's cgfx.l from sources (on the
> Coco). I have everything compiling and assembling into rofs fine. I
> then merge them into the library files. If I try to use them, the
> compiler tells me that the library is "not an ROF". If I use "rdump",
> it gives me correct rof headers for each rof in the library. If I use
> Carl Kdreider's "lib" utility to try and "split" them beack into rofs,
> it tells me it is not an rof. This got me curious so I "split" my copy
> of Carl's clib.l that I normally use (downloaded from RTSI) and
> compare the rofs from that lib to the rofs in my RELS dir that I
> created on assembly, and each and every file I compiled/assembled is
> exactly 2 bytes longer. Using ded to look at those and the originals,
> it seems every file has 2 extra 0s at the end. Since I was using
> c.comp on the C files and rma from the repo, I dropped back and
> replaced c.comp with c.pass1 & c.pass2 and replaced my rma with the
> one from the original Develepment System disk. I still get the same
> results. This is before the rofs are merged. I am trying to figure out
> what is adding 2 0s (00 00) to the end of each file on assembly.
>
> Any ideas?
> Thanks :-)
>
Not a clue Bill.  the only problem I ever had with home made libraries 
was merge related, and c.link does not make but one pass while resolving 
linkages.  

Translation: if you use function "a" from a module, then later use 
function "b" from the same module, you will have to link another copy of 
that module later in the library.  I recall that an os9 module starts 
with $87CD, and a library module starts with $62CD (I think) but the 
rest of the module is pretty straight os9.

Isolate it down by looking at the assembled modules and see if the 
surplus 2 $00's are there.  If they are, then backup and look at the src 
code being fed to the assembler, there should not be anything that would 
make output after the emod,end statements. 

The size is stored in the header, does it fit with or without the $00 $00 
on the end?

Another person to query would be Willard, he worked on c.prep, but I 
think the rest of it, ansifront, c.opt,and c.opt2, and the c.pass1, 
c.pass2 stuff is close to 25 years old.  Bit rot?

If worse comes to worse, one could probably knock up an assembler built 
routine that would read the header, then copy only the bytes the header 
says it is to a new file, thereby getting rid of the 2 byte surplus?

> Bill Pierce
> "Today is a good day... I woke up" - Ritchie Havens
>
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com

Cheers Bill, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

-------------------------------------------------------
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>