maxc1553@ucselx.sdsu.edu (InnerTangent - human1) (04/02/91)
Awhile ago, I posted an complete message asking about a packing program for Macintosh, no one responded. (Packing is to compress an executable file into about 50% of it's original size, but remain executable; This is similar to StuffIT and Arc, but the final product from packing is executable) IBM has it. Amiga has it. Atari has it; why even Commodore 64 has these sort of program. The advantage is obvious: It saves alot of disk spaces on your harddrive. I'm suprised that Macs doesn't even have this kind of programs. "No one from Mac worlds ever thought of it?", I ask. Peace. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + AAllll tthhoossee mmoommeennttss wwiillll bbee lloosstt iinn ttiimmee,, lliikkee tteeaarrss iinn tthhee rraaiinn.. + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + (**) Maxc1553@ucselx.sdsu.edu (**) Billy - IInnnneerrTTaannggeenntt - Human1 +
jcav@quads.uchicago.edu (john cavallino) (04/02/91)
In article <1991Apr1.221555.1836@ucselx.sdsu.edu> maxc1553@ucselx.sdsu.edu (InnerTangent - human1) writes: >Awhile ago, I posted an complete message asking about a packing program for >Macintosh, no one responded. (Packing is to compress an executable file into >about 50% of it's original size, but remain executable; This is similar to >StuffIT and Arc, but the final product from packing is executable) Isn't this the sort of thing that DiskDoubler does? (only with all files, not just executables) -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 "Opinions, my boy. Just opinions" | Telephone: 312-702-6900
epayne@x102a.harris-atd.com (payne edward 01471) (04/02/91)
There is a shareware program calle AutoCompress (I believe). It's really neat except for one thing: it's slow. I'm using an SE/30. I'd imagine that a Plus would be excrutiatingly slow. I don't want to give it a bad rap it was just to slow for me. You might be able to find it at Sumex. Later! Ed ------------------------------------------------------------------------------- Ed Payne | Harris, GASD | If I only had more than epayne@x102a.ess.harris.com | Melbourne, Fl | 3 lines....
Aron_Fingers_Nelson@cup.portal.com (04/03/91)
Why don't you post some examples of the IBM/ATARI world pack program that compresses files %50 smaller yet still allow them to be run as executable I have an IBM clone and I still have no idea of what you're talking about. If you're talking about ZIP->EXE kind of files that auto-unpak themselves then the Macintosh does have it in the form of Compactor and Auto-Unstuffit. If you are talking about something that will actually squish an Executable to %50 of it's size while still remaining functional w/o any TSR's or anything else, I have never heard or seen it. aron_nelson@cup.portal.com
andrew@jhereg.osa.com (Andrew C. Esh) (04/04/91)
Yes, as a matter of fact I think we originated the idea. AutoUnstuffit Shell came packed with one of the early versions of Stuffit. The first time I saw it was in 1988, I believe. It is a Stuffit archive that has a small application in the recourse fork (the stuffed files are in the data fork) which, when double clicked, unstuffs all the files. Many software distributors use it to compress files onto fewer distribution disks. Steve Jasik, author of "The Debugger" uses another auto decopressor to ship his stuff too. I forget the name of that one, but I think it works with compactor files. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Minneapolis, MN 55416-1528 So much System, (612) 525-0000 so little CPU time...
231b3679@fergvax.unl.edu (Mike Gleason) (04/05/91)
andrew@jhereg.osa.com (Andrew C. Esh) writes: >Yes, as a matter of fact I think we originated the idea. AutoUnstuffit >Shell came packed with one of the early versions of Stuffit. The first time >I saw it was in 1988, I believe. It is a Stuffit archive that has a small >application in the recourse fork (the stuffed files are in the data fork) >which, when double clicked, unstuffs all the files. Many software >distributors use it to compress files onto fewer distribution disks. Steve >Jasik, author of "The Debugger" uses another auto decopressor to ship his >stuff too. I forget the name of that one, but I think it works with >compactor files. I don't remember the original post, but I think the poster wanted to know if there was a program that would keep itself compressed, and when run it would decompress itself to memory. There is a program for the Amiga called Power Packer that does this. My friend keeps his little-used unZoo program Power Packed. Then when he runs unZoo, it transparently decompresses itself, and runs. When he quits, it is back to it's compressed state. I guess Disk Doubler kind of does this, but I doubt you could use a program compressed with DD on another machine without the DD INIT. I've written a little doohickey that compresses resoruces (look for it in about a month on Sumex, it'll be free, PD, and with source code), and I was wondering if it were possible to do some sort of power packing on the mac. I imagine it would have one normal CODE resource which would decompress the rest. The big problem I see with something like this, is if the user would want to go in and customize something with ResEdit, and everything would be compressed. I don't have System 7 yet, which is supposed to have compressed resources, which will probably obselete my little program and Ben Haller's LZWRez anyway. Perhaps the "important" programmers who get the 7.0 betas could fill us in on how this is done (is everything compressed, or just things like PICTs? how efficient is it?). _mike gleason >-- >Andrew C. Esh andrew@osa.com >Open Systems Architects, Inc. >Minneapolis, MN 55416-1528 So much System, >(612) 525-0000 so little CPU time...
boortz@sics.se (Kent Boortz) (04/06/91)
Yes, self extracting archives is not the same as compressed executable files. I have tried lzexe on MSDOS. I run lzexe on a file foo.exe to compress it and add unpacking code to it. The new application, foo.exe, will to the user work like the old one, with a very small delay at startup. Programs that patch this code will not work of cause (many msdos programs do like this because there is nothing like resources in an msdos executable file). This is close to the self extracting archives that is created by Compactor but with some differences: - Lzexe compresses only one executable file - The file is executed after unpacking - The compacted file will not look the same, another Icon, info etc. The main reason this is not done by any of the mac compression program authors I think is that all decompression programs that I know of are slow (or is it msdos programs that are small, I don't know). The delay starting a compressed version of PageMaker or Word will not be acceptable. Am I wrong? Is not packed resources part of sys 7? Then the problem is solved is it not? If Apple gives us an small application that change the resource attributes and compresses/decompresses resources in an application then the resource manager do the rest for us under runtime. I will be a little strange discussing how fast an application run after that. "My application XX is not that slow, what resources did you pack?" ;-) -- Kent Boortz boortz@sics.se
lsr@Apple.COM (Larry Rosenstein) (04/09/91)
In article <1991Apr6.115308.27161@sics.se> boortz@sics.se (Kent Boortz) writes: > >Yes, self extracting archives is not the same as compressed executable >files. I have tried lzexe on MSDOS. I run lzexe on a file foo.exe to >compress it and add unpacking code to it. You could do this on the Mac as well. You would simply compress each CODE resource and change the program entry point to a bit of code that decompressed the resources before using them. >msdos programs that are small, I don't know). The delay starting a compressed >version of PageMaker or Word will not be acceptable. Am I wrong? Compression programs on the Mac compress everything. If you compress individual resources then the decompression time would be spread out. (On the other hand, you have to decompress the resource each time it's brought in.) Compressing resources might even speed up program execution, depending on the relative speeds of the disk and CPU. If the CPU is very fast relative to the disk, then the time you save in disk I/O (by loading a smaller compressed resource) will be more than the time required to decompress it in memory. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
minich@unx2.ucc.okstate.edu (Robert Minich) (04/09/91)
boortz@sics.se (Kent Boortz) writes: | Yes, self extracting archives is not the same as compressed executable | files. I have tried lzexe on MSDOS. I run lzexe on a file foo.exe to | compress it and add unpacking code to it. by lsr@Apple.COM (Larry Rosenstein): # You could do this on the Mac as well. You would simply compress each CODE # resource and change the program entry point to a bit of code that # decompressed the resources before using them. | msdos programs that are small, I don't know). The delay starting a compressed | version of PageMaker or Word will not be acceptable. Am I wrong? # Compression programs on the Mac compress everything. If you compress # individual resources then the decompression time would be spread out. (On # the other hand, you have to decompress the resource each time it's # brought in.) # # Compressing resources might even speed up program execution, depending on # the relative speeds of the disk and CPU. If the CPU is very fast relative # to the disk, then the time you save in disk I/O (by loading a smaller # compressed resource) will be more than the time required to decompress # it in memory. How about this: decompress resources on demand but use a temp file to save the uncompressed things when you need more memory. This way large items will only cause longer delay than necessary upon their first use. Tie the swap out routine to the GrowZone function. -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| "I'm not discouraging others from using |=(___)= | minich@d.cs.okstate.edu | their power of the pen, but mine will | U | - "Ackphtth" | continue to do the crossword." M. Ho