mfro wrote: ↑Fri Feb 04, 2022 11:35 am
Anyway, I think MiNT could (and maybe should) do something else instead. As MiNT knows the process it's killing, it might be able to walk a list of "well known to be a target of redirection" vectors, determine if they are modified (pointing inside the process' memory that just gets killed) and - provided the redirection was done cleanly (using XBRA) - unhook the vectors by resetting them to their previous value?
Yes, something similar was proposed in that 1995 thread as well. I quite like it (despite the fact it's burdening the OS with something which it really shouldn't be its business but on the other hand, changing system vectors shouldn't be application business either).
Since the kernel knows everything, it could easily supply the xbra unhook function, it could even check whether the application had already called its own unhook function.
This would actually make FreeMiNT quite user friendly in case an app/game/demo freezes (and still adheres to XBRA of course -- but maybe there could be a fallback reset in case it doesn't?); one would get keyboard, screen, sound/dsp lock etc back for every crash... hmm... not bad, not bad at all.
The only problem I see is that someone in the future could misinterpret this as an OS feature and leave out any deinit code entirely, making it crash in TOS and MagiC pretty badly.
EDIT: now I'm thinking about it even more, maybe we could make this really robust. For instance the kernel could supply the XBRA idea as whole, i.e. tracking who's changing which vectors and when the application is unexpectedly terminated (or terminated with faulty deinit code), just fix the chain within the kernel. And for really dirty apps (setting vectors directly, no XBRA, ...) one could have a flag in the PRG header like "save the current state because this app is going to destroy everything and not put it back on exit".