[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, 12 Mar 1998, Peter Rottengatter wrote:

> I guess I said it in another posting : I believe, you (the MiNT developers)
> are not in the position (anymore ?) to do this. The Atari world is basically
> divided into three sections : There are the single-TOS users, which are
> probably the largest share, but few programmers, then the MiNT users, and
> the MagiC users. At least here in Germany MagiC dominates MiNT, and else-
> where MagiC plays an important role too, since it works on Macintosh and
> 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
their XFS/XDD-interface? Their dynamic libs? (Btw. that could make
sense, although I don't know how they're implemented)

In this case it's not a matter of making MiNT more or
less compatible. It's a convenience-feature that's conceptually
questionable, at least in the eyes of most of us (the MiNT list).

> AFAIK Atari has never discouraged the use of exception handlers. Conse-
> 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
no suggestions to alter MiNT in that way either (at least not for the
super-user). But it's not something we want to encourage. After all,
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...

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. 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).

> > If you run MiNT as the first program in the autofolder (or to be more
[...]
> Here you're making an assumption that is not necessarily correct. From the

Very possible, yes.

> 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. 

> A proper judgement can only be done by using a test MiNT kernel that
> implements at least partially my suggestion. Maybe we can try this ?

It would have been interesting to find out what's going on, but I'm
still very in doubt if this is clever to implement.

> 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;
}

> This can only be cleared up if we start to collect vectors for which
> trouble can be expected if the MiNT handler were moved to the end of the
> chain, and discuss them. Any suggestions ?

This is out of my league...

> > A bit off-topic: Perhaps a good "auto-folder" FAQ should be written?
> 
> That would help newbies a lot, but cannot help if "deadlocks" like I
> described earlier happen. And writing a FAQ costs more time ;-)

Well, as you said yourself, there are a lot of other things that cause
dependencies, so a FAQ would probably be the most useful and helpful
thing to do.


/*
** Jo Even Skarstein    http://www.stud.ntnu.no/~josk/
**
**    beer - maria mckee - atari falcon - babylon 5
*/