earleh@dartvax.UUCP (06/10/87)
First of all, let me say that System 4.1 is a nice piece of work. (The Finder that comes with it needs some hacking with ResEdit to make things preload, though.) I have a 512Ke, and use a 512K (yuch) at work. The new System file takes a lot of squeazin' to make it fit on a single sided floppy, but with some careful hacking of Installer scripts, the job can be made easier. This procedure is not intended for the faint of heart, since one little mistake can generate a severely crippled, maybe non-bootable disk. In INFO-MAC Digest, Volume 5 : Issue 92, Joel West writes: > >Finally, people complained about the size. One factor is the set of ROM >patches to retrofit old traps and add new traps. The resource sizes are: >'PTCH' 0 540 bytes all systems > 105 5,696 Mac 512 > 117 26,884 Mac Plus, 512e > 630 12,958 Mac SE > 376 12,004 Mac II > >If you really need to make a compact a Mac Plus-only version, strip out: > PTCH: 105, 376, 630 > snd,snth,ADBS,cicn: all >That saves 40K in the System file. You could also make an SE version >by stripping the unused PTCH's an all but the ADBS. For the Mac II, >strip only the PTCH. What follows is a summary of how I modified my "Mac Plus,512Ke,512k (v4.1)" Installer script to (a) not install the patches, (b) not install any desk accessories unless already in the destination System file, and (c) skip the FONT update. As a result, I am now running VersaTerm PRO on a single-sided floppy, with a MiniFinder and 40k of free space. If you want more details, I refer you to "TN 75 Installer Scripts" for them, this is just a cookbook. Briefly, Installer scripts (resource 'insc', ID 0) look like a bunch of file and resource names embedded in what looks like pcode. Open up one of them with FEdit or REdit (I prefer REdit over ResEdit because it is much safer to use, also ResEdit crashes if I open 'insc's as 'insc' for some unknown reason). Scan through the display in the ASCII part of the window until you find 'DRVR'. The two bytes preceding the 'D' are a disposition code, telling the Installer what to do with the resource. The 'R' is followed by a few bytes of pcode, mostly zeroes, then the driver name. The stuff between the resource type and the name (if present) is stuff like resource length, ID, and filler bytes. You know when you've found the end of the part of the script describing a particular resource when you run up against the next disposition code and resource type. Find the entry for "Chooser". Starting two bytes before the 'D' in DRVR, the hex part of the display should read "600044525652". Changing 6000 (hex) to 6040 (hex) tells the Installer to install the Chooser only if there is one in the destination system. Changing 6000 to 6040 for ALL the DRVRs (drivers) tells the Installer you don't really want any of them unless already installed. Depending on your setup, you might or might not want to do this with ".Print" and the Appletalk drivers, too. Now for the patches. These don't have names, but you can go by the ID numbers, which are right after the resource type, 'PTCH'. The number is repeated, once for the source ID and once for the destination ID. In case you can't convert decimal to hex in your head, here are the equivalents: dec hex 0 0 105 69 117 75 630 276 376 178 The default disposition code for the 'PTCH's is 6002 hex, and is to be found just before the resource type, as with the 'DRVR's. Changing this code to 400A hex causes the Installer to REMOVE the patches you don't want. MAKE SURE TO DO THIS ONLY TO THE PATCHES YOU don't WANT. Now for the 'FONT's. These are installed along with the 'FOND's, and these are found at the end of this script. Chances are, you have one favorite font or two, and don't want Times, Helvetica, Courier, etc. on all your disks. You might not even like Apple fonts, and you use Boston II, that's up to you. Anyway, the default disposition code for 'FOND's is 6000. Change it to 6040, and you only get the 'FOND's and 'FONT's you already have. Trouble is, you get all the sizes. Personally, I prefer to handle the font stuff with Font DA Mover, and don't like the Installer messing with it. I couldn't think of a way to do this by changing the disposition code because as we all know, we have to have Geneva (the "real" name for these two bytes is "rspec" but I'm not using it because the term is vague, in case you wondered.) This is what I did to disable the font update completely. This part is tricky (I bet you thought the other stuff was tricky.) Find the hex string 0653797374656D000072. This is the name of the System file, followed by two zero bytes and then 72 hex. The 72 hex is, I believe, the number of resources handled by this update script. STOP HERE IF YOU ARE TIMID. Change the 72 hex to 6C. Go down to the first 'FOND'. Back up two bytes to the beginning of the 6000 hex preceding it. Press the '0' key and hold it down until you reach the end of the 'insc' resource. (I strongly recommend REdit for this operation, because with FEdit it's kind of hard to tell when you have hit the end of the script). You're all done, except for one crucial part. Go back up to the beginning of the script. Locate the text for the script title and help screen. Alter the ASCII part of the text in such a way as to positively identify this script as something that was hacked by you and is not a virgin Apple product. I find that the string "ROGUE MONSTER: ARRRGGGH! MONSTERS FROM THE DEPTHS!" right in the middle of the help text works for me. I also changed the title to "Earle's DEATH script" just to make it distinctive. Be careful not to mess with the bytes that define the help and title string lengths, or you will be sorry. Just planting something offensive in the middle of these two strings is a pretty safe way to give most people the idea there's something queer about your script. I didn't bother with "snd,snth,ADBS,cicn: all" because the ADBS is just a little bitty thing, hardly worth the trouble, and the Installer didn't give me the other things when I used the Mac Plus/ 512k/512ke script. Disclaimer: If you choose to hack up any software based on what I have written here, you do so at your own risk. Neither my employer not myself approve of other people hacking up software or using it for other than its intended use. -- ********************************************************************* *Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755 * *********************************************************************
han@apple.UUCP (06/11/87)
Please do not do stuff like this unless ABSOLUTELY necessary. Removing
system patches is VERY dangerous. And modifying the installer scripts
is worse.
If you ABSOLUTELY need to do stuff like this, make a virgin copy of the
system and finder and use ResEdit to remove stuff. BUT DO NOT DO THIS
UNLESS ABSOLUTELY NECESSARY. If you use the software and applications
crash because patches are not there, you will be sad. And you will
blame 1. Apple 2. the application producer.
=====================================================================
Byron Han | UUCP: {sun,voder,nsc,mtxinu,dual}!apple!han
Apple Computer, Inc. | CSNET: han@apple.csnet
20525 Mariani Ave, | ATTNet: 408-973-6450
Cupertino, CA 95014 | GENIE: BYRONHAN APPLELINK: HAN1
MS 27Y | CSERVE: 72167,1664
=====================================================================
All opinions and statements do not necessarily represent those of my
employer, Apple Computer Inc.
=====================================================================mayerk@linc.cis.upenn.edu (Kenneth Mayer) (06/11/87)
[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
earleh@dartvax.UUCP (06/14/87)
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 * *********************************************************************