Sure. Why do it in a simple way if you can do it complicated. Let the mickeyratt become a full time programmer, learn about the compression method(s), learn how to debug the damn thing and then, maybe, possibly, pehaps one day that thing will work. But maybe not. 

All that instead of one empty EEPROM chip, soldering iron and about half an hour of work.

So, does anyone feel like writing some condensed articles based on the threads posted here? Would greatly appreciate the help!

Btw, I should use MacTorrent more.

Poke a bit at the sources and see if you can make it better

It appears the filler bytes between strings allow the strings to be treated as C strings.

The comment string has a two byte length and is therefore not a pascal string.

Since the ckid is variable length, I would maybe copy only the non-variable part from the resource to CkidRecord (everthing before projectPath).

C in classic Mac OS may have an option to print pascal strings. Is it "%p" instead of "%s"? I forget. That's not going to work for the comment which as a two-byte length.

Since the strings always have a terminating null character, you can treat them as C strings (unless you think someone might try putting a null character inside the string).

If you need to modify a string, you need to remember to update the length. If you update the length, you need to move all the following strings. If you make a string longer, then you need to move all the strings before making it longer.

Str255 is defined in MacTypes.h as:

typedef unsigned char        Str255[256];

That being said, I based the struct in my first post on the Pascal structure defined in the PDF I referenced.  It definitely has pad bytes, and you can see them in ResEdit too, where there appears to be two ^^'s between each data field.

Still not sure what to do here... should I be able to get this to work with C structures, or should I try and parse through it one character at a time?

Thank you!