@Crutch and
@cheesestraws since you guys seem to be enjoying my deeds of Mac derring-do, let me tell you about my ordeal with the Journaling driver, for therein lies a tale...
So while I was pulling my hair out over the MBState issue, I came across those two pages in the ancient scriptures (Inside Macintosh) about the Journaling driver and the fabled desk accessory Apple engineers had used to stress test the Mac UI. Surely therein lay the solution to my problem. So I whipped up a desk accessory and lo and behold, it worked... for about two seconds... sometimes four seconds, maybe five if I got lucky.
So the idea with the journaling driver is pretty simple. You write the reference ID of your driver to journalRef, and you set journalFlag to whether you want it to record or playback. Not too difficult, pretty self-explanatory. But I found out that whenever journalRef was set, it would get unset some time random interval later, like those
weird little boxes that turns itself off. I was able to declare a short-lived victory by resetting the journalRef each time my desk accessory got idle time, via the accRun, which allowed me to collect and playback events for longer periods under System 8.0 (on Basillisk II), but this same technique crashed the Mac Plus under System 7.0, so I had to abandon it. This left me trying to understand
why journalRef was being reset and by whom.
Wouldn't it be nice if I could simply watch a memory location for changes? AFAIK, no debugger can actually do this while the system is running at full speed and stepping was not an option since this was only happening every several seconds. So I decided to grab a copy of the PCE emulator and hacked it to print out the program counter whenever the journalRef address was accessed. This worked well and I hacked it to print out all the program counter values leading up to the change, so I could trace the chain of instructions that led to the fault. To make a long story short, the Button trap will do a Control call whenever journalRef is set, the Control call then checks the device unit table to see if there is an entry for the driver. If the entry exists, it calls the driver; if it does not, it returns an error code, which causes the Button trap to clear the journalRef -- a perfectly valid thing to do, I suppose -- BUT WTF IS MY DRIVER NOT IN THE DRIVER UNIT TABLE?
Well, I again hacked PCE to show me whenever the driver unit table was written to and I found it out it was done very frequently. My hacked PCE also told me the program counter when it was happening, but it was in the middle of RAM somewhere and I wasn't really able to gleam anything from the surrounding instructions to tell me what the code was doing, but the fact it was done periodically made me fairly certain it had something to do with task switching. Back in the days, desk accessories were legitimate device drivers that could be expected to hang around while an application was running, but now a days System 7.0 treats them as mini apps, so my guess is that this involves removing them from the driver unit table at each context switch. If this happens to coincide with an event that needs to be sent to the journaling driver, then the Control call fails and journalRef gets reset to zero. Not good.
Anyhow, I tried a couple things to attempt to make the Journaling driver to not act as a desk accessory, by loading it into the SystemHeap or putting a dot in the driver name so it wouldn't be a desk accessory, but none of that really helped. Maybe if I had loaded it at system startup via an INIT it would have worked. But anyhow, at this point I already had found out the journaling mechanism was kind of slow so it didn't seem like a workable solution for the VNC server anyway, so I kind of gave up on the idea.
Oh, one last thing. I also extracted Apple's own journaling Desk Accessory from the Guided Tour disk. It seemed to crash pretty spectacularly on modern systems. I did disassemble it to see if it held any secrets, that's how I learned about crsrCouple, but otherwise it seemed to be pretty much structured like my own Desk Accessory, so I don't think my attempt was wrong in any way.