JCALG1 vs (new)BriefLZ vs Zip vs LZMA

[sartic]

I still miss jcalg1. It was better for my purpose!
BriefLZ is fast. Zip is little slower than LZ. And LZMA is slooow when compressing.
Testing stuff before changing code in 5.00 programs.
I have to admit I have problems with LZMA in (un)compressing memory. I lost all day to investigate why is not working as LZ and Zip with same code.

[Thorium]

In all my tests zlib was both faster and had a better compression ratio than jcalg1, in all cases.
What kind of data you are compressing?

[sartic]

zlib is not internal.
i used jcalg1 for my installer, packer, binder. i learned that compression level 5 is optimal (i used 9 or 8 for small files)
new version is using lz and zip as option (i give up on internal lzma; not working and slow).
i am using some kind of solid archiving (sorting all by context and compressing all as one big file).
old version is still better than new in size for smaller instalation. new version with zip has lower size with larger install.
compression time is relativly equal for all three options in compare with non working lzma.
zip has nice bonus to create zip compatible archive (i prefer external 7z).

[Thorium]

Didnt used the new internal LZMA. However someone posted a working LZMA.lib with example code on the forums and i used that.

LZMA is way slower in compressing but has a better compression ratio. I would guess that zip works using zlib. At least zlib is included in PB for the PNG decoder and encoder and can be accessed very easiely by importing it.

If you still want to use jcalg1, just create a little dll with a older PB version exporting what you need. And load that dll in a program made with the newest PB version. Keep in mind that jcalg1 is 32bit only! If decompression speed is important for you, you could use my jcalg1 decompressor, which is 64bit compatible and faster than the original implementation. Depending on the kind of data (5-10% on photos, up to 20% on text): viewtopic.php?t=38606

[jassing]

If you still want to use jcalg1, just create a little dll with a older PB version exporting what you need. And load that dll in a program made with the newest PB version.

Strictly speaking, wouldn't that be against the EULA?

[Fred]

If you still want to use jcalg1, just create a little dll with a older PB version exporting what you need. And load that dll in a program made with the newest PB version.

Strictly speaking, wouldn't that be against the EULA?

If you use it with PB and for your program, it's not a problem.

[DoubleDutch]

If it does no harm , why not keep jcalg1 forever for x86 - but just don't support it?

[sartic]

+1

[DoubleDutch]

Fred: Why don't you use Thorium's code at viewtopic.php?t=38606 and make a decompress lib for x86 and x64, then just leave it in but not support it? (are not only x86 and x64 processors supported now? - if Arm ever gets supported then you don't need jcalg1 - but if someone wrote an Arm version for you then you could also maybe include that?)