Greetings,

I understand that some API's should not be patched, but I need to do it
anyway, for a school project.  Let's say I wanted to make an ordered list of
every system call that occurred, as it occurred.  I could patch every
individual system call, in HackMaster fashion, to update a log database, and
then call the regular system call.  More simply, I could replace the trap 15
handler with a new handler that would log each system call to a database,
and then jump to the regular trap 15 handler.

The problem is where to store the log?  The Feature manager is not
re-entrant (probably not a good place to write a big log anyway).  I would
guess the database functions are not re-entrant either.

Is there a good way to save this data?  Is there any possible way to save
data from *any* patched API call?  Would allocating a big hunk of dynamic
ram work? (I know it would be rude, possibly even evil, but would it work
for this toy school project?)

-Todd



This post was sortof related, so I included it:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Post from 7/23/99:
At 5:29 PM +0000 1999/07/23, [EMAIL PROTECTED] wrote:
>Does Palm have a list of which traps should "absolutly not" be trapped ?
>It would be very helpfull to have something to reference when writting
>trap code.

They're listed in Appendix A of the Palm OS documentation under the heading
"System Use Only Functions". Not listed there, however, are all APIs
beginning with 'Hwr' and 'Prv' which are also very much off-limits.

Also note there may be issues with trap patches installed from HackMaster
hacks for otherwise seemingly legitimately patchable public APIs, due to the
need to call the feature manager from within the trap patch to obtain the
call-through address.

For example, if the patched API is ever called from within an interrupt
service routine, system kernel timer, or pre-emptive background thread (to
name a few). The feature manager is not re-entrant for these cases, so
FtrGet will eventually crash the device, which could possibly destroy the
user's data depending on which API had been patched.

This list is obviously incomplete, but it's a start. Hope the info helps!

Regards,

Jim Schram
3Com/Palm Computing
Partner Engineering



Reply via email to