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

[Peter Rottengatter <perot@pallas.amp.uni-hannover.de>]

On Thu, 12 Mar 1998, Jo Even Skarstein wrote:

> > PC too. I'm pretty sure the MagiC people will simply refuse to acknowledge
> > any competence on your side to set any new standards. So while you could
> 
> And by that rationale we should accept every ASH does? Like adapting

I have not said, nor meant, that.


> > quently there are many programs that install one. For me, that's good
> > reason to not ban exception handlers. After all, it does not necessarily
> > affect system stability or performance of MiNT at all, so what the heck ?
> 
> I'm not talking about banning exception handlers, and there has been

Ok, but others did (by referring to the dogma of exception handlers
belonging exclusively to the OS).


> efforts have been made to make MiNT more secure and suited in a
> networked environment, and catching exception-handlers is not the
> smartest thing you do...

Why not ? It all depends on how the handler is done. You can write it such
that it's rock-solid, then it's in no way a danger to the system. On the
other hand, if you allow applications to use Supexec() (which you need to
do with TOS), they have every means to entirely crash the system. So
calling exception handlers more unsafe than "normal" application code in
insane as long applications are not entirely restricted to user mode
(which won't work under TOS).


> And IMHO the best way to ensure the future of MiNT and Atari computing
> is to adapt it to the rest of the world, and not necessary MagiC
> alone.

I did not mean to adapt to MagiC. I mean to talk to the MagiC people and
do independent stuff only where agreements cannot be reached, but then
stick to staying close to single-TOS where that is an issue. So it seems 
to me we do not differ at all in our opinions here.


> From my point of view it's MiNT that moves in the right
> direction now ( -> more secure, more suited in a network) and not
> MagiC ( -> Windows-like, lots of gadgets but nothing useful for me).

As you said, it depends on the point of view. That's good reason to not
simply dismiss MagiC, but try to stay compatible.

BTW.: A comparison to Windows is unfair by many respects ! MagiC is a
rock-solid OS, and even more immune to shaky programs than MiNT !


> > fact that running those after MiNT gives trouble, you deduce that their
> > trouble is caused by their exception handlers (if any) running before
> > MiNT's. I must say that I find that rather unlikely. There are quite a 
> > few other things that cause dependencies, I suspect very much that it is
> > something else that gives you problems here.
> 
> Then your fix really won't matter, will it? Running-order still
> matters. 

I said, it's a *step* towards independency of running order. I haven't
claimed that complete independency could be reached.


> > Someone mentioned an XBRA_install() (or whatever it was called) function
> > that is used by MiNT during initialisation. I do not have any recent
> > MiNT source code. Maybe someone can send me the code for that function,
> 
> /*
>  * install a new vector for address "addr", using the XBRA protocol.
>  * must run in supervisor mode!
>  */
> 
> static void
> xbra_install (xbra_vec *xv, long addr, long ARGS_ON_STACK (*func) ())
> {
> 	xv->xbra_magic = XBRA_MAGIC;
> 	xv->xbra_id = MINT_MAGIC;
> 	xv->jump = JMP_OPCODE;
> 	xv->this = func;
> 	xv->next = *((struct xbra **)addr);
> 	*((short **)addr) = &xv->jump;
> }

Aha, that's pretty basic. The typedef that defines xbra_vec would a
lot btw. ;-)


Cheers  Peter

---------------------------------------------------------------------
   Peter Rottengatter       perot@pallas.amp.uni-hannover.de
                            http://www.stud.uni-hannover.de/~perot
---------------------------------------------------------------------