> 
> On Sat, 16 Dec 1995, Shawn Pearce wrote:
> 
> > But, in order to use the booter, it calls MacOS code, right?  And that'd
> > mean rewrite so that you can use it without the MacOS...  Anybody know the
> > booter well enough that has the time to do this?  Assuming someone proves
> > Mr. Kurtz's theory....
> 
> Well, in digging, there *ARE* no code resources in the System folder.  
> There are several code-like resources, though.  I finally found one that 
> executes first, but upon putting my own cheap little program in place, 
> the system crashes with a sad mac 0000000F 00000066.  Not very nice, 
> huh.  Either that or my disk was bad (I had to use Norton to fix a couple 
> of bad blocks very early on the disk).  Either that or I removed *too 
> much*.  Since my program was written in FutureBasic, it's probably more 
> likely that my program's runtime module crashed.  Dunno.  If somebody has 
> a simple program to do something like scramble the video memory or 
> something else that doesn't use any MacOS code, could you drop me a 
> note.  I'd like to test this theory, but I don't have any kind of a 
> compiler to build a simple program.  Hmmm.  Maybe just resource 0 should 
> be in the strange format and the others should remain as CODE resources.  
> I'll try that sometime later today.

Ack! Don't do that! I bet the runtime module is expecting a full system,
so you can't put it in the system file.

My insticts are that you shouldn't touch the System file AT ALL. There
are two ways to go, as I see it:

1) Replace the code in the boot blocks with code which will fire up
NetBSD. Note: At this point in startup, we don't have a MacOS yet.
We just have rudiments which can deal w/ hardware. We don't even have
the ability to read files yet. This method would be the fastest, as
we don't load ANY MacOS, but we have a 24-bit memory scheme at this
point, so we'd need to screw heavily w/ the PMMU tables.

2) Let MacOS come up. Note: we'd probably want to run w/ a minimal
system, possibly one just for the machine in question. We then either
relabel the booter to be the startup program (as described in the
bootblocks), or we just stick the booter in a Startup items folder
and set its preferences to boot after launch. The advantage of this
technique is that we don't really have to do anything new. We just make
minimal OS disks, stick on a booter, and away we go. Also, we can use
the booter to change boot defaults if we want, and the booter only has
to run under MacOS (we don't have to roll our own windowing system).
As a final plus, we have a system in a state documented (as well as it
is) in IM.

I kinda think the latter is the easiest. I tried to make a boot floppy
for my IIsi last night, but the disk was defective, so I ran into
trouble. Also, I'm not sure if System 7.1 likes having a StartUp
program which isn't the Finder (as theFinder's such a special app
to the machine).

If you want to muck around w/ the boot process, look in either Inside
Mac vol 5 (old) in the Startup Manager chapter, or look in the
references in the new IM quoted in another post. Interestingly, the
prefface to the Startup Manager chapter says the only reason you'd
want to read it was you were going to be porting another OS to the
Mac. :-) This discussion is clear about what is and isn't
available at what time.

About having a startup folder, etc, check out the partition table.
Mr. Norton tells me that my partition table indicates the HFS
directory ID for the system file, and for the startup program.
Changing these values lets us get rid of a system folder.

Take care,

Bill