🚀 go-pugleaf

In article <1336@super.upenn.edu.upenn.edu>, mayerk@linc.cis.upenn.edu 
 (Kenneth Mayer) writes:
> [A very long article on how to modify installer scripts...]
> 
> Since these scripts are fairly short, why don't all of you hardcore 
> mac hackers upload your favorite customized installer script to 
> comp.mac.binaries? It would prevent a lot of duplication of effort.
> Specify what changes you made and what it will or won't do.
> Kenneth Mayer				mayerk@eniac.seas.upenn.edu

I wouldn't feel at all right doing this.  Hacking up someone else's software
is one thing.  Passing out instructions on how to do it is another.  But
distributing a hacked up Installer script to a place where innocents can get
their hands on it?  That's where I draw the line.  Besides, I don't know the
legal status of these things, and I don't want to find out.  (Apple thought
police visit my house, call my employer "We hear Mr. Horton has not only
been hacking up our software for his private use: he has been distributing
copies of it to our customers.  If he doesn't stop, we're sending out the
LAWYERS.")  It's not really nice to hack up software, but I only do it
for my own use, so I don't feel too bad about it.  I don't feel at all
bad about telling other hackers about it, either.  But I do feel an 
obligation to help protect the innocent people of this world from 
hardware and software modifications that are meant to be used only
by those who can appreciate the consequences.  My feeling about this
kind of thing is, if you can apply the patch, then you are equipped to
handle the consequences.  Better to have duplication of effort than
to have innocent people get burned by something they don't understand.
This is why I did not, and will not, and expect others not to, post 
modified Installer scripts.

By the way, I have discovered why ResEdit no longer works with Installer
scripts.  The Technote describing  Installer scripts describes the 
disk block field as "unused, currently contains zero."  The TMPL in my
copy of ResEdit expects a zero in this field, and defines it as an 
"OCNT", presumably to discourage changing it.  It turns out that with
System 4.1, the disk block field is now used, and does not now 
contain zero, but the version number or whatever of the new boot blocks.
When I tried to attack the Installer script with ResEdit, it found a
hex 16 (dec 22) there, and assumed that meant 22 boot blocks descriptors
were to follow.  I guess ResEdit then thought there were 22 boot blocks
fields to edit, and then allocated space for 22 of them, which caused it
to crash my 512 because there wasn't enough memory.  Also, the Technote
describing the boot blocks field appears to be grossly in error, since
what is there does not even resemble what the Technote said would be.
If you have a copy of ResEdit with an "insc" "TMPL" installed, then
you can modify it to work with the new Installer scripts by changing
the type field of disk blocks to "HWRD" or something, and modifying
the rest of the disk block fields to something harmless like "HEXA".

What this means is that if you applied my patch to the FOND part of 
the Installer script, then you didn't get the new boot blocks.  If this
has caused you any inconvenience, then I am sorry.  (It still runs
though, doesn't it?)  If you are seriously interested in disabling
the "feature" of the new Installer script that causes it to overstuff
your System file with FONTs that you may not want, then you have to
put the disk block info back in, right where the first FOND reference
used to be.  It's not hard, but remember to get the offset right!

Update:  System 4.1 runs fine on my 512ke after 10 days of use.  No 
problems, even though ALL of the system disks I use were updated using
one of my hacked-up Installer scripts.  I must have done something
right!

-- 
*********************************************************************
*Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755   *
*********************************************************************