FWIW, everything in your original post still applies, and just booting to a Finder desktop via removing a check shouldn't be considered "working" by any means.
The ROM can be thought of as the actual OS. The System file is very literally just a collection of Resources that get run by various things like the Finder, ROM, etc.
The ROM's memory manager is what initializes the heap before booting. The ROM needs to allocate memory before booting for all kinds of things. For instance it allocates the device driver table, the disk queue, loads device drivers from SCSI disks and Slots into RAM, device drivers need to allocate their own private storage, etc. And these need to continue to run after control is transferred to Finder or another application.
And it's not just the memory manager, all kinds of different parts of the system are working this way. And all of this code is run before the System is loaded, and can patch the ROM. Which also means the System must be compatible with whatever the ROM did. It's straightforward enough for a newer system to know what previous ROM behaviors were, but the opposite is much less likely to work.
In this case, doing much after booting will result in memory manager errors if you're lucky (meaning the memory manager caught internal self-inconsistency and bailed), and if you're unlucky, bus errors, memory corruption, etc.
I just did the NOP, so it's really just removing the check, and if stuff works, it works. If not, boom crash.
The patching process matches on the version number of the ROM, and entire eras of machines have the same version number, despite overall different ROMs. As best I can tell, although there are differences between ROMs of the same version number, the offsets to key areas are kept the same (and in many cases padding has been added to ensure that), which means one patch can apply to multiple distinct ROMs. For the LCIII, it shares the same version number as supported System 6 machines.
It may be possible to just copy/paste a System7 patch from a later system, or just stub it out for other machines, or whatever. It's probably not relevant due to other internal data structure mismatches.
But... Depending on the specifics of ROMs, it may be more viable on some machines than others.
There are other 'ptch' resources (lower case) that are also applied. I think those get applied indirectly by one of the other resources the ROM executes.
Also, this is all way different on System 7, since that uses executable boot blocks by default, and uses 'boot' 1, 2, 3 and 'gbly' resources too. Anyway, that's for another time.
I just started all this because I was curious as to exactly what fails, since most of the hardware specific initialization is handled by the ROM. So, disabling the check allows discovering why it won't work. That and the investigation into the boot process was the real value, IMO. Booting to finder is more an interesting curiosity more than a useful "solution".
The ROM can be thought of as the actual OS. The System file is very literally just a collection of Resources that get run by various things like the Finder, ROM, etc.
The ROM's memory manager is what initializes the heap before booting. The ROM needs to allocate memory before booting for all kinds of things. For instance it allocates the device driver table, the disk queue, loads device drivers from SCSI disks and Slots into RAM, device drivers need to allocate their own private storage, etc. And these need to continue to run after control is transferred to Finder or another application.
And it's not just the memory manager, all kinds of different parts of the system are working this way. And all of this code is run before the System is loaded, and can patch the ROM. Which also means the System must be compatible with whatever the ROM did. It's straightforward enough for a newer system to know what previous ROM behaviors were, but the opposite is much less likely to work.
In this case, doing much after booting will result in memory manager errors if you're lucky (meaning the memory manager caught internal self-inconsistency and bailed), and if you're unlucky, bus errors, memory corruption, etc.
I just did the NOP, so it's really just removing the check, and if stuff works, it works. If not, boom crash.
The patching process matches on the version number of the ROM, and entire eras of machines have the same version number, despite overall different ROMs. As best I can tell, although there are differences between ROMs of the same version number, the offsets to key areas are kept the same (and in many cases padding has been added to ensure that), which means one patch can apply to multiple distinct ROMs. For the LCIII, it shares the same version number as supported System 6 machines.
It may be possible to just copy/paste a System7 patch from a later system, or just stub it out for other machines, or whatever. It's probably not relevant due to other internal data structure mismatches.
But... Depending on the specifics of ROMs, it may be more viable on some machines than others.
There are other 'ptch' resources (lower case) that are also applied. I think those get applied indirectly by one of the other resources the ROM executes.
Also, this is all way different on System 7, since that uses executable boot blocks by default, and uses 'boot' 1, 2, 3 and 'gbly' resources too. Anyway, that's for another time.
I just started all this because I was curious as to exactly what fails, since most of the hardware specific initialization is handled by the ROM. So, disabling the check allows discovering why it won't work. That and the investigation into the boot process was the real value, IMO. Booting to finder is more an interesting curiosity more than a useful "solution".