[Coco] Fwd: failure notice

[Gene Heskett]

On Tuesday 12 May 2015 02:40:36 Bill Pierce via Coco wrote:
> Gene, I haven't a clue why the email didn't go through, I used the
> same address and method I always use... probably some "Linus
> thing".... security blanket and all that... (j/k)but anyway...

Naw, likely aol has gone down the same road yahoo has with a certificate 
based msg acceptance policy.  That BS has rather effectively broken the 
internet.  And I find it a bit ironic that yahoo was first with it, when 
in fact 20% of my incoming spam has been thru a yahoo server.

> The problem is that when I assemble (or compile, in the case of C
> sources) the sources to CK's clib.l, EVERY resulting ROF has 2 extra
> zeros at the end.
>
> Apparently, when trying to compile a C file using the merged library,
> the linker (and any other file made to use ROFs), reads the header,
> which is WAAAY different from a standard OS9 header, and get the ROF's
> size, then uses this size to calculate where the next header should
> be... So the zeros must not be figured into the size as the linker and
> CK's "lib" which separates C libraries, reports that the file is not
> an valid ROF. In fact, CK's "lib" separates the first file in the
> library then pukes on the second because it can't find the header, so
> it assumes the library is not an ROF. It will separate CK's clib.l
> fine. I have checked the assembled files against the library files
> that I've been using and they are byte-for-byte identical except for
> those two bytes at the end. Even the headers are the same.
>
> I tried using RMA and C.Asm, and both produce the same result. The
> resulting rofs, when merged, should make a valid lib file, but the
> linker says no, and aborts if I use the lib in a C compile.
>
> And I have CK's notes on the contents of the ROF header. It's much
> more complex than a standard OS9 modules header. The ROF header
> contains all the info about the file's global and dp variables as well
> as the pointers, so that the linker can tie them all together later
> when used in module. In a C library, these ROFs are left raw and just
> merged so the linker is not involved until the library is used.
>
> I want to make some "custom" libraries, but until I solve what's
> adding the "00 00" to the end, it ain't happenin'

Does the linker use the module length, and is this module length correct 
such the the extra $0000 int is detectable, and fixable by a quick 
assembly program that would copy only the valid bytes, piping that into 
the merge command that makes the library?

Its a problem I never had a decade and change ago.  Have you asked 
Willard, who did a more recent c.prep, if he has encountered this?
If not, get the crc's of what he is using so you can tell when you've 
found the ones that work.

Worse comes to worse, ded might be able to fix it by reducing the module 
size by 2 bytes, do this in the raw ROF's FD sector. How difficult this 
is depends on how many modules there are to fix.  Keep in mind that 
would probably need a v for verify to fix the files crc for the new, 
shorter data length too.  I think this would have to be a 2 copies of 
ded running project, one to edit the FD.sector, and one to load the file 
to verify that it has been fixed.

Unless you can ID the compiler module that is doing the fubar output, 
thats the best idea I can come up with.

> 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, 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>