Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!alberta!sask!reid
From: reid@sask.UUCP (Someone you don't know)
Newsgroups: comp.sources.d
Subject: Re: help with compress on XENIX
Message-ID: <969@sask.UUCP>
Date: 21 Dec 87 19:31:47 GMT
References: <810@hyper.UUCP>
Reply-To: reid@sask.UUCP (Irving Reid)
Organization: The Church of the Least Fixed Point
Lines: 32
Keywords: compress,xenix,4.0,help

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?