-=> Quoting Bob Lawrence to John Tserkezis <=-

Hello Bob,

 BL> The obvious thing is to remove the "#! (x)unbatch" line and let the
 BL> uncompressors identify it for themselves, but yes... PD code is
 BL> available for compress, gzip and zip. A have a version of gzip that
 BL> identifies all three compression methods after the unbathc line has
 BL> been removed, but it's a bit slow...

 Is it slow just "because" or does it have to use "trial and
error" to work
out exactly what type of decompression to apply?  If you have the source, it
should be possible to change it to adapt to the cuntbatch line if it has one.

 BL> What I've done, is add it on the end of the download. If you poll
 BL> for 50K of mail it takes 30 seconds at 14400, and the 4 seconds to
 BL> open all the files, strip the unbatch and uncompress it is lost in
 BL> that 30-seconds.

 That is ok for an end user, but if you do this as a mail hub, it drags things
on for too long a time.

 BL> That's the beauty of Windows and event driven code. If you can keep
 BL> the processing under 100mS you don't even notice it... so you tag all
 BL> the long stuff onto whatever is unavoidably too long (like loading the
 BL> EXE file itself).

 Windows makes me ill.  That's why I'm back in the electronics industry.  I
can use my OS of choice, I don't have to worry about if I know windows or not.


John Tserkezis, Sydney, Oz. Fidonet: 3:712/610  Internet: jt{at}suburbia.com.au

... Be reasonable, do it my way.
---