rico@oscvax.UUCP (01/12/87)
In article <5090@amdahl.UUCP> kim@amdahl.UUCP writes: > ... [lots of interesting stuff] ... >There are some other possible problems in using either ARC or Compress. >Compress is usually compiled in 12-bit mode for use on micros due to >memory size limitations. On UNIX(R) boxes like VAXen (and Amdahl's :-) ), >Compress is compiled for 16-bit compression mode. I do not believe you >can uncompress a 16-bit compressed file with a 12-bit compiled program. >So one may run into some problems using compress depending on where one >does the compress and uncompress. Also, Compress is not part of the >standard System V release package to my knowledge, so a significant number >of sites mat *not* have it. The compress on Fish disk #6 uses 14 bits rather than the full 16. This doesn't really pose a big problem since you can instruct your host computer to use less of the bits when you compress. i.e. on the host: you receive file foo.Z.uu by news or whatever uudecode foo.Z.uu uncompress foo.Z compress -b 14 foo download to your micro using your favourite protocol \. _\\ \ _\ \\ `\ on your micro: uncompress foo.Z I use the last three steps w/ kermit (image transfers of course) all the time. I'm not sure about the SYS V sites problem, but there are a zillion versions of compress floating around so I think that many (most?) SYS V sites would have some version or another of compress. -Rico -- [NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode, foo] [CSIS food: supermailbox, tuna, fiberglass coffins, Mirabel, microfiche] [Cat food: Nine Lives, Purina, Meow Mix, Crave]
wagner@utcs.UUCP (01/14/87)
In article <470@oscvax.UUCP> rico@oscvax.UUCP (Rico Mariani) writes: > >on your micro: > uncompress foo.Z > Actually, using the fish disk compress at least, I found that I had to say compress -d foo to get the right results. In the UNIX setup, compress and uncompress are links to the same file, and the program figures out what to do by which way it was called (it looks in arg[0]). There aren't 3 copies on the fish disk, and anyways, I wouldn't want to keep three copies of the same program around, so I use the -d flag to get the right results. As I recall, it wasn't documented, but I did find it in the code (thank god for source). > > -Rico >-- >[NSA food: terrorist, cryptography, DES, drugs, CIA, secret, decode, foo] >[CSIS food: supermailbox, tuna, fiberglass coffins, Mirabel, microfiche] Cute. Are we supposed to infer something about the levels of paranoia of the two services? Michael
fnf@mcdsun.UUCP (01/15/87)
In article <470@oscvax.UUCP> rico@oscvax.UUCP (Rico Mariani) writes: >The compress on Fish disk #6 uses 14 bits rather than the full 16. This >doesn't really pose a big problem since you can instruct your host computer >to use less of the bits when you compress. Sometime in the next few days I will be releasing disks 47-52 (or maybe 53 if it gets filled) and on one of them is a new release of compress. I've found that 15 bits seems to be the upper limit for a standard 512K Amiga, but the disk will contains executables with defaults ranging from 16 bits down to 13 bits. As a side note, and I don't really know how feasible this is as I haven't looked at the code yet, but I will probably implement some sort of a virtual memory scheme within compress so that one executable will work for any and all number of bits. Might be slower than Commodore's release of a new machine, but slow is better than never... -Fred -- =========================================================================== Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA {seismo!noao!mcdsun,hplabs!well}!fnf (602) 438-5976 ===========================================================================