Re: Unlinking vectors

[Jo Even Skarstein <joska@nuts.edu>]

On Thu, 12 Mar 1998, Peter Rottengatter wrote:

> > Actually, I know *one* case when MiNT is unlinking all installed vectors
> > arbitrarily. Namely, this is the case when MiNT quits. And this case
[...]
> Hmm, IMHO that's hardly sensible ? There may be a good reason for it (if
> someone knows it, please ...), but it's not very consequent, given the
> newer notion that MiNT should run first in the AUTO folder. It's sensible

Nobody has ever said that MiNT should run first in the AUTO-folder, that's
not realistic at all.

> only if programs could be divided into MiNT-supporting and not-MiNT-
> supporting, then the latter would run first, then MiNT, then the former
> programs. Then MiNT would unlink all stuff that "relies" on it when
> exiting.

Which is pretty much what's done today, by sorting the auto-folder.

> BTW.: MiNT was called an OS extension. Is it sensible in the first place
> that such a thing can terminate ? Probably yes, but only if it works

Yes, it's very sensible. It's quite possible to exit MiNT and work in TOS,
then restart MiNT from the desktop. Just like Geneva really.

> on the system carefully enough that a consistent state of the system can
> be restored. That calls for refraining from unlinking foreign handlers
> too.

It restores the system exactly as it were before MiNT ran. This includes
killing all childs and unlinking their handlers.

The original MiNT didn't run any programs after it in the auto-folder.
This feature was introduced by Atari when they released MultiTOS, and can
AFAIK still be #ifdef'ed in the current sources. You'd then have to start
all MiNT's childs from mint.cnf, which ensures that you can exit MiNT,
work in TOS and restart MiNT including all it's childs. That's also why
the original docs states that MiNT should be the very last program in the
auto-folder.


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