我们的产品使用Greenleaf Archive Library，一个适用于Windows的旧压缩库。我们现在正在寻找移动到mac，但我很确定我们从Greenleaf获得的.lib文件将无法在该平台上运行。
除了转换到另一个压缩库之外，由于多种原因会出现问题，是否有人知道任何替代方案，例如库的开源版本或mac端口？
答案 0 :(得分：1)
Archive2的2.12版本我们在这里附带了完整的源代码，并且在各种编译器下可以轻松地构建。 检查原始安装包，看看它是否有安装源的选项。
答案 1 :(得分：0)
Greenleaf Archive Lib有一些源代码，这些源代码被混淆成各种功能。如今，借助现代IDE，您可以通过重构事情来很好地解决此问题。我还与与之合作的马克·纳尔逊（Mark Nelson）进行了交谈，他通知他们已经从写ARJ的罗伯特·荣格（Robert Jung）处获得了代码的授权，从那时起，尽管我发现没有可接受的许可，但仍提供了ARJ源代码，但我可以确认存档是相同的。除了Greenleaf的滑动窗口较小。
Compression Parameters
The HUS/VIP compression does seem to use the ARJ decode (1 to 3) with a dictionary size of 1024 instead of 26k.
Parameter Value
CODE_BIT 16
THRESHOLD 3
MAXMATCH 256
DICBIT 10
DICSIZE 1024
NT 19
TBIT 5
NP 15
PTABLESIZE 256
PBIT 5
NC 511
CTABLESIZE 4096
CBIT 9
NPT 19
https://community.kde.org/Projects/Liberty/File_Formats/Husqvarna_HUS
现在，ARJ中的参数DICSIZE是22k，而不是1k。但是，ARJ中的NC值也为510，而不是Greenleaf中的511。解码压缩参数更改字典大小。也就是说，每个级别的额外压缩都会增加2的幂。实际上，它是通过位移来设置大小的。
我没有看到任何经过适当许可的东西，因此您可能必须从头开始重写arj压缩方案。尽管技术细节很少，但是源代码本身却很奇怪。显然，他在一个很奇怪的部分上获得了一项已过期的专利，在那里，他显然在做一些哈希表，通过在内存中建立一些表元素并使用它们对下一个索引进行索引来进行霍夫曼编码。它似乎是使用可选提供字典的LZSS方案。但是，该算法的实际工作原理与zip的deflate方案非常相似，实际上可能适合进行deflate。因此，如果由于某些原因而无法编译某些可能难以理解的源代码，则可以将其重写。
我重新编写了减压文件，并使用了MIT许可代码：
https://github.com/EmbroidePy/pyembroidery/blob/master/pyembroidery/EmbCompress.py
这也适用于ARJ压缩，因为我不在乎窗口大小。它会读取任何大小的窗口，因为它只会读取文件中的数据。
对于压缩，我不想花费大量精力编写真实的计划，因此我开发了一种特殊的作弊方式。我们编写了一个包含256个8位长条目的伪表。他们将自然而然地在领带中排名最低，因此他们将精确地映射为与角色本身相等。
Block writing.
16 bits filesize
- Writing Character_Length huffman.
5 bytes: 00000, we have 0 entries. 1 length. They are all 8.
5 bytes: 01010, all values are 10, meaning length 8.
---- CharLength huffman only returns 10.
- Writing Character Huffman.
9 bits: 100000000, 256 entries.
---- All character build with c_len value 10, which is 8. No bits are read.
---- Huffman table of 256 8 entries.
Distance Huffman. (we are never using this).
5 bits: 00000 No entries.
5 bit: 00000 Any value doesn't matter. Since we're never using it.
但是！
45 % 8 = 5
16 + 10 + 9 + 10 = 45 bits.
And we'd have to offset all of our bytes by 3 bits.
So we need a huffman table bit length that is exactly mod 8.
5 bit: 00001 1 distance huffman.
3 bit: 111 we have a variable length value 7 or more.
5 bit: 11110 we add 4 to this 7 for 11. Because really we want to pad bits.
(16) + (10) + (9) + (5 + 3 + 5) = 48 bits. 6 bytes.
2 bytes filesize. Followed by 4 bytes:
0b00000010101000000000000111111110
这可以存储为单个整数：
0x02A001FE
因此要执行Greenleaf或ARJ压缩。
2-byte-block-size + 0x02A001FE + uncompressed_stream
如果需要超过2 ^ 16个字节，则需要更多块。您以相同的方式制作它们。