I was searching for the latest version of the interesting "624" (Six-2-Four) .COM file packer, and found the following article:
https://codejuggle.dj/analysis-of-the-624-six-2-four-packer/
In that article they give these ideas to improve the compression rate:
1 With the current implementation the first byte is always a literal, therefor the bit in front to mark it as literal is not needed. The unpacking stub could jump at beginning of execution directly to the code to copy the literal to the output buffer
2 A match will probably be followed by a literal. The bit to mark the literal can be skipped and the unpacker adjusted to expect a literal after a match without changing the size of the unpacker stub
3 A run of literals could be encoded with the length of it. The following compressed flag of the match following the literal run would not need to be saved
4 Huffman codes can be replaced by [gamma encoding](https://en.wikipedia.org/wiki/Universal_code_(data_compression)), which would result in a smaller unpacker stub but may depend on the input file to compress to improve the overall compression ratio
The packer versions to download:
Version 1.0:
https://files.scene.org/view/mirrors/hornet//code/compress/plp_624.zip
Version 1.1:
ftp://ftp.sac.sk/pub/sac/pack/624-11.zip
Do any of you dare to improve the 624 packer a bit?  |
Thread view
Board view
