PureBasic Forums - English

Hi Fred,
Enhancement request: Packer support for ZIP compression algorithm.

For PureBasic 4.0, is there any possibility we could have multiple algorithm support for the Packer command, in particular the ZIP compression algorithm?

Perhaps just an additional parameter (and PB constants) to the Packer command to specify which algorithm to use. ZIP is so common and widespread, it would be nice to have it supported natively in PureBasic using the Packer command.

I believe there are open source and liberally-licensed ZIP libraries that could be leveraged directly in PureBasic to support ZIP.

Also i wouldnt mind if the packer supported more algorithms.

An option to switch between BriefLZ and JGCalc wouldnt be bad
Sometimes the compression needs are different. Sometimes you need the best compression, sometimes you need the best compared to speed (not the best compression ratio)

thefool wrote:An option to switch between BriefLZ and JGCalc wouldnt be bad

Better split it up in multiple libs identified by prefix so JGC_OpenPack(), ZIP_OpenPack(),...
(let's keep the exe small )

Dummy wrote:

thefool wrote:An option to switch between BriefLZ and JGCalc wouldnt be bad

Better split it up in multiple libs identified by prefix so JGC_OpenPack(), ZIP_OpenPack(),...
(let's keep the exe small )

Good idea

Better split it up in multiple libs identified by prefix so JGC_OpenPack(), ZIP_OpenPack(),...
(let's keep the exe small Wink )

I don't know anything about the PB compiler/linker internals but rather than using command prefixes couldn't we still go the parameter route for consistency with other PB commands and let Fred handle in his code which libraries are or are not linked in?

Sure, it's just ugly with prefixes . We planed to do that trough a module approach, like image and sound libs. On the todo list.

Nice to hear

Will be included in 2010

LOL, 7zip integration would be nice but I don't think 7zip will be good 2010

I visited 2010 yesterday with my home-programmed timemachine (programmed using pb 5.0), we dont compress anything anymore. Everyone simply got lightning fast internet and too much diskspace. Actually PB 5.0 blows the exe's very much, because we dont know how to use all our discspace!!

As you might guess, bericko has taken over the programming of pb because he is so lazy and simply bloats everything he touch!

Anyway thanks for the chat and cya in some years..

thefool wrote:I visited 2010 yesterday with my home-programmed timemachine (programmed using pb 5.0), we dont compress anything anymore. Everyone simply got lightning fast internet and too much diskspace. Actually PB 5.0 blows the exe's very much, because we dont know how to use all our discspace!!

As you might guess, bericko has taken over the programming of pb because he is so lazy and simply bloats everything he touch!

Anyway thanks for the chat and cya in some years..

I visited 2010 today with my home-programmed timemachine, and I think your timemachine has a bug, because compression will be everything. CD/DVDs already get destroyed with the specific drive if it is at all it can do status. So speed of drives can't be better anymore.

i think YOU got a bug. Tss tss dont remember i programmed my machine with the NEXT # VERSION OF PUREBASIC!! (of course, when its bericko behind the main compiler you never know!)

Fred wrote:Sure, it's just ugly with prefixes . We planed to do that trough a module approach, like image and sound libs. On the todo list.

nice idea. I agree

Sure, it's just ugly with prefixes . We planed to do that trough a module approach, like image and sound libs. On the todo list.

That's terrific Fred, thanks! I was hoping there was an alternative to the prefix method, that did seem a bit like an ugly hack.