[Implemented] Packer functions on Linux

Num3 · Post by **Num3** » Mon Mar 22, 2004 6:16 pm

Would be nice the packer lib worked under linux too

thefool · Post by **thefool** » Fri Apr 02, 2004 11:13 pm

USCode · Post by **USCode** » Sat Apr 03, 2004 12:33 am

I know the current packer algorithm is superior to the zip algorithm but it would be more handy to be able to pack data in the zip format AND it would also be easier for Fred to support the zip packer lib on ALL platforms since it's so widely available across platforms. (zlib?)

I'd like to propose we change the packer algorithm to use the zip algorithm.

Shannara · Post by **Shannara** » Sat Apr 03, 2004 1:01 am

how is the current packer algo superior to the zip algo? I could of swore the zip algo has to do with compression, while the pb packer algo does not.

Post by **freak** » Sat Apr 03, 2004 1:38 am

Shannara wrote:how is the current packer algo superior to the zip algo? I could of swore the zip algo has to do with compression, while the pb packer algo does not.

What the heck are you talking about?? The packer library doesn't compress??
What else does it do in your eyes?

In fact, the PB packer lib does produces better results than zip.
And even though, packing is very slow, unpacking is really fast, which makes
it perfect to compress your program's data.

I would not like to see the current algo be replaced by the zip one.

Timo

Shannara · Post by **Shannara** » Sat Apr 03, 2004 2:48 am

agh! my eyes are gone, nooo!! I was thinking of vbin, not packer, hehe my bad.

PolyVector · Post by **PolyVector** » Sat Apr 03, 2004 2:51 am

USCode · Post by **USCode** » Sat Apr 03, 2004 7:13 am

I guess my main points about replacing the existing algorithm with ZIP are:

- ZIP is available on most platfoms, making it easier for Fred to leverage existing code to make it available on all PB supported platforms and to do so relatively easily, not just Windows...
- ZIP is a very common and ubiquitous method for exchanging files.
- Not the best but a decent algorithm.

To mean, it just seems more useful overall.

thefool · Post by **thefool** » Sat Apr 03, 2004 10:58 am

But, when using the pb pack library, most people cant uncompress it without having a decompresser for PB packed files. If you NEED zip, look for an userlibrary with it. I found one once, and i think i remember that it worked good. Or else - look for dll files on the internet. there is some free ones out there. And you can include that dll to your .exe file and unpack it on runtime, so user wont notice.

USCode · Post by **USCode** » Sat Apr 03, 2004 10:26 pm

Well, whichever packer algorithm is used, I'd like to see the packer function at least be cross-platform (according to the docs its Windows only) AND produce files which can be packed on one platform, then be unpacked on another. Sure, we can download zip but it'd be better if it was built in, since packer is already there.

Wish summary:
- Packer available cross-platform
- Packed files unpackable on all platforms, irregardless of which platform packed on.
- Switching to zip would make this easily attainable.

.

But, when using the pb pack library, most people cant uncompress it without having a decompresser for PB packed files.

That's my whole point. It'd be much more useful to produce zip files instead of pak files for this very reason. Zip is available everywhere! Then you don't need a PB program to unpack the files...

thefool · Post by **thefool** » Sat Apr 03, 2004 10:30 pm

it was menshioned as a good thing. so users just dont go extracting important files and more. But what about AddZipPackFile() and openZipPack()

Shannara · Post by **Shannara** » Sat Apr 03, 2004 11:23 pm

I agree with thefool, the reason it is only unpackable w/ pb programs is to help deter criminals. However, it's flaw is that any pb program can unpack packed files.. if there was some sort of way to have an encryption scheme or some such... That and the fact that purebasic is easily downloadable (3.81) anywhere on the internet for free...

thefool · Post by **thefool** » Sun Apr 04, 2004 12:04 am

yes, a crypt scheme would help. But i agree with uscode, zip if widely used and should be included. that was a thing i missed in visual basic. I know you could get t
the functionality, but if it was built in, it would be better.

I think the packer lib should stay in pb, and that we get one more lib, a zip lib off course seperated from the original packer, but so the zip funtionality is there.

USCode · Post by **USCode** » Sun Apr 04, 2004 12:42 am

I agree with thefool, the reason it is only unpackable w/ pb programs is to help deter criminals. However, it's flaw is that any pb program can unpack packed files..

Yeah, as you said, any PB program can unpack the files. However, can't ZIP files be password protected? I'm sure it's probably not a very robust protection but it could offer some protection against casual hackers at least.

How about a new option to set the packer algorithm, maybe something like SetPackAlgorithm(x)? Same functionality but just a new algorithm/format option: either the orignal JCalG1 or the ZIP. Any maybe others in the future.

SetPackAlgorithm(0) = JCalG1 (the default anyways to as not to break existing code.
SetPackAlgorithm(1) = ZIP (then all Packer library functions would use the ZIP algorithm)

This way we can have the best of both worlds:
- Same set of Packer functions everyone is familiar with.
- Keep the JCalG1 as the default but calling a function sets a new algorithm to ZIP (or others?)

How's that for a compromise? Now, if we can only get Fred to agree...

thefool · Post by **thefool** » Sun Apr 04, 2004 9:56 am

USCode wrote:
I agree with thefool, the reason it is only unpackable w/ pb programs is to help deter criminals. However, it's flaw is that any pb program can unpack packed files..
Yeah, as you said, any PB program can unpack the files. However, can't ZIP files be password protected? I'm sure it's probably not a very robust protection but it could offer some protection against casual hackers at least.

How about a new option to set the packer algorithm, maybe something like SetPackAlgorithm(x)? Same functionality but just a new algorithm/format option: either the orignal JCalG1 or the ZIP. Any maybe others in the future.

SetPackAlgorithm(0) = JCalG1 (the default anyways to as not to break existing code.
SetPackAlgorithm(1) = ZIP (then all Packer library functions would use the ZIP algorithm)

This way we can have the best of both worlds:
- Same set of Packer functions everyone is familiar with.
- Keep the JCalG1 as the default but calling a function sets a new algorithm to ZIP (or others?)

How's that for a compromise? Now, if we can only get Fred to agree...

hmm i think it sounds like a good idea!

The zip password is weak and some programs dont even need to bruteforce, they just remove it.

but the SetPackAlgorithm() is a very good idea, if fred want to include it. Fred?

PureBasic Forums - English

[Implemented] Packer functions on Linux

[Implemented] Packer functions on Linux

Zip ?

ZIP packer

Cross-platform packer function AND files

packer zip lib

Re: packer zip lib