Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!wuarchive!udel!mmdf
From: archer%segin4.segin.fr@relay.prime.com (Vincent Archer)
Newsgroups: comp.os.minix
Subject: ST patch 1
Message-ID: <28101@nigel.ee.udel.edu>
Date: 22 Aug 90 07:32:18 GMT
Sender: usenet@ee.udel.edu
Lines: 38

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"