On Mon, 8 Mar 1999, Bob Ebert wrote:
> At 12:57 PM -0800 3/8/99, Kenneth Albanowski wrote:
> >Hmm... "Conflict Catcher(tm) for PalmOS(tm)"... Nah, it'd never sell.
>
> ...actually, we've talked about various ways to figure out which app is
> running so the user can be notified. In this case, it's fairly easy since
> the app's creator code has just been used.
Though just _knowing_ isn't sufficient, you have to communicate it too. I
suppose there could be an alternate boot mode (not Up or Down) that
displays the name of each app, before it invokes it, and halts instead of
rebooting on a crash. (Hmm. Just like the INIT icons showing up on the
Mac, come to think of it.)
More interesting would be an automated killer-task-disabler. This might
even be feasible: keep some status information and magic numbers in RAM
during the invocation of the apps. If that status information is present
when a warm boot occured, then the last app listed must have killed the
thing, so skip it this time around -- more work is needed to support
skipping multiple apps, of course.
Once a boot completes, bring up a dialog saying "task Foo was skipped due
to crash, do you want me to delete it?".
> One marginally interesting problem we face as hacks and callbacks become
> more prevalent is that customer support gets calls about 3rd party
> software. If we had some relatively easy way to figure out which app was
> running (down to the level of a hack that's patched out an OS trap), we'd
> find it much easier to 1) figure out the problem, and 2) have the user
> direct their questions to someone who can actually help.
>
> One problem with simple solutions like a low memory global that tracks the
> app creator is that there are sub-calls and hacks, so you end up either
> slowing down the OS or using a lot of space.
>
> At the opposite end, a solution which tries to figure out the app from the
> program counter or call stack breaks down when the crash has side effects
> in OS systems like the data manager or memory manager.
I think the question is just _what_ tends to break if a hack is causing
trouble. Will the hack itself crash, will some OS call that the hack
invokes crash, or has the hack merely damaged the OS in some way that
causes it to crash later, outside of the hack's code? You can detect the
first by looking at PC, and tracking it back to its owner (assuming the
owner still lives). You can detect the first and second by looking at the
call stack (assuming it wasn't nuked, and that the owners can be traced).
My guess is that the third can only be detected by statistical analysis.
It strike me that it wouldn't hurt much to add some code to the Reset
dialog that attempts to trace back the owners (a term that is probably a
bit fuzzy) of the code points in PC and on the call stack, producing
database names. After all, the worst that could happen is that the data
manager and stack are corrupted, causing the tracer code to crash.
> So while conflict catcher may be overkill for now, "who's running" is an
> interesting problem, and might be fun to work on.
Indeed, and one that'll become more important. Anything that helps users
diagnose their own problems will take some load off customer support. And
if all you change is the Reset dialog, there's not much possibility of
making things worse. (Famous last words).
--
Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)
