This is what I'd try to do....
As long as the file streaming API as well as the DB API come to allocating
memory, you'll always be limited to the available system memory.
If you allocate a fixed buffer and the simply write to it (while in trap,
using the suggested approach), you'll be limited by the size of the
allocated block.
If you want to make that block extendable (again, up to the memory limits),
you couldn't use the DB api for the reasons already discussed, but I'd
assume (and check several times!!!) that you could use MemPtrNew. If you
can't - then I'd simply forget the idea. If you can, though, you'd be able
to create a linked list of memory blocks, which is a primitive, but yet
functional DB structure.
Will that work for you?
BTW, if you want to catch _all_ systraps....you need to get the interrupt
handler, probably, which dispatches the interrupt call. Is that what you
plan to do?
BGK
-----Original Message-----
From: Todd L. Cignetti <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Thursday, August 19, 1999 3:18 PM
Subject: Re: How to save data from *any* patched API call? (Hack/patch
related)
>The maximum size of the log would be limited to the size of RAM with this
>solution.
>Is there a way to do this with a database or the file streaming API?
>
>----- Original Message -----
>From: Bobby Kolev <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Thursday, August 19, 1999 1:44 PM
>Subject: Re: How to save data from *any* patched API call? (Hack/patch
>related)
>
>
>> Below is something I believe I mentioned recently. This time I just found
>> the mail and enclose it.
>> BGK
>>
>>
>> The technique I use (example is of patching DmOpenDatabase, stripped of
>> error checking) is:
>>
>> // My global data.
>>
>> typedef struct {
>> various global data
>> } GlobalsType, *GlobalsPtr;
>>
>> // Special structure used to create a snippet of code, which gets called
>> // as the patched routine, sets up the global ptr, and then jumps to the
>> // real patch code.
>>
>> typedef struct {
>> Word opCodes[3];
>> VoidPtr codeP;
>> GlobalsPtr globalsP;
>> } PatchType, *PatchPtr;
>>
>> // Snippet of patch installation code.
>>
>> GlobalsPtr gP = (GlobalsPtr)MemPtrNew(sizeof(GlobalsType));
>> MemPtrSetOwner(gP, 0);
>>
>> PatchPtr openDBPatch = (PatchPtr)MemPtrNew(sizeof(PatchType));
>> MemPtrSetOwner(openDBPatch, 0);
>>
>> // set up code to do move.l *+8,a0 followed by jmp instruction.
>>
>> openDBPatch->opCodes[0] = 0x207A;
>> openDBPatch->opCodes[1] = 0x0008;
>> openDBPatch->opCodes[2] = 0x4EF9;
>>
>> openDBPatch->globalsP = gP;
>> openDBPatch->codeP = DmOpenDatabasePatch;
>>
>> SysSetTrapAddress(sysTrapDmOpenDatabase, openDBPatch);
>>
>> // DmOpenDatabase patch. This gets called with the pointer to
>> // globals in register a0.
>>
>> static DmOpenRef
>> DmOpenDatabasePatch(UInt cardNo, LocalID dbID, UInt mode)
>> {
>> GlobalsPtr gP = GetGlobals();
>>
>> // do stuff in the patch code.
>> }
>>
>> // Return a pointer to our globals. Since they get passed to us in A0,
>> // and we're returning the GlobalsPtr result in A0, we don't need to
>> // do anything expect help the compiler generate appropriate code.
>>
>> static inline asm GlobalsPtr
>> GetGlobals(void)
>> {
>> } // GetGlobals
>>
>> >An even better approach would be to just allocate the extra needed
>> >space on the front of your "globals" chunk so you only allocate one
>> >chunk. This will probably require some clever inline assembly to put
>> >it all together, but it is possible. Probably would make for a good
>> >tech note since it solves the issue of having access to globals in
>> >code that runs at interrupt time.
>>
>> To do this, you'd put a PatchType record at the beginning of the
>> GlobalsType record, and do only one allocation - plus the first opcode
>> would need to change to load the address of the instruction into A0. I
had
>> them separated since I was patching several different traps, all of whom
>> wanted to share the same global pointer.
>>
>> -- Ken
>>
>> -----Original Message-----
>> From: Todd L. Cignetti <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> Date: Thursday, August 19, 1999 12:11 PM
>> Subject: How to save data from *any* patched API call? (Hack/patch
>related)
>>
>>
>> >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
>> >
>> >
>> >
>>
>>
>
