>From what I've heard, there is definitely a nice way to do this in
Hackmaster 2.0 (which is coming "RealSoonNow(TM)").
A couple of comments though:
1. MemHandleLock and MemHandleUnlock are pretty high overhead calls.
Are you sure you want to call them (in addition to FtrGet) for
every single event? It might be better to keep a locked chunk.
Actually, even better would be to keep your stuff out of the
dynamic heap and use the data manager. There's a really easy
way to do this in OS 3.1 and up (FtrPtrNew). Of course, writing
to the data will take more time, but it's much nicer on the system.
2. I don't quite understand what you mean by unallocating on an
appstopevent. Are you implying that the hack gets one of these
when it gets uninstalled?
If you find a good way to tell when you are uninstalled in the current
hackmaster, let me know. I was trying to do this, but couldn't get a
foolproof method. One method I thought of was to patch SysSetTrapAddress,
and it works relatively well, but I haven't prefected it yet (it depends
somewhat on what order traps are installed/uninstalled in). Another method
would be to try trapping FtrUnregister, but the Hackmaster API explicitly
says that you can't patch Feature Manager calls (I want to try anyway
though...)
---
--On Wed, Dec 29, 1999 11:08 PM -0500 "David A. Buckle" <[EMAIL PROTECTED]>
wrote:
> I'm attempting to develop a hack using HackMaster to control the
> installation process (the hack patches the SysGetEvent trap entry).
>
> The trap routine that is installed makes some changes to the OS
> environment that need to be undone when the hack is un-installed:
>
> 1. It needs to maintain some global state between events. Rather than
> allocate memory for the global state on each event, it allocates some
> memory (using MemHandleNew) the first time the memory is needed,
> initialises the memory from preference memory, and saves the handle
> away in a feature.
>
> On subsequent events, the routine just locks the memory handle to get
> access to its global state.
>
> When it detects an appStopEvent event, it saves a small part of this
> global state to the preference memory, releases the memory chunk,
> and then unregisters the feature.
>
> 2. It changes the display settings. These are normally restored to their
> original values when the appStopEvent is detected.
>
> My problem occurs when the hack is un-installed. HackMaster seems to just
> remove the trap routine from the trap chain, and doesn't give it a chance
> to tidy up after itself.
>
> The HackMaster documentation mentions a custom extension routine, but
> gives no further details on the interface. I'm assuming that I could do
> the resource cleanup there.
>
> Does anyone know whether this has actually been implemented within
> HackMaster and if so what the API looks like?
>
> Any other suggestions as to how to get around this problem would also be
> greatly appreciated.
>
>
> Thanks - David
>
> -------------------------------------------------------------------------
> ---- David A. Buckle
> [EMAIL PROTECTED]
> -------------------------------------------------------------------------
> ----
>
>
