archer%segin4.segin.fr@relay.prime.com (Vincent Archer) (08/22/90)
I was happy to see the first "official" ST patch. I was less happy to see that
it was compressed with 16 bits compression!!! :-(
I spend a full hour trying to find a way of having compress.c compile with 16
bits decompression... Here are the pitfalls in which the unwary ST user will
fall if it tries to make compress.c a worthy tool:
* Undefine AZTEC86
We're not in the xx86 world, so why bother. This defined was intended for
64K I&D compilers.
* Now that AZTEC86 is undefined, compress.c will come up with 16 bits (or try
to). A few necessary lines of code are now phased out, they should be phased
in:
- Move the void xxxx(), xxxx(); declaractions outside of the #ifdef
- Move the #define htabof(i) htab[i] outside of the #ifdef
* Hugh: strrchr() is now defined TWICE (once because we're not using AZTEC86,
a second time because we're under Minix). Throw the #ifdef _MINIX / #endif
away (with all that's inside).
* Still, uncompression does not work better. Try to find all the:
1 << bits
expressions. All the 1 should be changed to 1L !!!
With that, compress does compile, compress and uncompress. I suggest that you
find out the default compression value (int something = BITS;) and replace it
by the default 13, otherwise, you'll end up generating 16 bits compress
yourself!!!
Apart from that, the kit is a boon. Now, I'm investigating the "other" kit,
the one with ansification. There are some bugs that get corrected in there,
including one for PCs in mm (mm/signal.c)!!! I'll post a summary of the
interesting fixes later.
Vincent
Vincent Archer | Email:archer%segin4.segin.fr@relay.prime.com
"People that are good at finding excuses are never good at anything else"