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

[Konrad Kokoszkiewicz <draco@mi.com.pl>]

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

This question has nothing to do with MagiC or its popularity anywhere.
STiNG works with MagiC, because STiNG is loaded after MagiC. Also, when
STinG is loaded after MiNT, it works also. So where is the problem?!
Perhaps MiNT doc say that the kernel should be last program in the AUTO
folder, but the confusion with STiNG which needs to be started after MiNT
may be easily avoided, by putting a line in the STiNGs documentation
that STiNG needs to be executed from MINT.CNF by exec
c:\something\sting.prg. That was Petr's Stehlik proposal, what you have
pretty ignored, insisting us to accomodate the kernel to a DIRTY
PROGRAMMING HACK. If you don't understand the difference between fault
recovery vectors and other exceptions, please read Howards postings again,
more carefully.

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

Actually assuming that "something else" is making problems is always a lot
easier that hte problem is in own software that is broken.

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

Yes, we can. You offerred me to send the code, so do that and I'll apply
this to MiNT then release a pre-PL 7 beta (as I already wanted to do even
without STiNGs problems) for anyone to test. But better be quick with
that, because MiNT 1.14.7 is very close to release.

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

Buffff.... do you realize how much work is this?

>I might agree, but this is really such a simple thing ...

Positioning STiNG after MiNT in the AUTO folder is even more simple, and
for sure a lot of more safe.

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

Where this "deadlock" occurs? You were theoretizing a lot about program A
what needed to be started after MiNT, but wanted to have a driver B
started before MINT, which can't be started there etc, but could you give
a *reasonable exaple of any software* which is *impossible* to start with
MiNT due to that problem? 

K.