derosa@motcid.UUCP (John DeRosa) (01/04/91)
Now, don't get me wrong, I like compactor, especially because it is fast and creates those lovely self extracting archives that I personally love to send to all my friends (it makes their life so much easier). My problem is with people using Compactor files for the info-mac archives. 1) Compactor can't do binhex - This means that everytime that I retrieve a file from the archives (and I retrieve a lot of them), I need to use one program to un-binhex, exit that program and then double click on the Compactor .sea file. If I run into a plain .cpt files I need to run Compactor itself, twice as bad. Which leads to..... 2) Compactor .sea files don't let you pick where you want the resulting files to be un-compacted to. You end up with files in places that you don't want them. How much extra space would it cost in the .sea file to add the code to bring up the save as dialog box? It is just a system call, correct? I admit my ignorance here, it may very well be too difficult to implement). Solution ======== Use Stuffit Classic to stuff and then binhex the file. This optimizes the process by allowing one program to do everything, albeit multiple steps in this one program. It amazes me that the people who are going through the trouble of sending files to the archives (God bless them all), don't notice that it took them multiple applications to put the file in a form that was uploadable. My Procedure ============ The way I use Stuffit Deluxe to "decode" my downloaded archive files, is to open the binhex file (cmd-h). This will bring up a dialog box that allows me to BOTH decode the binhex and automatically open the resulting archive (.sit file). Thus with a few operations in ONE application, I can produce the required files. Unfortunately, I end up with some debris, .hqx and .sit files that I have to trash. Also, by using Stuffit, I get the opportunity to indicate where the resulting files should go. BTW, I have seveal folders set up to help this operation..... hqx.files folder | | | V | old.files folder (storage) V sit.files folder (to the trash later) | V finished.files folder | | | | | | | +> empty folder 1 | | +> empty folder 2 | +> empty folder 3 | . +> empty folder n All in all, this goes fairly easily until I run into a .cpt or .sea file or one of those pesky Lpunch files. Ultimate Solution ================= How about some mad person of a programmer making a single program that will, in one easy step, create the compressed and binhex'd file for uploading. The same program would also be able to un-binhex and decompress the file in one easy step. IT WOULD BECOME THE WORLDWIDE STANDARD AND MAKE THE AUTHOR MANY, MANY $$$$ (IMHO). Thanks for listening, John -- = John DeRosa, Motorola, Inc, Cellular Infrastructure Group = = e-mail: ...uunet!motcid!derosaj, motcid!derosaj@uunet.uu.net = = Applelink: N1111 = =I do not hold by employer responsible for any information in this message =
3XMQGAA@CMUVM.BITNET (Sari Khoury) (01/04/91)
In article <5490@crystal9.UUCP>, derosa@motcid.UUCP (John DeRosa) says: > >because it is fast and creates those lovely self >extracting archives that I personally love to send >to all my friends (it makes their life so much >easier). >My problem is with people using Compactor files >for the info-mac archives. > >1) Compactor can't do binhex - This means that >everytime that I retrieve a file from the archives >(and I retrieve a lot of them), I need to >use one program to un-binhex, exit that program >and then double click on the Compactor .sea >file. If I run into a plain .cpt files >I need to run Compactor itself, twice as bad. The combination of the BinHqx DA, and Compactor is great. BinHqx is MUCH faster than stuffit Encode/Decode and it splits and joins text files just as fast. So Compactor is still more convenient than Stuffit if you use this Combinat ion. According to Bill Goodman (author) he will be adding better file segmentin g , and a new Binhex feature in the next version. >Which leads to..... > >2) Compactor .sea files don't let you pick >where you want the resulting files to be >un-compacted to. You end up with files >in places that you don't want them. > True, maybe he'll correct that. But all you have to do is open the .sea file under compactor and then you can direct it to whatever destination you want. And the .sea only takes up about 10K more than a regular .cpt file. >How much extra space >would it cost in the .sea file to add the >code to bring up the save as dialog box? >It is just a system call, correct? >I admit my ignorance here, it may very well be too >difficult to implement). Not much. >Thanks for listening, John Anytime. >-- >= John DeRosa, Motorola, Inc, Cellular Infrastructure Group = >= e-mail: ...uunet!motcid!derosaj, motcid!derosaj@uunet.uu.net = >= Applelink: N1111 = >=I do not hold by employer responsible for any information in this message = ------------------------------------------------------------------------- Sari Khoury BITNET : 3XMQGAA@CMUVM Art Department Internet: skhoury@postcard.engin.umich.edu Central Michigan University UUCP : "psuvax1"!cmuvm.bitnet!3xmqgaa Mt. Pleasant, MI 48859 USA
white@ucs.sfu.ca (Steve White) (01/04/91)
I don't like to un-binhex on the Mac side. On a 9600 baud modem, it's worthwhile to un-binhex with mcvert on my unix machine and then use zmodem to upload. So for unix users, the un-binhexing ability of StuffIt is not crucial. Concerning the switching of applications: If you're running MultiFinder, it's certainly not a heck of a lot more work to launch binhex and Compactor, and if you're NOT running MultiFinder, you can always un-binhex the whole lot and then un-compact them all. One switch per batch.
lee@quincy.cs.umass.edu (Peter Lee) (01/05/91)
In article <5490@crystal9.UUCP> derosa@motcid.UUCP (John DeRosa) writes: Path: dime!umvlsi!m2c!bu.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!motcid!derosa From: derosa@motcid.UUCP (John DeRosa) Newsgroups: comp.sys.mac.apps Date: 3 Jan 91 21:18:57 GMT Distribution: comp Organization: Motorola Inc., Cellular Infrastructure Div., Arlington Heights, IL Lines: 109 Now, don't get me wrong, I like compactor, especially because it is fast and creates those lovely self extracting archives that I personally love to send to all my friends (it makes their life so much easier). My problem is with people using Compactor files for the info-mac archives. 1) Compactor can't do binhex - This means that everytime that I retrieve a file from the archives (and I retrieve a lot of them), I need to use one program to un-binhex, exit that program and then double click on the Compactor .sea file. If I run into a plain .cpt files I need to run Compactor itself, twice as bad. Which leads to..... 2) Compactor .sea files don't let you pick where you want the resulting files to be un-compacted to. You end up with files in places that you don't want them. How much extra space would it cost in the .sea file to add the code to bring up the save as dialog box? It is just a system call, correct? I admit my ignorance here, it may very well be too difficult to implement). ... Thanks for listening, John -- = John DeRosa, Motorola, Inc, Cellular Infrastructure Group = = e-mail: ...uunet!motcid!derosaj, motcid!derosaj@uunet.uu.net = = Applelink: N1111 = =I do not hold by employer responsible for any information in this message = My biggest problem with self-extracting archives of any form is that I need to override GateKeeper to use them. Anything that forces me to override my virus checker completely is something I will think twice about using. It's especially troubling when, as another poster pointed out, the self-extracting archive itself might be infected! For the time being, I launch Extractor manually when I want to expand one of it's archives, but I find Stuffit Deluxe's "Magic Menu" far more convenient, and it works just fine with Stuffit 1.5.1 archives... -- |- Peter E. Lee, Staff Assistant -| | Software Development Lab at the University of Massachusetts at Amherst | | lee@cs.umass.edu or Fuligin@umass.bitnet or (413) 256-1329 | "When you expect whistles, it's flutes. When you expect flutes, it's whistles"
bose@milton.u.washington.edu (Rob Olsen) (01/07/91)
I think the best way to do it would be to Decode Binhex on the other side then send it through with MacBinary][. I have xbin in my dir but it decode into three files. I would like to see it done in one file. Does anyone have the source code for DeBinhex for unix? -From one of the Insanes.
derosa@motcid.UUCP (John DeRosa) (01/08/91)
lee@quincy.cs.umass.edu (Peter Lee) writes: >My biggest problem with self-extracting archives of any form is that I need to >override GateKeeper to use them. Anything that forces me to override my virus >checker completely is something I will think twice about using. It's >especially troubling when, as another poster pointed out, the self-extracting >archive itself might be infected! I receive an extract 2-5 archive files a day from the Info-Mac Archives and I have NEVER, repeat NEVER, gotten an infection from any of them. I use disinfectant 2.4, which does not complain when running .sea files. It is available from the archives at VIRUS/DISINFECTANT-24.HQX. Enjoy. -- = John DeRosa, Motorola, Inc, Cellular Infrastructure Group = = e-mail: ...uunet!motcid!derosaj, motcid!derosaj@uunet.uu.net = = Applelink: N1111 = =I do not hold by employer responsible for any information in this message =
elliott@veronica.cs.wisc.edu (James Elliott) (01/09/91)
My main problem with compactor, at least as I understand the situation, is that the archive format is "proprietary". Too many people are still falling into the power-trip trap of keeping information secret. Granted it gives them more control over things that they create, but it ends up being significantly less useful to the rest of the world. (I believe that Stuffit Deluxe has the same problem). This means that any features that I might want to see implemented with respect to compactor archives will have to be implemented by the author or some appointed person given the arcane knowledge necessary. It won't be able to be implemented by, say, me. Or the author of MacTree (it'd be nice to have a viewer for seeing the contents of compactor archives, but we can't write one since we can't read them.) Open software and open standards are very important, and they're the wave of the future. To the extent that they continue to catch on with Mac developers, the Mac will remain a viable platform. -- Jim Elliott "Like a bridge he'll come between us, not a wall" elliott@veronica.cs.wisc.edu
barleben@sun1.ruf.uni-freiburg.de (Friedrich Barleben) (01/09/91)
bose@milton.u.washington.edu (Rob Olsen) writes: >I think the best way to do it would be to Decode Binhex on the other side then >send it through with MacBinary][. I have xbin in my dir but it decode into >three files. I would like to see it done in one file. Does anyone have the xbin -b filename.hqx results in one nice Filename.bin Fiete Barleben >source code for DeBinhex for unix? > -From one of the Insanes. -- mail: barleben@sun1.ruf.uni-freiburg.de | Fiete Barleben phone: +49-761-203-3410 or +49-761-702503 | Institut fuer Biologie III fax: +49-761-203-2745 or +49-761-702503 | Schaenzlestrasse 1 BTX: *0761702503# | D-7800 Freiburg
daven@svc.portal.com (01/10/91)
In article <1991Jan8.220654.858@spool.cs.wisc.edu> elliott@veronica.cs.wisc.edu (James Elliott) writes: >My main problem with compactor, at least as I understand the >situation, is that the archive format is "proprietary". Too many >people are still falling into the power-trip trap of keeping >information secret. Granted it gives them more control over things >that they create, but it ends up being significantly less useful to >the rest of the world. (I believe that Stuffit Deluxe has the same >problem). Actually, StuffIt Deluxe falls between an open format and a closed one. The Aladdin people will disclose the format to anyone they feel has good reason to know. With the MAUG group on CompuServe they have placed this information in escrow. The Aladdin people have also disclosed their viewer, translator, and optimizer technology to various entities as well. Compactor's author has steadfastly refused to devulge a iota of informa- tion. -- ------------------------------------------------------------------------------- Dave Newman | daven@svc.portal.com | AppleLink: D0025 Sofware Ventures Corp. | AOL: MicroPhone | CIS: 76004,2161 Berkeley, CA 94705 | WELL: tinman@well.sf.ca.us | (415) 644-3232
jimb@silvlis.com (Jim Budler) (01/10/91)
In article <1991Jan9.193732.13640@svc.portal.com> daven@svc.portal.com writes: >In article <1991Jan8.220654.858@spool.cs.wisc.edu> elliott@veronica.cs.wisc.edu (James Elliott) writes: >>My main problem with compactor, at least as I understand the >>situation, is that the archive format is "proprietary". Too many [...] >Actually, StuffIt Deluxe falls between an open format and a closed one. >The Aladdin people will disclose the format to anyone they feel has >good reason to know. With the MAUG group on CompuServe they have placed >this information in escrow. The Aladdin people have also disclosed their >viewer, translator, and optimizer technology to various entities as well. > >Compactor's author has steadfastly refused to devulge a iota of informa- >tion. Wrong! Compactor's author agreed to putting his source code in escrow. What he and Compuserve could not agree to were the conditions under which the source code would be released from escrow. I might not have responded were it not for the use of modifiers like "steadfastly refused" and "an iota" when refering to Compactor's author, and statements like "will disclose the format to anyone they feel..." when refering to Stuffit Deluxe's publishers. Reality is we know *nothing* of the conditions of escrow involved with Compuserve. We know nothing of the motives of the individuals. One scenario could easily be along the line of: "Party #1, believing their technology has a market life of 2 years finds no objection to an escrow trigger X" "Party #2, believing his technology has a market life of 5 years finds escrow trigger X objectionable." Compuserve apparently felt he had demonstrated good faith in whatever their private negotiations were, as they allow his format. Reality is, as far as Usenet must be concerned, there is no significant difference between these two proprietary formats. If the escrow with Compuserve is triggered, Usenet may not learn anything of the format, someone at Compuserve might incorporate the format in a program which might be available on Compuserve or commercially. It may remain proprietary, not public domain. All that may change is the proprietor. The question on Usenet should not be "which proprietary format do we use?", it should remain "do we insist on public domain formats". Personally, since all the parties involved provide freeware dearchivers, I don't care. I have a nice fast Mac to de-archive with, and I pay my own $ for the link to my Unix machine, so I prefer to send the compressed data across that link. I understand to a point with those who would rather de-archive on their 29 Mip Sparcstation and download it to a Mac over a company or University provided network. But not to the point where I must accept a 30% increase in my download $ to save them some time. And to those who earlier in this thread asked why we didn't just implement the Usenet public domain Compress, Stuffit 1.5.1 is exactly that, plus. During stuff it selectively tries Run Length Encoding, Huffman Encoding, and LZW Encoding, using three known algorythms. The LZW in question is the Usenet Compress. That's how unsit works, when the header says its RLE or Huffman, it decodes it, when the header says it's LZW, it pipes it through compress. "Read the Source, Luke." Or just read the README. The following paragraph is from the README included with the unsit source: "This program opens a pipe to the "compress" program for doing the uncompression of some of the files in the archive. Most Unix sites probably already have "compress". If not, it can be found in the comp.sources.unix archives." In other words, Compress is not as good as Stuffit Deluxe or Compactor. In still other words, using existing public domain formats instead of these proprietary formats will cost 20-30% size. Back to my original reasoning: I will reluctantly accept proprietary vs. public domain arguments. Reluctant because the arguments are usually someone's convenience vs. my dollars. I do not find arguments between proprietary formats which are not based upon size or speed or level of customer support acceptable. I do not believe "they let <someone> escrow their source code or format" to be a valid argument. Honestly, even if they let *me* escrow their source code or format it wouldn't be a valid argument. I might find it convenient, it's true. The previous paragraph presupposes that the format in question has a freeware de-archive. If you quote my arguments, please be sure to include this statement. All the formats in question I am aware of, except maybe Diamond, which actually I am not very aware of, have such a freeware de-archiver. Perhaps I should be specific? Stuffit Deluxe has a partial de-archiver. Some optimized files require the shareware Stuffit Classic. Compactor has the freeware Extractor. Disk Doubler has a freeware expander. 'Nuff said. jim -- __ __ / o / Jim Budler jimb@silvlis.com | Proud / / /\/\ /__ Silvar-Lisco, Inc. +1.408.991.6115 | MacIIsi /__/ / / / /__/ 703 E. Evelyn Ave. Sunnyvale, Ca. 94086 | owner
yee@osf.org (Michael K. Yee) (01/11/91)
In article <1991Jan10.042931.26762@silvlis.com> jimb@silvlis.com (Jim Budler) writes: |> In article <1991Jan9.193732.13640@svc.portal.com> daven@svc.portal.com writes: |> >In article <1991Jan8.220654.858@spool.cs.wisc.edu> elliott@veronica.cs.wisc.edu (James Elliott) writes: |> >>My main problem with compactor, at least as I understand the |> >>situation, is that the archive format is "proprietary". Too many |> [...] |> >Actually, StuffIt Deluxe falls between an open format and a closed one. |> >The Aladdin people will disclose the format to anyone they feel has |> >good reason to know. With the MAUG group on CompuServe they have placed |> >this information in escrow. The Aladdin people have also disclosed their |> >viewer, translator, and optimizer technology to various entities as well. |> > |> >Compactor's author has steadfastly refused to devulge a iota of informa- |> >tion. |> If I'm not mistaken, the disk cataloging program FileList 1.4 recognizes compactor files. So the compactor format is not totally "proprietary" (i.e. other programs know about the format). =Mike -- = Michael K. Yee -- yee@osf.org or uunet!osf.org!yee -- = OSF/Motif Development = "I can't give you brains, but I can give you a diploma." -- The Wizard of OZ
typ125m@monu6.cc.monash.edu.au (John Wilkins) (01/11/91)
yee@osf.org (Michael K. Yee) writes: > If I'm not mistaken, the disk cataloging program FileList 1.4 > recognizes compactor files. So the compactor format is not totally > "proprietary" (i.e. other programs know about the format). Also the hypercard stack catstuff 2.0. So there! -- John Wilkins, Manager, Publishing & Advertising, Monash University Melbourne, Australia - Internet: john@publications.ccc.monash.edu.au Disclaimer: IF Standard(disclaimer) THEN Applies(disclaimer) ELSIF Nonstandard(disclaimer) THEN PROBABLY (Applies(disclaimer)) ENDIF
johnston@oscar.ccm.udel.edu (01/11/91)
In article <1991Jan10.225126.4155@monu6.cc.monash.edu.au>, typ125m@monu6.cc.monash.edu.au (John Wilkins) writes... >yee@osf.org (Michael K. Yee) writes: >> If I'm not mistaken, the disk cataloging program FileList 1.4 >> recognizes compactor files. So the compactor format is not totally >> "proprietary" (i.e. other programs know about the format). >Also the hypercard stack catstuff 2.0. So there! So does the Finder. There is a difference between reading the the type and creator info from the header of a file, and reading the file. That is not the point here. It is the data structure of the rest of a Compactor file that is proprietary. FileList and CatStuff do not recognize the Compactor data format. -- Bill (johnston@oscar.ccm.udel.edu)
rterry@hpcuhc.cup.hp.com (Ray Terry) (01/12/91)
Many of the reasons expressed in this thread for not using Compactor 1.21 are currently being addressed in v1.3. Compactor 1.3 is currently in beta testing and adds among other things, binhexing, segmenting, segmented sea-s, user interface improvements, etc... I think everybody will like the improvements. Ray
yee@osf.org (Michael K. Yee) (01/12/91)
In article <41386@nigel.ee.udel.edu> johnston@oscar.ccm.udel.edu writes: |> In article <1991Jan10.225126.4155@monu6.cc.monash.edu.au>, typ125m@monu6.cc.monash.edu.au (John Wilkins) writes... |> >yee@osf.org (Michael K. Yee) writes: |> >> If I'm not mistaken, the disk cataloging program FileList 1.4 |> >> recognizes compactor files. So the compactor format is not totally |> >> "proprietary" (i.e. other programs know about the format). |> >Also the hypercard stack catstuff 2.0. So there! |> |> So does the Finder. |> |> There is a difference between reading the the type and creator info from |> the header of a file, and reading the file. That is not the point here. |> It is the data structure of the rest of a Compactor file that is proprietary. |> FileList and CatStuff do not recognize the Compactor data format. |> |> -- Bill (johnston@oscar.ccm.udel.edu) You've missed my meaning. FileList 1.4 recognizes enough of the stuffit and compactor data format to get the list of files in the archive. This is a neat feature, because you can keep your files in compressed format and still get a listing of the FILES stored on your disks. I haven't tried FileList 1.4 yet so I may be totally off base. :-) =Mike -- = Michael K. Yee -- yee@osf.org or uunet!osf.org!yee -- = OSF/Motif Development = "I can't give you brains, but I can give you a diploma." -- The Wizard of OZ
draphsor@elaine5.stanford.edu (Matt Rollefson) (01/12/91)
johnston@oscar.ccm.udel.edu writes: >In article <YEE.91Jan11113640@pmin7.osf.org>, yee@osf.org (Michael K. Yee) writes... >>In article <41386@nigel.ee.udel.edu> johnston@oscar.ccm.udel.edu writes: >> You've missed my meaning. FileList 1.4 recognizes enough of the >> stuffit and compactor data format to get the list of files in the >> archive. This is a neat feature, because you can keep your files in >> compressed format and still get a listing of the FILES stored on >> your disks. I haven't tried FileList 1.4 yet so I may be totally >> off base. :-) >> >Thanks also to Mr. Junio Hamano for making the same point with regard to >to FileList 1.4. A Compactor .cpt archive is all data fork ... so anything >that reads it, reads the "data format", strictly speaking. Nevertheless, >it is likely that file/folder information is stored in the file's header >along with the name, type and creator. I expect that the people who wrote >CatStuff and Filelist were able to deduce the header format in a straight- >forward way; it only makes sense that the author of Compactor would >incorporate this information in a straight-forward way. I'm sorry, you're wrong here, at least for CatStuff. It states quite clearly in the stack that the author of CatStuff asked for, and received, information about the format of Compactor archives directly from the author of Compactor, Bill Goodman. It further says that Bill Goodman was quite helpful and willing to pass on this information. I don't know if it is personal prejudice or some other reason that caused you to assume the worst as regards how the authors of these programs received the necessary information, but I suggest you find out the facts before posting 'I assume' messages. Note: This is not, strictly speaking, a flame. I would do it via e-mail, except that I believe the information in my posting (ie the corrections as to how the author of CatStuff obtained the information about Compactor's format) should be available to the net. >-- Bill (johnston@oscar.ccm.udel.edu) -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
vd09+@andrew.cmu.edu (Vincent M. Del Vecchio) (01/13/91)
draphsor@elaine5.stanford.edu (Matt Rollefson) writes: > johnston@oscar.ccm.udel.edu writes: > >forward way; it only makes sense that the author of Compactor would > >incorporate this information in a straight-forward way. > > I'm sorry, you're wrong here, at least for CatStuff. It states quite > clearly in the stack that the author of CatStuff asked for, and > received, information about the format of Compactor archives directly > from the author of Compactor, Bill Goodman... I disagree somewhat with your interpretation. I believe that Bill Goodman would be more than willing to disclose header-type information for incorporation into programs like FileList and CatStuff; this information should not be hard to deduce anyway and disclosing it doesn't give an advantage to your competitors. On the other hand, in light of what I have heard about his negotations with CompuServe, he seems to be reluctant to disclose the actual compression format with which the files in the archive are compressed or decompressed (typically, the filenames, orig. and compressed sizes, etc. of the compressed files are stored in plaintext (uncompressed) in the data fork of the archive file). Perhaps a good way to put it would be to say that the archive format is known, but the compression format is still not. Disclaimer: This is mostly speculation on my part. -Vincent Del Vecchio vd09@andrew.cmu.edu #include "stdsig.h"
draphsor@elaine5.stanford.edu (Matt Rollefson) (01/13/91)
draphsor@elaine5.stanford.edu (me) writes: >johnston@oscar.ccm.udel.edu writes: >> [Makes point about how FileList and CatStuff probably only read the >> header information for the archive, suggests that the authors of these >> programs probably deduced the format on their own.] >I'm sorry, you're wrong here, at least for CatStuff. It states quite >clearly in the stack that the author of CatStuff asked for, and >received, information about the format of Compactor archives directly >from the author of Compactor, Bill Goodman. It further says that Bill >Goodman was quite helpful and willing to pass on this information. Bill Johnston has pointed out to me that, although I was posting a message to 'set the record straight', I myself posted a misleading message. While I do say that the author of CatStuff received information 'about the format of Compactor archives' from Bill Goodman, my language may suggest that he received information which would allow him to decompress the data. To my knowledge, this is not the case. It is likely that all he received was the header information. So, Bill Johnston's point remains valid, that is that Compactor's format is not publicly accessible, nor necessarily even easily accessible; I have no information on this, as I have not attempted to get the format from Bill Goodman, nor do I know anyone who has. Just setting the record straight. >>-- Bill (johnston@oscar.ccm.udel.edu) >-- >Draphsor vo'drun-Aelf draphsor@portia.stanford.edu -- Draphsor vo'drun-Aelf draphsor@portia.stanford.edu
mididoc@peg.UUCP (01/13/91)
I thought the main aim behind archiver programs were to reduce (a) storage and (b) net-traffic. Anthing wchich does it better is good. As was previously said, Compactor and the BinHQX Da is an unbeatable combination. As for StuffIt Deluxe ... BLYECCH!!! (IMNSHO!) SI Classic is faster anyway! The only thing SI Deluxe really has going for it is JPEG - I can do it standalone anyway. There is no reason to have everything in one package, y'know ... Geoff Peters mididoc@peg.pegasus.oz.au
coolidge@cs.uiuc.edu (John Coolidge) (01/14/91)
rterry@hpcuhc.cup.hp.com (Ray Terry) writes: >Many of the reasons expressed in this thread for not using Compactor 1.21 >are currently being addressed in v1.3. Compactor 1.3 is currently in beta >testing and adds among other things, binhexing, segmenting, segmented sea-s, >user interface improvements, etc... I'd really love to have a copy to beta-test, because right now I _can't_ run Compactor 1.2.1. Why? Because I run A/UX, and Compactor doesn't work under A/UX (it crashes in the Add... command). I hope that Compactor 1.3 fixes this problem. Fortunately, self-extracting archives do work. Admittedly, A/UX is a very small segment of Compactor's audience; however, the programs that don't work under A/UX now are likely to be the ones that die under newer Systems (7? 8?) that enforce 32-bit cleanliness. --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1991 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well.
tj@pons.cis.ohio-state.edu (Todd R Johnson) (01/14/91)
In article <1991Jan13.142958.11554@sics.se> ollef@sics.se (Olle Furberg) writes: >> >>In <252200004@peg> mididoc@peg.UUCP writes: >> >>>I thought the main aim behind archiver programs were to reduce (a) >>>storage and (b) net-traffic. Anthing wchich does it better is good. >> >> You haven't understood the width of the problem yet! >>There are a lot of people who does the unpacking on non-Mac computers. >>There are PC-users who uses Mac sound files and don't have access to >>any Mac, there are also a lot of people (like me) who has special >>programs on UNIX for unpacking and filing into AUFS-archives. All this >>works great because the algorithm for StuffIt 1.5.1 is known. >> >> If the author of Compactor wrote (free) unCompactors for UNIX and >>PC-users, I would accept Compactor as a new net.standard. I wouldn't. I want a version for my Amiga as well. When a new machine comes out I want a version for it as well. >> >> It's really short-sighted to think that everybody uses archiver >>programs in the same way as you. This remark has been made by several >>people but you (and some other guys) doesn't seem to take note of it. This is exactly the reason why Stuffit and Compactor are both unacceptable. I want to be able to create and extract archives on my Unix account, my Mac, and my Amiga. When I first got my Mac I was amazed that the most common compression program did not (and still does not) have a unix version. To upload information I have to use stuffit. To download information I have to use Zoo. I would personally be happy with a complete mac implementation of Zoo or lharc, even though these may produce archives a few percent larger than Compactor or Stuffit. I also have zoo on my Amiga. Communication with Unix boxes is much easier on the Amiga because of the common compression and text formats. Archival programs must be completely open so that they are available for as many machines as possible. There should also be at least one free no-frills version for each machine. Hopefully, the designers of Stuffit and Compactor will grow up and release their formats. Until then, I'd urge people not to support them. ---Todd -- Todd R. Johnson tj@cis.ohio-state.edu Laboratory for AI Research The Ohio State University
jimb@silvlis.com (Jim Budler) (01/14/91)
In article <1991Jan13.142958.11554@sics.se> ollef@sics.se (Olle Furberg) writes: > >In <252200004@peg> mididoc@peg.UUCP writes: > >>I thought the main aim behind archiver programs were to reduce (a) >>storage and (b) net-traffic. Anthing wchich does it better is good. > > You haven't understood the width of the problem yet! >There are a lot of people who does the unpacking on non-Mac computers. > > It's really short-sighted to think that everybody uses archiver >programs in the same way as you. This remark has been made by several >people but you (and some other guys) doesn't seem to take note of it. > I took note of it. I even replied that I didn't think that the ability of people using their University and Company supplied networks and computers efficiently mandated my paying 20-30% more of *my* money to download over a phone line I pay for.. And I've never gotten a response to my question of why I should pay 20-30% higher download bills. I've got lots of responses. They almost universally list the benefits *they* get from the use of a public format. They have *never* mentioned why *I* should pay for it. Not even in letters and posts responding to my statements. The main purpose of an archiver is to reduce storage space and download time. Stuffit 1.5.1 no longer does either of those adequately. If you want us to stay with a publicly accessible format, maybe you should make an effort to insure that publicly accessible formats are efficient. Stuffit 1.5.1 is no longer efficient. A simple truth. > /Olle jim -- __ __ / o / Jim Budler jimb@silvlis.com | Proud / / /\/\ /__ Silvar-Lisco, Inc. +1.408.991.6115 | MacIIsi /__/ / / / /__/ 703 E. Evelyn Ave. Sunnyvale, Ca. 94086 | owner
rxcjm@minyos.xx.rmit.oz.au (John Mazzocchi) (01/14/91)
tj@pons.cis.ohio-state.edu (Todd R Johnson) writes: >stuffit. To download information I have to use Zoo. I would >personally be happy with a complete mac implementation of Zoo or >lharc, even though these may produce archives a few percent larger There ARE Mac implementations of lharc and zoo. (MacArc, ArcMac, MacZoo)=> try sumex-aim.stanford.edu. -- + John Mazzocchi + "The mind is not a vessel to be filled, + + Melbourne, Victoria + but a fire to be lighted" - Plutarch + + Australia + + rxcjm@minyos.xx.rmit.oz.au +
jlee@watnow.waterloo.edu (Johnny Lee) (01/15/91)
In article <sbXsa0600aw356gogZ@andrew.cmu.edu> vd09+@andrew.cmu.edu (Vincent M. Del Vecchio) writes: > >I disagree somewhat with your interpretation. I believe that Bill Goodman >would be more than willing to disclose header-type information for >incorporation into programs like FileList and CatStuff; this information should >not be hard to deduce anyway and disclosing it doesn't give an advantage to >your competitors. On the other hand, in light of what I have heard about his It wasn't that hard. One just needs to get a decent sampling of Compactor archives and one doesn't have to be Sherlock Holmes to deduce 99% of all the fields. Actually, the information that Mr. Goodman sends out doesn't seem to reveal the Compactor-specific information, i.e. Compressed lengths, location of compressed data. >negotations with CompuServe, he seems to be reluctant to disclose the actual >compression format with which the files in the archive are compressed or >decompressed (typically, the filenames, orig. and compressed sizes, etc. of the >compressed files are stored in plaintext (uncompressed) in the data fork of the >archive file). Perhaps a good way to put it would be to say that the archive >format is known, but the compression format is still not. > From a preliminary look at the resulting archives, Compactor seems to use a couple of types of compression including run-length encoding. I've never heard any stories about reverse-engineering a compressed file, but it should be nice late-night fodder. Compactor is a nice Mac archiving program, but I don't use it because I talk more to/thru Unix boxes than Macs. Besides, for real compression, COMIC beats most with one hand tied behind its back (though you'll have to wait a long time). Johnny Lee jlee@watnow.waterloo.edu