Hello John,

 BL> This way, you have to open the file, read the header, and then
 BL> write the entire file to copy it, then close it, then open it
 BL> and decompress it having decided the correct decompressor. This
 BL> is totally stupid! You end up reading the entire file twice.

 JT> I'm not sure how this is handled in unix, but it works there.

  My favourite definition of engineering comes from Arthur M.
Wellington: "... engineering is the art of doing that well with one
dollar what any bungler can do with two after a fashion."

  I didnlt say it doesn't work.... just that it is stupid to do it
that way. 

 JT> If you have a de-compresser that can't work with it, it was
 JT> probably not designed with mail in mind. 

 BL> Neither compress 320, gzip, nor zip handle it... they're the
 BL> three that were designed with mail in mind.

  (grin)

 JT> Ok, in that case I agree, they're all fucked. What can be done
 JT> to "fix" the problem? Is there any PD source available on the
 JT> decompression methods? 

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

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

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

Regards,
Bob
     
___ Blue Wave/QWK v2.12
@EOT:

---