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

> 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!
Freedos-user mailing list

Reply via email to