Subject: Re: Using the Installer
To: None <>
From: Stan Shebs <>
List: macbsd-development
Date: 01/17/1995 11:46:36
   From: (Allen Briggs)
   Date: Mon, 16 Jan 1995 22:19:27 -0500 (EST)

   > How exactly does one make files that the Installer can use?  I would have
   > thought any gzipped tar file would work, but no - I get
   > 	Invalid compressed data--format violated 1

   Are you sure that the file is a binary file with the gzipped data in the
   data fork of the file?

Yes.  It works with uncompressed tar files, which strongly suggests bugs
in the inflation code.

   > Also as a general question, is anyone working on the install and boot
   > programs?  I have some experience with Mac programming, and could help
   > make the code be more "Mac-like" etc.

   You're welcome to it.  All the Mac-side programs need an overhaul--I'd
   like to see both fsck and install combined into one program (maybe with
   basic disk partitioning thrown in although this is neither necessary nor
   particularly desirable).  The booter should probably be kept separate,
   but both could share a library to read/write ufs data.  They should also
   be updated to use the new level-2 ufs (the installer still writes level-1).

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!

I agree that mkfs should go into the installer, but need not include disk

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:

NetBSD_Mac_Setup Source
	Makefile		(MPW Makefile)
	Makefile.unix		(Unix Makefile)
	installer.option-p	(Think C project)
	installer.option-p.rsrc	(installer's resource fork)
	installer.MPW.r		(MPW Rez file - reads in .rsrc)
	installer.c		(all/nearly all installer code)
	booter.option-p		(Think C Project)
	booter.option-p.rsrc	(booter's resource fork)
	booter.MPW.r		(MPW Rez file - reads in .rsrc)
	booter.c		(all/nearly all booter code)
	unix-emu.c		(Unix emulation bits)
	unix-emu.h		(Unix emulation definitions)
	util.c			(random shared code)
	util.h			(random shared definitions)
	libufs			(UFS code)
	libgzip			(gzip code)
	include			(hacked common include files)

The contents of lib* and include should be synchronized with common
NetBSD and gzip sources.  One way to accomplish this would be to use
macro tricks - "#define printf alice_printf" and suchlike, plus include
file tricks - "sys/types.h" includes ":sys:types.h", to reduce the
amount of random source file tweaking and replication (I noticed not
one but two versions of ufs code in the sources, different from each
other and from the standard NetBSD source).  I do this sort of thing
to get GNU packages to build under MPW. (Cygnus hasn't advertised this,
but I actually have all of GCC/GAS/LD/BINUTILS/GDB building and running
under MPW, using sources that currently being distributed by the FSF!)

I would suggest not attempting to use Think's or MPW's console packages,
instead just using the booter's Output.c code for output and making a
dialog to handle the collection of input for the minishell (could even
have a menu of minishell commands, but perhaps not too important).

None of this really affects the actual workings of installing and booting,
but I'd like to think about some way to know whether things haven't been
broken accidentally.  Has anybody thought about using some sort of
emulation/simulation so that a real machine's filesystem isn't trashed?

   Someone else has expressed interest in working on this, and y'all might
   want to work on spec'ing a new install process (it might be nicest to
   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?

Who is the "someone else"? (I haven't gotten any pings)