zip in qbasic

[Anonymous]

Ok if you say so.

*****

not only me =)

Results 1 - 10 of about 1,510,000 for pkzip.
Results 1 - 10 of about 10,200,000 for zlib.

[Moneo]

Ok if you say so.

*****

not only me =)

Results 1 - 10 of about 1,510,000 for pkzip.
Results 1 - 10 of about 10,200,000 for zlib.

Using the same yardstick..... 22,200,000 for winzip, son of pkzip.

*****

[na_th_an]

Insert here what I said before. Risky and unsecure. Someone could do really nasty stuff just replacing a file.

[Anonymous]

ok, you're right, pkzip is a dinosaur. but for within applications, zlib is one of the golden standards, trust me. another one is called gzip, the compression of choice for linux.

winzip doesn't have an API to do thins like compress to/from memory, it's all file based. what if you don't have file modification priviledges on the host computer? hehe...

Results 1 - 10 of about 132,000,000 for gzip.

;P

[yetifoot]

Results 1 - 10 of about 132,000,000 for gzip.

;P

OMG THE WINNARR

Even with zlib, the security issue or bugginess issue comes into play. If you use zlib.dll, then anyone could replace that. If you statically link zlib, then your program may be prone to any bugs discovered in zlib. So really there are no winners.

[LooseCaboose]

winzip doesn't have an API to do thins like compress to/from memory, it's all file based.

Not winzip/pkzip specifically but API's do exist for the compression routines used. pkzips compressions is equivalent to tar + compress on Unix systems.

what if you don't have file modification priviledges on the host computer? hehe...

Then you can't open it with write access with in another program regardless of whether you are using a library or an external program. You could setuid your application, but that introduces potential security flaws.

Insert here what I said before. Risky and unsecure. Someone could do really nasty stuff just replacing a file.

In a closed server environment Moneo's approach is probably fine and I think, more widely used that you may anticipate. Remember that somebody clever can also replace a dynamic library with something that does nasty stuff too.

You can't be too reliant on Googles page counts either, they are just estimates. It possible to get wierd results like: results 1-3 of about 500.

[Anonymous]

what if you don't have file modification priviledges on the host computer? hehe...

Then you can't open it with write access with in another program regardless of whether you are using a library or an external program. You could setuid your application, but that introduces potential security flaws.

I know you're one of those ppl who are never wrong but this doesn't make any sense. If you use winzip to unzip a file, temporary files HAVE to be made before they can be accessed. Not so in zLib. You made a completely moot point.

And fact the zLib and gzip are so widespread is sort of encouraging in that, lots of bugs have already been found and killed.

I wasn't even really concerned with security. Just utility. If a routine can't write to/from memory instead of only a file, it wasn't abstracted enough.

[LooseCaboose]

I know you're one of those ppl who are never wrong

Im often wrong, and will happily admit to it when I am. Nobody is infallable ;-)

but this doesn't make any sense. If you use winzip to unzip a file, temporary files HAVE to be made before they can be accessed.

I (mis)interpretted your statement to mean that if you don't have access (ie read permissions) to a file then you can't unzip it with winzip. I was pointing out that while this is true, if this is the case, then you wouldn't be able to unzip the file using a library either. You are correct that if the external application needs to write temporary files and you don't have permission to then you are pretty much out of luck.

External programs do not have to create temporary files though. Im not sure how winzip deals with this but many Unix programs for example (including tar and compress) can work as filters, reading from stdin and writing to stdout. The output of an external program can be sent to another process (via a pipe for example) without need for any temporary files to be created.

My point was that although libraries such as zlib are no readily available, and in many cases a better choice, a number of systems still use the approach discussed by Moneo.

[Anonymous]

Yeah, I suppose it's like 32/64 bit =). The 64-bit technology is superior (in every case I can think of...), but since 32 was the standard during a time when a lot of 'foundational' software was built, sometimes you have to accomodate that.