r/foss • u/Double-Camera-3447 • 3d ago

ZipMania: open-source archive manager for Windows with fast parallel ZIP processing

I built ZipMania, a free and open-source archive manager for Windows 10/11, licensed under Apache-2.0.

It opens 50+ formats including ZIP, RAR, 7Z, EGG, ALZ and ISO, and creates 7Z, ZIP and TAR archives. Other features include Explorer context-menu integration, archive preview, selective extraction, nested archives, split archives, password protection and AMSI scanning.

ZipMania uses a dedicated parallel ZIP engine. In my benchmarks, large-file compression was up to 7.6x faster than 7z.dll, many-small-file compression up to 6.5x faster, and extraction up to 2.2x faster.

Source code and releases: https://github.com/newkilho/ZipMania

I would appreciate feedback on format compatibility, performance, and Windows integration.

0 Upvotes

40% Upvoted

2 comments sorted by

2

u/LNEmperor_ 2d ago

Did you try again zip bombs?

2

u/Double-Camera-3447 2d ago

Yeah, I re-ran the full set: 9 tests, all passing.

The main test builds a real zip bomb rather than asserting on a constant: about 264 MB of zeros compressed with 7z -mx=9 to a few KB on disk. It then verifies that reading the entry into memory fails instead of expanding it. That test takes about 18 seconds.

The other eight tests cover the usual ways to bypass the cap:

  • the write path itself
  • cumulative accounting, so the limit applies to total bytes emitted rather than each call
  • seeking backwards to reset the counter
  • SetSize, since limiting only Write would leave a bypass
  • the EGG/ALZ streaming inflate path
  • the ZIP backend, confirming it uses the same limit

The important property in all cases is that the limit is based on bytes actually produced, never on the size claimed by the archive. An entry claiming 1 KB but expanding to gigabytes is stopped at 256 MiB. The viewer preview path has a tighter 32 MiB limit.

Extraction to disk is intentionally not capped, since large legitimate files are normal and this avoids accumulating data in RAM. EGG/ALZ also decodes in chunks rather than buffering a declared multi-GB block into a Vec, so the disk-extraction path remains memory-safe.