DevZIP opens up its archive engine

DevZIP asks a straightforward question: can we make smaller archives for mixed real-world files while keeping the format understandable and the engine maintainable? The April 13 source publication put the native C++ engine, command-line tools and Windows WPF shell into the public repository.

The archive format is .dvz. It records the backend identity so the decoder knows how a block was stored, while the pipeline handles preprocessing, solid groups and deduplication. The desktop interface delegates the actual compression and extraction work to the native command-line engine.

The initial retained README described a best-of-two default and a mixed-large benchmark where DevZIP produced about 143.8 MB against about 144.8 MB for the 7-Zip LZMA2 baseline. That was a modest size improvement with a real time cost: roughly 304 seconds against 107 on that recorded run.

I like having both numbers in the same explanation. A smaller archive can be valuable, but someone making a quick transfer may care much more about how long it takes. The project needed to show the tradeoff rather than presenting one size result as a universal win.

The Windows preservation contract was deliberately bounded too. It covered things such as file bytes, relative paths, empty directories and modified timestamps, while excluding ACLs, alternate streams, EFS metadata and sparse-hole maps. That makes this different from claiming a complete system-backup format.

This was a source-publication milestone, with benchmark results recorded in the project rather than independently rerun for this article. The next work broadened the compression choices and content-aware transforms, keeping byte-exact reconstruction as the check that mattered before celebrating a smaller output.