RE: [MiNT] MetaDOS compatibility broken (fwd)

["Julian Reschke" <reschke@muenster.de>]

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Martin-Eric Racine
> Sent: Friday, June 18, 1999 8:04 PM
> To: MiNT List
> Subject: RE: [MiNT] MetaDOS compatibility broken (fwd)
>
>
> ---------- Forwarded message ----------
> Date: Thu, 17 Jun 1999 10:35:14 +0200 (MET DST)
> From: Ronald Andersson <dlanor@oden.se>
> To: q-funk@pp.fishpool.com
> Subject: RE: [MiNT] MetaDOS compatibility broken (fwd)
>
> Hi Martin-Eric,
>
> Please forward the remainder of this mail so it reaches those it concerns.
> (Not just Julian, but the others too.)
>
> Hi again Julian,
>
> Julian Reschke wrote:
> >
> >Well.
> >
> >MiNT never has been really "compatible" with MetaDOS -- at least
> not to the
> >extent that Ronald would like to see.
>
> That is perfectly true.  MiNT itself does not follow the rules established
> for how TOS enhancers should link themselves to older parts of the system.

MiNT is not a TOS "enhancer"; it is a new kernel.

> This means that other enhancers too can get blocked, and the view held by
> some MiNT contributors, that MiNT is so good that nothing else is ever
> needed or even wanted, that is simply not realistic.

I'd like to challenge that in the context of DOS drivers. Please give an
example of an existing DOS driver which implements things that you currently
don't have under MiNT.

> MiNT may be good, but other things can be good too, and they can't all be
> incorporated into MiNT.  (Would anyone like a 10MB kernel ?  ;-)

This is why MiNT is extensible through loadable drivers.

> But even so, all MiNT versions up to and including FreeMiNT 1.15.0 have
> always remained sufficiently compatible to allow access to MetaDOS drives.
> With FreeMiNT 1.15.1 this changed, so that no access at all is possible.

Well, as I said this is probably caused by running a kernel without the
old-style TOSFS which you need to "pass through". Whether it's in or not is
a compile time switch.

> >However it *is* compatible with
> >MetaXBS, which allows to install a CDROM BOS driver, and to access this
> >driver through an XFS.
>
> Let us say rather that MiNT 1.15.1 is not at all compatible to MetaXBS,

Yes it is. MiNT passes unknown XBIOS calls down, and MetaXBS can process
them. I assume that THIS did not change, as it would  break SPIN.

> but your SPIN.XFS is compatible to it and can therefore use its BOS
> drivers, together with either of two different specific DOS drivers.
> (But not with any others.)

SPIN.XFS does not use DOS drivers at all (it only takes the entries from
CONFIG.SYS to find the drive letter assignments).

> I am not criticising this approach of yours for your XFS.  It is one way
> to try to improve an intolerable situation of growing MiNT
> incompatibility.

Please give a real example where MiNT's behaviour actually causes problems
that can't be solved by using the right loadable MiNT module instead...

> And for the special purpose it is intended for, SPIN does succeed.
>
> But the result it achieves is naturally limited, as only a rewrite of the
> compatibility-blocking code in MiNT can improve the situation generally.
>
>
> >What might have happened is that if you install MetaDOS or BetaDOS before
> >MiNT, you have access to the CD filesystem through the old TOSFS.
>
> Yes, of course, that is how it should work, except that the TOSFS is not
> really involved at all, as the MetaDOS/BetaDOS dispatchers are installed
> 'on top' of the TOS dispatchers, so for a drive handled by a DOS driver
> (with or without any BOS driver), the call never reaches the TOS routines.

Yes, but it must go through TOSFS, which is (was) MiNT's internal XFS which
passes GEMDOS calls down to the "old" GEMDOS.

> >If this is disabled (and replaced ny the NEWFATFS), this
> pass-through simply
> >does not work.
>
> But in the new MiNT 1.15.1, that is not an option. The driver completely
> replaces the old one, incorporating all work needed for normal FAT drives,
> which is perfectly ok in my opinion too.  That is perfectly valid.
>
> Their error lies in that when a GEMDOS dispatcher is installed on top of
> others, like MiNT's dispatcher is installed, then it has an obligation to
> pass unrecognized calls, or calls for unrecognized devices, downwards to
> the GEMDOS layers 'below' itself, since those may have implemented such
> calls or devices.  That is what MiNT now completely neglects.
> (It has long neglected passing newer functions down.)

I don't agree. Just passing down the calls would never work fully. For
instance, Fselect(), input/output redirection or the links in drive U: could
never work with this approach.

MiNT simply needs more information about the drive, and just passing through
calls would not be good enough. So why add a workaround with limited
functionality, when the XFS interface actually solves all the problems in a
well defined way?

And if you really think that MiNT needs to support this, you are of cause
free to take the TOSFS source, make it a loadable XFS and add all the stuff
you want.

> When I want to open a directory (for example) on X: (my CD-ROM), and that
> drive is not recognized by any driver loaded by MiNT, then it should pass
> the GEMDOS calls for that drive to the 'lower' layers.  That is where the
> MetaDOS or BetaDOS dispatcher is installed and it will then handle the
> access.  I see no sensible reason to block this functionality.

There are lots of possible solutions, none of which requires changes to
MiNT:

a) use SPIN.XFS -- that's why it has been written,

b) use a MiNT kernel where TOSFS is enabled,

c) write a new loadable XFS based on TOSFS, adding all the stuff you want.