From: grantham@amalthea.tenon.com (grantham)
   Date: Tue, 17 Jan 1995 13:23:54 -36507155 (PST)

   In the version of the ZInstaller I made in early '94 (which never made
   it out), I had the same problem.  It seems to depend on where you compress
   it.  Where is the gzipped tar file from?

It's from Unix gzip version 1.2.3.

   > Well, this morning I sifted through the sources more carefully, and got
   > the booter to build under MPW, just for grins.  As you might imagine, MPW C
   > found many sins that Think C overlooks!

   It's nice to do checking in MPW, but please make sure that you can still
   compile the tools with Think C, since that's what most of the original
   Alice members seem to have around.  (e.g. I don't have MPW...)

But of course.  It's not hard - for instance, access to QuickDraw globals
should always go through a macro QD() that can expand into a global or a
struct ref, depending on the compiler.

   > Here's a proposal for a new Mac-side source organization that puts all
   > the various source bits for both programs into a single folder:

   This looks good, but don't forget the basic rule of Alice Group
   development; "hack it until it only crashes less than 50 % of the time,
   and only then go back and fill in the 'About' dialog box with
   rotating 3-D text."

:-)  I was thinking more at the level of throwing away dead and/or obsolete
code.  I was just showing jtc the two-argument calls to free() that are in
the ufs code that the installer uses now, it was both entertaining and
horrifying...

   >    have the actual install process boot with a RAM disk loaded and install
   >    from w/in a running kernel or a mini-partition loaded into the swap
   >    partition as a 1-4MB "install" filesystem.  Go to it!
   > Uh, I don't understand the advantage of this change... for speed perhaps?

   It allows you to use NetBSD gzip and tar directly instead of re-writing
   the code.  This is something we discussed re: MacOS filesystems in
   VFS.  Then you could boot NetBSD, mount your Mac filesystem, and then
   use NetBSD tools to install, which means
	   a) richer toolset
	   b) don't have to crowbar UNIX code into MacOS
	   c) don't have to update MacOS utilities everytime the kernel
		   ufs source changes.

Hmmmm.  It seems more fragile, although when I think through various
failure scenarios, there are ways to recover, so maybe it's sufficiently
robust.  Making Unix code run under MacOS isn't *that* hard, especially
if you can get the maintainers of the Unix code to accommodate you here
and there.  In any case, there's not much point in me messing around with
that part of the Installer if it's going to be removed soon, so I'd like
to get a decision on which way people want to go and when.

							Stan