Page 1 of 1
[Implemented] Packer functions on Linux
Posted: Mon Mar 22, 2004 6:16 pm
by Num3
Would be nice the packer lib worked under linux too

Posted: Fri Apr 02, 2004 11:13 pm
by thefool
yup
Zip ?
Posted: Sat Apr 03, 2004 12:33 am
by USCode
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.

Posted: Sat Apr 03, 2004 1:01 am
by Shannara
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.
Posted: Sat Apr 03, 2004 1:38 am
by freak
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
Posted: Sat Apr 03, 2004 2:48 am
by Shannara
agh! my eyes are gone, nooo!! I was thinking of vbin, not packer, hehe my bad.
Posted: Sat Apr 03, 2004 2:51 am
by PolyVector
ZIP packer
Posted: Sat Apr 03, 2004 7:13 am
by USCode
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.
Posted: Sat Apr 03, 2004 10:58 am
by thefool
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.
Cross-platform packer function AND files
Posted: Sat Apr 03, 2004 10:26 pm
by USCode
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...
Posted: Sat Apr 03, 2004 10:30 pm
by thefool
it was menshioned as a good thing. so users just dont go extracting important files and more. But what about AddZipPackFile() and openZipPack()
Posted: Sat Apr 03, 2004 11:23 pm
by Shannara
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...
Posted: Sun Apr 04, 2004 12:04 am
by thefool
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.
packer zip lib
Posted: Sun Apr 04, 2004 12:42 am
by USCode
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...

Re: packer zip lib
Posted: Sun Apr 04, 2004 9:56 am
by thefool
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?