This is yet another resubmission of the arc source from the version posted
by Stu Heiss (ihnp4!jpusa1!stu) in net.sources on 30 Sep.

Despite previous claims, I couldn't get original version to extract older
archives that were created using method # 6 on my SVR2 box.  After hacking at
it for a few weeks, I was ready to give up.  That problem has been fixed 
now, thanks to Dan Hazekamp (seismo!rochester!cci632!djh).

The following are the types of compression and the nearest unix equivalents:
 
  header #             name                shown in 'v' option     Unix

     1           standard packing              "   --   "
     2           standard packing              "   --   "
     3           non-repeat packing            " Packed "         pack
     4           Huffman squeezing             "Squeezed"         sq
     5           Lempel-Zev compression        "crunched"         compact
     6           Lempel-Zev plus non-repeat    "crunched"
     7           L-Z plus ncr with new hash    "crunched"
     8           dynamic Lempel-Zev            "Crunched"         compress

I've changed the file name extentions to lower case 'arc'.

Emmet P. Gray				US Army, HQ III Corps & Fort Hood
..!ihnp4!uiucuxc!fthood!egray		Attn: AFZF-DE-ENV
					DEH, Environmental & Natural Resources
					  Management Office
					Fort Hood, TX 76544-5057

> This is a resubmission of the arc 5.12 sources posted by Mike Farren.
> 
> WARNING!!!
> 
> Although I've managed to get this running on a 68k Unisoft (sys 5) box,
> the code is not thoroughly tested.  I *do* know that it will handle
> crunched files and am pretty sure packed also.  Some of the other formats
> have not been tested although it probably works.  This program makes
> assumptions about sizeof and endedness.  It was written for CI-C86
> (8086 architecture) where sizeof and endedness is different for just about any
> datatype than on a 68k box.  Since it works at all, I've probably caught most
> (all?) of the dependencies.  The troublesome code is mostly (all?) in
> arcunix.c which replaces arcdos.mac and arcdir.mac.  I've done the
> typedefs for this machine only, but porting to others should now be
> simple.  The most troublesome part is dealing with the arc headers
> as you have to read the header into a buffer and parse it into a
> structure.  I have, of course, converted the source to *not* need the
> obscure macro processor.  The orriginal arcdos.mac and arcdir.mac are
> included at the end of this for the sake of completeness.  They are not
> converted.  I *have not* tried to get marc or xarc going although the
> Makefile would lead you to believe otherwise.  They're of little use under
> unix anyway.  Thanks to the poster of tm_to_time.c (included also) as
> this is necessary for the time/date conversions between dos/unix.  Sorry
> I can't remember who it was.
> 
> Following is a disclaimer from Mike's orriginal posting... - Stu
> 
> **** FLAMEPROOF SUIT ON ****
> 
> This is NOT a public domain program, but is copyrighted by System Enhancements
> Associates.  They have released the compiled program as shareware, meaning 
> that payment is NOT required for the program, but IS solicited.  I have
> received explicit permission from Thom Henderson, the author of this program,
> to post these sources.  No commercial intent is here, so please don't look
> for it!
> 
> **** FLAMEPROOF SUIT OFF ***
> 
> Some notes towards a UNIX version of ARC:
> 
> 1.  These sources represent the MS-DOS version of ARC.  As such, they have a
>     few of the MS-DOS limitations, i.e., eight-letter filenames with a three-
>     letter extension, limited use of pathnames, and assumption of a single-
>     user, single task OS.  It would be nice to address these limitations
>     for a UNIX version.
> 
> 2.  The sources are not, strictly speaking, C sources.  They need to be
>     preprocessed by a macro preprocesser.  The preprocessor used to produce
>     them is called MACRO, and is a commercial product of SEA, the producers
>     of ARC.  It should be a simple task to fake it, though, as the
>     preprocessor does not appear to have been used extensively.
> 
