RE: [MiNT] MetaDOS compatibility broken (fwd)

[Martin-Eric Racine <q-funk@pp.fishpool.com>]

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

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

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.


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

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


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

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.

-- 
-------------------------------------------------------------------------
Regards:  Ronald Andersson                  mailto:dlanor@ettnet.se
http://dlanor.atari.org/    ICQ:38857203    http://www.ettnet.se/~dlanor/
-------------------------------------------------------------------------