> The real problem is that HackMaster was created because > the trap redirection can cause the device to become unstable > if multiple apps try to hook into the same trap - I can't > remember if the instability occurs immediately or if the problem > is related to removing your hack. Anyway. If you're going to > do this it's very important that you also implement logic to > search for third party hack managers and refuse to run if one > is installed (because you're messing with the same infrastructure > they are). You will also need to give a loud warning to the user > that your hack cannot be used in conjunction with any other > hack. Annoying, but it's the only option - one hack per device > or only use HackMaster compatible apps.
OK, I have researched the issue and here is what I've found. Intercepting system traps in PalmOS is pretty much like intercepting interrupts with a TSR program in MS-DOS (yes, I am old enough to have done that). The problem occurs when your program is uninstalled after a program (installed after yours) has intercepted the same thing. Here is what happens. Normally, when you call a system trap, the call goes to the original code in PalmOS, thought a table containing the addresses of the various traps. When your application, let's call it First, intercepts that system trap and an application calls it, the call goes like this: First->Original That's because at installation time your application obtained the address of the original call, saved it somewhere and replaced it with its own address. This way when an application calls this system trap, your program receives control. It does its thing and chains to the original system trap by calling the address it has saved. Now, suppose that a second application (imaginatively named Second) is installed and that it intercepts the same system trap using the same method. Then, when an application calls this system trap, the call goes like this: Second->First->Original So far, so good. If, at this point, the user uninstalls the Second application, everything will be fine (provided that the application remembers to restore the address of the system trap it has intercepted). The problem will occur if the user removes the *First* application while the Second one is still present and active. The First application knows where the original address of the system trap is, and it can even determine that somebody after it has intercepted the same system trap (by intercepting SysSetTrapAddress) - but it has no way of knowing where that somebody has saved the address of the system trap at installation time. So, if at this point the Frist application is removed, we get Second->[never-never-land]->Original In other words, the chain breaks. As soon as some application calls the intercepted system trap, the Second application will receive control. It will do its thing and chain to what it thinks was the original address - except that now it points to a place that doesn't contain the program it used to contain. Now, in MS-DOS, TSR programs usually did not try to uninstall themselves. Even those that did, usually left a small stub in memory that did the interrupt vector chaining. Unfortunately, that's not an option under PalmOS - there, if you delete an application with the memory manager, it is gone; all of it. Third-party hack managers aside, I see only three possible solutions: 1) An application can refuse to uninstall itself, if it detects that another application has intercepted the same system traps it has intercepted - that's relatively easy to implement. However, this will frustrate the user a lot, given that s/he probably won't know what these other applications are, in order to remove them. 2) When uninstalling itself, an application could disable all other applications that have intercepted the same system trap after it. Unfortunately, it has no way of knowing where exactly they remember that they are intercepting something, so they will still "think" (i.e., tell the user) that they are active - but will, in fact, be disabled. 3) By intercepting SysSetTrapAddress, the application can detect if some other application is trying to intercept one of the system traps it has intercepted. When this happens, it can disable itself by restoring the original system trap address, effectively removing itself from the chain. Neither of these solutions is good enough, but at least they avoid the crashing problems that would otherwise occur. Regards, Vesselin -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
