holgerl@amiux.agsc.sub.org (Holger Lubitz) (05/11/91)
As I already mentioned in my previous posting, I am currently forwarding any articles concerning Zoom! by Olaf Barthel to him since he hasn't access to news at the moment. This is his reply to the 'Zoom! crashes'-articles which recently appeared on this newsgroup. Please note that I set the 'Reply-To:'-Field to Olaf Barthels mail adress. Best regards, Holger ** Olafs reply starts here ** Having just received a bundle of messages discussing Zoom! I suppose it's time to explain why Zoom! crashes on some systems and to end the speculation. - The standard vanilla Amiga boots with the default stack of the initial CLI set to 4000 bytes. Most users feel little need to change this, while most `C' programmers have to raise the default CLI stack size in order to keep the compiler from crashing. Pre-4.2 releases use a lot of stack space, 4000 bytes definitely being not enough. A number of temporary variables (such as long strings) are assigned while the program is running. No checking is done for stack overflow/underflow. Consequently, Zoom! would crash a) after displaying requesters, b) after leaving the compression/decompression subroutines, c) after program termination. My working environment has the default stack size set to 20000 bytes, that's why the problem never showed up at home. - Zoom! uses two different data encoding routines for compression. The first one compresses rows of equal bytes (the lzh-compression-routine has the disadvantage of spending a lot of time trying to match rows of equal bytes) followed by the lzh compressor which handles the main compression part. While it was easy to adapt the lh compression routines to work with Zoom! the byte-run-compressor required more time and thought. Ralf Thanner had adapted the compression/decompression code to suit Zoom! Unfortunately documentation was sorely lacking causing the decompressor to start decompressing at the wrong memory location. This is why the contents of some disk tracks appear to have been shifted up by one byte. - Each track is compressed and stuffed into a `box' according to the contents of the disk bitmap. This `box' is passed through the byte-run-compressor and the lzh-compressor. Sad to say, this routine contained a subtle bug causing the blocks to be cleared to be selected by random. The compression routine could even be told to compress zero bytes causing the byte-run-compressor to hang. - I am not so naive to believe that both compression runs will always be able to reduce the size of the `box'. Zoom! will always notice if compression does not reduce the size of the `box'. There are no overflowing buffers. I have just been able to fix the bugs/problems listed above. Judging from the bad reputation Zoom! has received over the past few months I suppose that it's better to spend some more time on testing and debugging than releasing Zoom 4.2 immediately. -- Olaf Barthel, Brabeckstrasse 35, D-3000 Hannover 71, FRG