Flash Tool 1.2 doesn't work under System 3.2 - it bombs with error ID = 12, which seems to mean I called a trap routine that's not implemented in that version of the system. I fixed one instance of this by changing the program to use GetNextEvent() instead of WaitNextEvent(), so now at least the program starts up and shows the dialog box. But if you select a file to use as the ROM image, it bombs again with ID = 12, and I can't figure out why.
From experiments with commenting out parts of the code, it looks like calls to FSOpen() and GetDialogItem() both cause an ID = 12 bomb. But FSOpen() appears in Inside Macintosh Volume II, which means it's been available since the earliest days of the Mac. I don't know why it would bomb. GetDialogItem() is a renamed version of GetDItem(), which appears in Inside Macintosh Volume I. Again, it's been there since forever, and shouldn't bomb under old System versions.
Here is the code where the bombs occur when running under System 3.2, inside the if (repl.good) block:
OSErr err = noErr;
Can you install macsbug on the machine? That should be able to help you figure out what the trap is that's causing the problem. Are you using CodeWarrior? It seems like CW's not setup for developing for older releases. You probably are including the MacOS.lib library that can be doing calls only implemented on later systems. The most common I've found is _StripAddress (0xA055), which I think appeared in system 4?
Just doing a hexdump on the resource fork of Flash Tool 1.2, I see two calls in there. Fortunately, just s/a055/4e71/ works fine for _StripAddress since it modifies A0 in place, so you don't have to do anything to have a correct return value for 24bit only machines.
I've found THINKC5 and earlier work well for developing for early systems. They don't add a lot of the glue code that CW does.
You're a genius. I know you mentioned that same thing with your ROM disk driver, but I didn't think to check it.
Using ResEdit, I patched the first instance of A055 with 4E71 and now the program seems to work under System 3.2 (still needs a bit more testing). The second instance looks like it was actually part of two other instructions: nnA0 followed by 55nn. When I patched that one, I started getting bomb ID = 03, illegal instruction. So I think only the first one is actually a call to StripAddress.
I should look in the Codewarrior code generation options to see if there's a way to fix this.
Cool! Yeah, it's been an issue for the ROM work because the Plus ROM doesn't have it implemented, although once booted into a newer System software, the trap gets installed (although is essentially a nop anyway, at least the trap is there and works).