By disabling PalmOS' write protection as described in section 3, we create a new safety problem: it is possible for a VM to overwrite the memory of dormant applications and cause damage to them. This would need to be addressed in case our contributions were made into a product.
One could argue that a correctly implemented VM would never attempt any access outside its own store. Hence, debugging the VM and all added native code would ``asymptotically'' eliminate the problem. However, if one wants to be on the safe side, some form of hardware write protection is required.
If we accepted the limited amount of primary memory in the original Spotless VM, there would be a simple solution. We might then have implemented the persistence of execution state in dynamic RAM by copying all of it into a database record on shutdown and read it back into dynamic RAM on resumption. However, we do not have any intention to claim: ``64 K should be enough for everybody.''
It should be possible to protect only part of the static RAM, not all of it. One could then arrange during each switch between applications that all passive programs are protected and that only records of the designated active application are exposed to unprotected write access. For example, if the hardware protection is governed by an address limitation register, then it would be straight-forward to relocate each application so that only the running one resides in dynamic RAM.
The remaining problem is that memory outside records could be altered inadvertently, which would compromise the integrity of meta data (e.g., handle collections, database indices) managed by the OS. Ideally, the OS would place meta data in the protected memory range. In case it does not, a promising approach would be to save all of the meta data occurring in the unprotected memory area to a database before they can be altered and to restore them before yielding control to another program or the OS.