Re: STiNG, CAB, and Multitasking (strikes back) (fwd)

["Eric R. Smith" <ersmith@netcom.com>]

>A question to the most experienced "MiNTers" on this list: Does anybody
>know *why* MiNT behaves like this in the first place?

In the case of the privilege violation vectors (and several other
similar vectors, such as for bus error) it was done so that MiNT
could (a) report the error to the user in a sensible way, and
(b) could send the appropriate signal (SIGPRIV, SIGBUS, etc.) to
terminate the process that caused the problem. Processes can also
catch these signals and work around them (as under Unix).
All of this behaviour is controlled by #define EXCEPTION_SIGS in
mint.h; if you comment this out, then MiNT will not try to
catch these events. Personally, I would recommend leaving things
as they are now; I think it's quite reasonable to require STiNG to
run after MiNT in the AUTO folder.

Some vectors (e.g. for trap #1) are always replaced by MiNT,
even if EXCEPTION_SIGS is not defined. This is because MiNT is
a replacement GEMDOS, and hence must handle all GEMDOS calls.
In some cases (access to a TOS format disk) it eventually
passes the call along to the old trap #1 handler, so programs
installed before MiNT in the auto folder still take effect.

I will agree that the MiNT documentation should be fixed. The
original rule ("always put mint.prg last") was far too simplistic.
The actual rule is: "always put mint.prg after any program that
modifies TOS services which MiNT uses", which generally means
any GEMDOS services or device drivers. Other system utilities
probably should come after mint.prg.

> Eric Smith did a
>very good job when he first developed the MiNT kernel, and this behaviour
>(unlinking handlers) would be considered very rude for any other TSR even
>back in '90. So I guess mr. Smith had a very good reason for doing this.

Thank you. :-) And yes, I did have (what I considered to be) a good
reason for this.

Eric R. Smith
ersmith@netcom.com