Hi, On Fri, Aug 30, 2013 at 12:19 AM, Mateusz Viste <mate...@viste-family.net> wrote: > > On 08/30/2013 06:42 AM, Rugxulo wrote: > >> IIRC, the default mode of 7za is -mx5 and .7z format using LZMA [or >> LZMA2 in newer alphas] method, which means (among other things) 16 MB >> dictionary, aka 2^24, aka LZMA:24 (but you can adjust that). > > This is right. But "bigger dictionary" doesn't necessarily mean > 'better'. well, sure, it means 'potentially better compression ratio', > because we can seek back redundant data in wider spans, but it also > means 'tremendously higher memory requirements'. This is why I don't > create FDNPKG packages using LZMA (unless for pure experimentation), > even though it's 5-15% smaller than DEFLATE. Trying to uncompress an > LZMA file on a <16MB RAM machine is hell (or simply impossible if no > virtual memory is available).
While some compressors use a minimum dictionary size regardless of the file size (e.g. bzip2 defaults to 900k unless explicitly told otherwise), 7-Zip is apparently smarter. At least, my one-floppy DJGPP .7z file only uses "6m" (6 MB, roughly the size of all files unpacked), so I did correctly decompress it (years ago), without swapping or slowdown, on a 486 with 7 MB of extended RAM. This was not possible with UHarc, which needed approx. 24 MB (by default with "-mx", I think). And like I said, you can make the dictionary bigger or smaller, depending on need. I don't remember the limits, perhaps 1 GB is max. And BTW, just for more arcane useless trivia, CWSDPMI won't allocate the total RAM size requested for its swapfile unless it is actually used (unlike Causeway), which is of course a more efficient way of doing things. >> Even .ZIP format can officially support Bzip2 or even LZMA >> method (or others). > > That's exactly what FDNPKG supports - LZMA-compressed files inside ZIP > 'slots'. This allows using the cool ZIP structure for handling files > (and extracting only these we need - eg. without SOURCES), but still > benefiting from the LZMA compression ratio. IIRC, zip 3.0 and unzip 6.00 both optionally support bzip2's compression method via libbz2 (or whatever it's called) at compile time (see "unzip -v" and "zip -Z bzip2"). E.g. my native Windows versions here do and don't support it (but Cygwin zip does). Though I don't know why there was never an official build of zip 3.0 for DOS. (I vaguely recall some tmpfile bug, but it wasn't pressing enough for me to care. I presume that others were similarly less interested, as always.) > indeed, .gz is designed to compress only a single file. No 'directory > storage' capabilities there. Still, for 'single file' compression I'd > use gzip over zip anytime. It's fits better, because it provides all we > need, without any additional garbage (mostly limited to filename + CRC32 > + a few flags). Well, as usual, things are as complicated as you make them. Yes, .ZIP has some minor overhead, but like I said, it's not technically true that it's always smaller to use .gz (or even .bz2) instead of .zip. Some tools don't handle both .gz and .tar.gz, e.g. DJGPP's djtar only handles the latter (and also .tar.bz2 in "beta" djdev204.zip ... and of course plain .tar and .zip). GNU gzip can unpack a .zip if it only has one file inside, but I don't think the *BSD equivalent has that feature. Yeah, I know, minor stuff, but it's somewhat annoying when your options are limited (e.g. no network connection or no compiler or similar trivial problem). >> "Usually" but not always. 7-Zip provides its own "improved" Deflate, >> which is slightly better > > On a side note: some decompressors have troubles handling the 7zip > 'deflated zip' files sometimes. For example kunzip crashes on some zip > files created by 7za, while it doesn't crash on any other files created > with 'classic' zippers. There are literally dozens of decompressors for .zip files. It would be impossible, even with "standard" appnote.txt, for them all to fully comply. I've not seen any huge problems, but it's always possible. If you (or yours) use kunzip much, maybe that's a concern, but since I (naively?) don't consider that a widely-used implementation, I'm not too worried. I mean, Ubuntu has unzip by default, last I checked, and of course Windows Explorer supports unzipping since I don't know when (ME? XP?). Even *BSD has a partial implementation of unzip too (libarchive?). In other words, I don't personally see a huge need for kunzip, but the more the merrier! :-) > Well, adding is easy (you just strip the directory from the end, append > your file and recreate the directory). > Deleting is trickier, indeed.. (need to move all data around to cover > the empy hole left by the deleted file, and recalculate all data offsets > in both the central directory and per-file headers...). I'm not sure how well most tools handle this. The naive approach would be to temporarily duplicate the entire file, which may be unfeasible with very large sizes. ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
