It never opens a compressor. It only spawns processes.
heavenzip chains prebuilt binaries — a preprocessor, then ziptastic,
then a recompressor — into one .hzpkg archive. File in, one file out, and the
package carries its own manifest.
Each seam is a process boundary, not a function call — the orchestrator hands over a file path and takes back a file path, and never sees a compressor's internals. The manifest records exactly which stage produced which bytes.
Where it is today
| Part | State |
|---|---|
| Stage chaining and the manifest | working |
ziptastic and preflate stages | working |
| Reverse — decompress to bit-exact original | working |
Prebuilt binary bundle in bin/ | in progress |
| End-to-end benchmark table | not published yet |
This page says "in progress" where that is the truth. A development page that describes the finished thing is a page that will be wrong in public.
Why it spawns instead of links
A boundary between licences
Some of the best compressors in the CHCE family are GPL. Linking them into an MIT binary would drag the whole thing under the GPL; spawning them keeps a process boundary between the two licences.
Nothing shared but a path
The orchestrator never sees a compressor's internals — it hands over a file path and takes back a file path. That is the entire interface.
A manifest that explains the bytes
Every package records which stage produced which part of it, so a later reader can say what happened without re-running anything.
What a run looks like
# the orchestrator spawns; it does not compress heavenzip pack document.pdf -o document.hzpkg # inside: preprocessor -> ziptastic -> recompressor # and a manifest recording which stage produced which bytes heavenzip unpack document.hzpkg -o restored.pdf # bit-exact
Support the work
Free to use, and it stays free
Everything here is free, offline and accountless. If it earned its keep, there are a few ways to say so — pick whichever is easiest where you are.