Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!usc!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!pasteur!cory.Berkeley.EDU!fadden
From: fadden@cory.Berkeley.EDU (Andy McFadden)
Newsgroups: comp.sys.apple
Subject: Re: //gs APW "compress"
Summary: 16-bits == lotsa memory
Message-ID: <20798@pasteur.Berkeley.EDU>
Date: 18 Dec 89 22:02:50 GMT
References: <3734.feeds.info-apple@pro-tcc>
Sender: news@pasteur.Berkeley.EDU
Reply-To: fadden@cory.Berkeley.EDU.UUCP (Andy McFadden)
Organization: University of California, Berkeley
Lines: 51

In article <3734.feeds.info-apple@pro-tcc> lvirden@pro-tcc.cts.com (Larry Virden) writes:
>In-Reply-To: message from fadden@cory.Berkeley.EDU
>Andy, what source code changes have been made to this compress?  I know of a
>source for a 16 bit compress in C which works on MS-DOS.  Since they have many
>of the same memory problems that the IIgs does, I wonder if we couldnt use
>that code pretty much as is.

I made very few changes to the code, and even then the changes were only to
things involving signal(), chmod(), and utime().  The most recent version I
have is a slightly hacked v4.0; I wasn't aware until today of an MS-DOS
compatible version.  At any rate, I made *no* modifications to the code
that did the actual compression, and wound up writing my own versions of
stat() and unlink() so that those portions of the code could remain unchanged.

Apparently there already is an APW version that handles 16-bit codes; if it
isn't on an archive site, perhaps the author will do a repost (the original
was posted about a year ago).

The reason I chose to limit it to 13-bit codes is the following:

- Minimum free memory for 13 bits is 73464 bytes.
- Minimum free memory for 16 bits is 433484 bytes.
- 13-bit codes require 16-bit ints; 16-bit codes require 32-bit longs (so
all handling of the codes is slowed by 50%).
- The M_XENIX defines (for compilers unable to reasonably cope with arrays >
64K) only handle BITS = 12, 13, or 16.

As far as I can tell, modifying it to handle 16-bit codes would require
changing one line, but would increase memory use from about 125K to around
455K.  I guess if you're using APW, then you've probably got enough memory
to handle it, but I wanted it to work for somebody on a 768K system running
ECP-16.

>Also, has anyone thought of a way to build an interface to a C program so that
>it would operate in 3 modes:
>
>1. from a shell with arguments
>2. from a program launcher without arguments (from prosel, etc.)
>3. from the Finder launched as a part of an Icon.

Change the filetype to S16.  Rogue works that way.  It may be possible to
check the filetype of argv[0]; that would give you a good indication of how
the program is being run, and allow you to react appropriately.  I think
numbers 2 & 3 are pretty much the same...

>-- 
>Larry W. Virden                 ProLine: pro-tcc!lvirden

-- 
fadden@cory.berkeley.edu (Andy McFadden)
...!ucbvax!cory!fadden