mark@hyper.UUCP (Mark Mendel) (12/15/87)
I have recently tried to compile compress 4.0 on XENIX. The result is not compatible with BSD output. Further, though it is able to uncompress correctly, the 'compressed' files seem to be larger. I'm sure it must be a bug that somebody has already fixed. Please send mail. Compress -V output: $Header: compress.c,v 4.0 85/07/30 12:50:00 joe Release $ Options: vax, BSD4_2, BITS = 16 -- Mark G. Mendel, ihnp4!umn-cs!hyper!mark, Network Systems Corporation (612)-424-4888 x2779
scott@tekcrl.TEK.COM (Scott Huddleston) (12/17/87)
In article <810@hyper.UUCP> mark@hyper.UUCP (Mark Mendel) writes: >I have recently tried to compile compress 4.0 on XENIX. > >The result is not compatible with BSD output. Further, though it is able to >uncompress correctly, the 'compressed' files seem to be larger. > >I'm sure it must be a bug that somebody has already fixed. Please send mail. > >Compress -V output: > >$Header: compress.c,v 4.0 85/07/30 12:50:00 joe Release $ >Options: vax, BSD4_2, BITS = 16 Your problem sounds like the following. A compressed file will have up to 7 unused bits in its last byte, depending on how its final output code is aligned. #if vax then the unused bits contain garbage #else they are (properly) cleared #endif It's a disconcerting feature, in that it causes vax vs. non-vax compressed to not "cmp" equal (usually), but not a functional bug: a vax-compressed file will properly decompress on a non-vax, and vice versa. I don't have a patch handy, but it's not hard to find and fix. Identical files under different OS's often have different sizes if measured in blocks (but identical sizes measured in chars). This could explain why your Xenix-compressed files seem larger. P.S.- standard tar (from the BSD distribution) has a similar "bug": in a tar image, the last data block for each file has unused bytes that contain garbage. A smarter tar clears the unused bytes. Standard and smart tar "untar" identically. But "smart tar" images compress better than "standard tar" images, often by 10%.
bob@aargh.cis.ohio-state.edu (Bob Sutterfield) (12/18/87)
In article <810@hyper.UUCP> mark@hyper.UUCP (Mark Mendel) writes: >I have recently tried to compile compress 4.0 on XENIX. > ... >$Header: compress.c,v 4.0 85/07/30 12:50:00 joe Release $ >Options: vax, BSD4_2, BITS = 16 How did you get your Intel chipset to emulate a VAX? And what new version of XENIX is compatible with BSD? I think you probably need to check some of your compilation Options. -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-cis!bob soon: bob@cis.ohio-state.edu
reid@sask.UUCP (Someone you don't know) (12/22/87)
In article <810@hyper.UUCP> mark@hyper.UUCP (Mark Mendel) writes: >I have recently tried to compile compress 4.0 on XENIX. >The result is not compatible with BSD output... >Compress -V output: >$Header: compress.c,v 4.0 85/07/30 12:50:00 joe Release $ >Options: vax, BSD4_2, BITS = 16 >Mark G. Mendel, ihnp4!umn-cs!hyper!mark, Network Systems Corporation >(612)-424-4888 x2779 I've read a lot of compress talk on the net, but I have yet to see this mentioned: There is a much more important bug in compress 3.0 and 4.0, which I had to fix before I could get either to work properly on our Ultrix 1.2 Vax 8600. The $(#@*$^ distributed version of the program contains Vax assembly code, contained in "#ifdef vax", which depends on the register allocation of the particular compiler/machine the program's author worked on. On our ultrix system, this turned compress into a very effective one-way encription program. Of course, any attempt to decrypt the file resulted in a core dump... Do yourself a favour and take out all the "#ifdef vax" parts. And watch out - one of them is actually an "#ifndef vax", just to make the compilation logic trickier. -- - irving - (reid@sask.uucp or {alberta, ihnp4, utcsri}!sask!reid) Isn't life the strangest thing you've ever seen?
jamesa@amadeus.TEK.COM (James Akiyama) (12/24/87)
I believe that part of the non-compatibility of compress on 80X86 machines
has to do with the Intel segmentation. It turns out that VAX versions use
a 16 bit compression code which requires substantially more than 64K array
sizes. Since most 80X86 systems are limited to a 64K array they generally
only support a 12-bit compression code. I know of two fixes:
1. Compress using the '-b' switch and limit the compression to 12-bits.
This will actually speed the compression up some although the percent
compression will be somewhat reduced.
2. Obtain a modified compress routine which is designed for a 64K
segmented architecture. This is generally done by splitting the
internal arrays into several pieces --usually about 8; then using
the upper three bits of the array subscript to determine which array
to use. Note that this have a severe speed penalty on the 80X86
systems, generally decreasing the speed of the program to about half.
If someone has problem locating this I can probably send you a copy
over E-mail if you give me your full mail path.
As to someone mentioning a problem on the VAX systems running Ultrix, here at
Tektronix, we have not seen that problem on our systems. It turns out that
the "#ifdef vax" statements use a Vax assembly instruction to generate the
odd code sizes (9-16 bits) needed by compress. The Vax has a nifty instruction
which allows you to access the nth word where each word is x-bits (e.g. get the
15th 14-bit word from an array). The normally compress code requires a lot
of shift left, shift rights and multiplies. Hope this is of some help.
James E. Akiyamarupley@arizona.edu (John Rupley) (12/24/87)
Several requests for help in the use and compilation of compress
v 4.0 on Xenix systems have been posted to the net.
The discussion suggests that it may not be recognized that Xenix
patches for compress had been posted long ago, and can be ftp'd
or whatever from comp.sources archive sites:
original posting: compress v 4.0, comp.sources.unix, volume2
xenix patches: compress.xenix, in volume6, comp.sources.unix
Subject: v06i023: Xenix patches to compress4.0 (compress.xenix)
Stuart D. Gathman <vrdxhq!BMS-AT!stuart>
additional comments: in Misc.Patches1, volume6, comp.sources.unix
Subject: Re: v06i023: Xenix patches to compress4.0 (compress.xenix)
The Xenix patches take into account the Intel 80286 segmented
architecture, either explicitly or by letting the compiler do it.
16-bit compress appears to be ok.
These patches do not work for Microport SysV/AT, which lacks the huge
model. Microport patches have been posted to comp.unix.microport,
again for the 16-bit case. If the Xenix patches don't work for you,
why not try the Microport patches? These certainly should give you
16-bit compress.
John Rupley
uucp: ..{ihnp4 | hao!noao}!arizona!rupley!local
internet: rupley!local@megaron.arizona.edu
telex: 9103508679(JARJAR)
(H) 30 Calle Belleza, Tucson AZ 85716 - (602) 325-4533
(O) Dept. Biochemistry, Univ. Arizona, Tucson AZ 85721 - (602) 621-3929james@bigtex.uucp (James Van Artsdalen) (12/29/87)
I have compiled compress.c from the stock news distribution (patchlevel 14) on Microport unix SysVr2.2 with an 80286 in all its 64K segmentation glory. The only thing is that M_XENIX needs to be defined, which I accomplish via a localize.sh modification to the Makefile, as in: /^compress: /+1s/-o compress/-DM_XENIX -o compress/ I have not attempted this recently with Xenix, although I can't imagine it would be much more difficult. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: (512)-323-2675 Work: (512)-328-0282 5300B McCandless, Austin TX 78756
paddock@mybest.UUCP (Steve Paddock) (01/01/88)
In article <702@bigtex.uucp| james@bigtex.uucp (James Van Artsdalen) writes: |I have compiled compress.c from the stock news distribution (patchlevel 14) |on Microport unix SysVr2.2 with an 80286 in all its 64K segmentation glory. |The only thing is that M_XENIX needs to be defined, which I accomplish via a |localize.sh modification to the Makefile, as in: | |/^compress: /+1s/-o compress/-DM_XENIX -o compress/ | The same for SysV r2.0 on an AT&T 6300 Plus (essentially the same o/s and processor.) The only item of note is that the size of the running process is >900 blocks, which pretty much absorbs the attention of a 1 mb system. I keep a copy of the 12 bit compress as compress for on system use, and a copy of the 16bit which I call with compress16 -d to uncompress the off system 16 bit stuff. -- Steve Paddock (ut-emx!mybest!paddock) 512-477-9736 Best Printing Co, Austin, Texas 78767