Message-Id: <199611110025.NAA25683@papaioea.manawatu.gen.nz> Comments: Authenticated sender is From: "Malcolm Taylor" Organization: Grafik Software To: Mark Habersack , grendel AT ananke DOT amu DOT edu DOT pl Date: Mon, 11 Nov 1996 13:24:09 +1200 Subject: Re: Why not to use 'tar' before packing DJGPP? Reply-to: malcolm AT manawatu DOT gen DOT nz CC: djgpp AT delorie DOT com > > archives then I can throw together a good archiver for the job in > > less than a week. It would not be as fast as pkzip, but should get > > significantly better ratios without too much more time. Is there any > > interest in this? > Would you use the Deflate algorithm or one from RKIVE? No, I was thinking of an algorithm similar to one used in an earlier version of RKIVE but optimised for speed and using less memory. > I think Deflate > is good enough and with some improvements (bigger dictionary, treating > ALL files as one stream of data without clearing the dictionary every > time new file is read, sorting files by type - i.e. extension, creating > a complete histogram before compressing) it would give much better > results tan either ZIP or PKZIP. Just increasing the dictionary isn't a great improvement. On most files it'll hurt compression (that's why 64K or 32K dictionaries are generally the largest that older LZ archivers had) you'd have to at least raise the minimum match length for the larger offsets. Having said this I think a completely new algorithm would be called for. PKzip uses huffman coding on everything, but arithmetic is better (slower though) for example. > I think it is important to stay at the > ZIP file format so that all the tools still work with it. This, of > course, wouldn't increase compression ratio as much as a completely new > archiver, but still it'd better than the old, good ZIP. I don't think it would be possible to stay with the zip format. Just going to solid mode compression (all files in one stream) would break it anyway. Malcolm