[Implemented] zlib's deflate as the standard crossplatform

[Rescator]

Currently x64 uses brieflz and x86 uses jcalg1.

The interesting thing however is that zlib.lib is included with PureBasic (used by PNG etc. as well)
zlib's deflate is faster than jcalg1, and the compressed size is pretty close to jcalg1, inflate speed is pretty close to jcalg1 as well.
zlib's deflate compress better than brieflz.

zlib is the de-facto industry standard, been in use for like 10 years now,
and it still has one of the speed vs compression balances.

Fast compression and low memory use,
one of the fastest decompression speeds, and very low memory use,
compress data never increases in size, un-compressible data is simply stored,
solid code, even feeding junk into the de-compressor won't crash it.
An insane number of games and applications use and rely on it.
Webservers (Apache), PHP, etc, use or support it for compressing web pages, web browsers support it for decompressing webpages.

I'm not saying zlib's deflate should be the only compressor for PureBasic,
but it surely is perfect as the default one?

zlib.lib is around 100KB, (less when the program is compiled obviously).
If only the deflate ad inflate code is used (or stripped down to just those two) then the size is reduces to 10-15KB if I recall correctly.

No patent issues, liberal license (zlib license), multiplatform, x86 and x64, good compression, high speed, low memory use, highly supported, time tested, industry standard, can't go wrong with that can we?

Can you tell I kinda think zlib's deflate rocks?

[ts-soft]

+ 1

I use zlib in most of my applications

[srod]

Yes being able to use the same algorithm with PB x86 and PB x64 would be great. Though I think Fred said that this is indeed forthcoming.

+1.

[Fluid Byte]

+1

[DoubleDutch]

But with the ability to decompress older files!

[netmaestro]

What they might do (just guessing) is change the packing to a plugin system similar to image decoders/encoders. When all is said and done this would be the best approach imho. I hope they do it.

[AND51]

netmaestro, that's a great idea!
I would also vote +1 for this request, but with your idea of a plug-in system you could use the good old commands with different compression methods. Another great advantage would be, that the current commands can be kept for future versions as well, just with tiny adjustments:
There could/should be flags when creating packages, to determine, which compression methods should be used, similar to SaveImage().
Another command could be added, informing about the compression method (zlib, jgcal1, etc.) when opening a package.
I think, Resactors arguments are convincing, since zlib seems to be used in many cases, e. g. on webservers.

Additionally, I would request to modernize the Packer-lib by introducing the ID-system. Then you could handle more than 1 package/archive at the same time.

[freak]

What they might do (just guessing) is change the packing to a plugin system similar to image decoders/encoders. When all is said and done this would be the best approach imho. I hope they do it.

This has been planned for quite a while, but it isn't really a priority. So better don't hold your breath

[USCode]

+1
I've been badgering Fred and Freak for this for years. Its been a defacto compression standard for ages and native PB support as part of the Packer library would be a very worthwhile addition. How about if we bribed you guys to add it?!?!

[Thorium]

Hm, 4.31 and 4.40 using zlib if i am not mistaken.
The signature of the data is "zlb".

But why making the packer incompatible in the first place?
At least the x86 version could have the ZLib decompressor and detect if a compressed buffer is JCalG1 or ZLib by the signatur.

At the moment the whole packer lib is useless for me, because i need a compression thats compatible between 32bit and 64bit Windows.

[USCode]

Yeah I was hoping this would make it into 4.40 as well but after looking at the 4.40 changelog I can't complain! They've been busy!
Fingers crossed for the next release.