[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: STiNG, CAB, and Multitasking (strikes back) (fwd)
On Wed, 11 Mar 1998, Jo Even Skarstein wrote:
> A question to the most experienced "MiNTers" on this list: Does anybody
> know *why* MiNT behaves like this in the first place? 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.
If such a reason emerges, then indeed it's probably best to just keep the
existing situation. It all depends on the very nature of that reason of
course.
> > The fact that some company releases some software does not mean that this
> > software is meant to set a standard on any particular detail. You cannot
> > tell that Atari was entirely happy with this point when they released
> > MiNT, you probably cannot even tell if they knew the problem. But that
> > does not render the point obsolete either, since Atari had earlier
> > specified rules for hanging into system vectors, hence I can only deduce
> > here that Atari did not intent to make this illegal. In fact I have always
>
> Atari has also documented features of the OS which they later have
> discouraged the use of. As the maintainers of the MiNT kernel I think it's
> up to us to decide if this should be done in this case as well.
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
decide to ignore the MagiC people, I believe this were a situation that
should be avoided by all means, because further divisions of our small
world weakens the Atari platform and accelarates it's decline.
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 ?
> > > And what about the possible problems with having MiNT's vectors at the end
> > > of the XBRA-chain? It doesn't work today, atleast not on my machine.
> >
> > Have you tried ? I don't think so. If, then tell me which program gives
> > problems ? It might be that it creates problems with some vectors, I never
>
> If you run MiNT as the first program in the autofolder (or to be more
> precise, before any other program that intercepts exception-vectors), its
> handlers will always be the last in the chain. A lot of other software
> (like Nova VDI, NVDI, MetaDOS and HS-Modem which are the trouble-makers I
> happen to have in my auto-folder right now) will then ceace working (yes,
> I've tried this). If I have understood the proposed modification
> correctly, this will render most programs that today have to run before
> MiNT useless.
Here you're making an assumption that is not necessarily correct. From the
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.
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 ?
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,
I'd write a duplicate that implements my suggestion, and you could play
with it. As a first test I'd suggest a kernel that has both functions,
and uses my version only for the priviledge violation vector. I'd bet
that you won't notice any drawbacks. Next test could involve a kernel
that installs a larger number of vectors using my version.
> NB! I base this on Konrads statement (which you haven't commented, at
> least not yet, so I consider it accurate), that your proposal is to let
> MiNT's handlers always be the last in the chain.
Although essentially correct, it's a bit too general. I said from the
beginning that possibly there are vectors for which this method is
not appropriate. Also, "last in the chain" of course refers to the
position after the last XBRA entry. If there are non-XBRA entries beyond
that point, well, there is nothing one could do for them, MiNT has no
choice but to unlink them (if the MiNT handler is to be kept, which I
consider a given fact here).
> > I haven't asked to apply the method to every vector. From the beginning I
> > only asked to do it for those for which it is safe.
>
> (Oops, that destroyed my previous argument...) I see your point, but I'm
> not sure how smart this is in the long run. My opinion is that all
> handlers should be treated equal in order not to confuse programmers. IMHO
> if we change the behavior of one vector, we should change them all.
> Consistency matters, atleast in my narrow and technically minded world :-)
You're right, that's a valid point. However I guess there would be very
few for which my suggestion is inappropriate. Probably the vectors can
be told apart by some very simple criterion, maybe it's even so obvious
that it does not even be mentioned in the docs ?
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 ?
> My opinion is that this is something that's not really worth spending time
> on (yes, I know that you offered to write the code, but your time is
> valuable too.), as the current situation (tuning the running-order in
I might agree, but this is really such a simple thing ...
> 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 ;-)
Cheers Peter
---------------------------------------------------------------------
Peter Rottengatter perot@pallas.amp.uni-hannover.de
http://www.stud.uni-hannover.de/~perot
---------------------------------------------------------------------