Qbasicnews.com
July 18, 2019, 08:20:48 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: 1 [2]
  Print  
Author Topic: zip in qbasic  (Read 5500 times)
LooseCaboose
I hold this place together
*****
Posts: 981



« Reply #15 on: October 06, 2006, 10:26:42 PM »

Quote from: "cha0s"

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.

Quote from: "cha0s"

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.

Quote from: "na_th_an"

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.
Logged

esus saves.... Passes to Moses, shoots, he scores!
Anonymous
Guest
« Reply #16 on: October 07, 2006, 12:40:45 AM »

Quote from: "LooseCaboose"
Quote from: "cha0s"

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.
Logged
LooseCaboose
I hold this place together
*****
Posts: 981



« Reply #17 on: October 07, 2006, 01:32:07 AM »

Quote from: "cha0s"

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 ;-)

Quote from: "cha0s"

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.
Logged

esus saves.... Passes to Moses, shoots, he scores!
Anonymous
Guest
« Reply #18 on: October 07, 2006, 05:56:55 AM »

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.
Logged
Pages: 1 [2]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!