RE: [MiNT] MetaDOS compatibility broken (fwd)

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

> From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> Of Jo-Even.Skarstein@gjensidige.no
> Sent: Friday, June 25, 1999 10:31 AM
> To: mint@fishpool.com
> Subject: FW: [MiNT] MetaDOS compatibility broken (fwd)
>
>
> Hi!
>
> I'm forwarding some interesting remarks from a private discussion between
> Ronald Andersson and myself.
>
> Jo Even Skarstein
>
> > -----Original Message-----
> > From:	dlanor@oden.se [SMTP:dlanor@oden.se]
> > Sent:	Thursday, June 24, 1999 10:10 PM
> > To:	Jo-Even.Skarstein@gjensidige.no
> > Subject:	RE: [MiNT] MetaDOS compatibility broken (fwd)
> >
> > Here follows a fairly comprehensive description of what I consider to be
> > the
> > necessary 'linking' for what I see as TOS compatibility, together with a
> > new
> > method to implement that in MiNT, such that no MiNT
> capabilities are lost
> > or
> > in any way downgraded. If you think this would interest MiNT people, you
> > are
> > naturally free to forward it to them:
> >
> > 1: When a file or drive function known to MiNT, but addressing a drive
> > that is
> >    not known to internal drivers (or loaded XFS drivers) then
> MiNT should
> > pass
> >    control to some underlying dispatcher.  As MiNT does
> implement drivers
> > for
> >    all drives known to normal TOS, it will never be normal TOS
> that deals
> > with
> >    such an access, but will always be some other dispatcher that has
> > logged in
> >    to the XBRA chain between TOS and MiNT.  Naturally MiNT may
> first check
> > if
> >    any bit in the system variable '_drvbits' ($4C2) has been set that
> > matches
> >    the specified drive, as it is not necessary to 'link down' otherwise.
> > That
> >    will make MiNT work fine with BetaDOS (or other MetaDOS) and
> yet retain
> > all
> >    positive qualities for all MiNT-level drivers, including error
> > reporting
> >    capability for access attempts to drives not implemented by any
> > dispatcher.

1) Actually, checking _drvbits would be wrong here. _drvbits indicates
whether a drive is known by BIOS. To find out whether there is GEMDOS
support for that drive, you need to do a Dsetdrv(Dgetdrv()).

2) No, MiNT should not do this. Everything Ronald is asking for here can be
done in a separate, loadable XFS in case somebody really needs it. I'd still
like to see a use case, though. I am not aware of any useful (!) MetaDOS
filesystem driver that doesn't have a similar or better MiNT XFS
counterpart.

> > 2: When a gemdos function is not known to MiNT at all, it should always
> > pass
> >    the call down some underlying dispatcher that may have
> implemented it.
> > If
> >    such a call reaches the TOS gemdos dispatcher, then the only result
> > will
> >    be the return of an E_INVFN error value, which is identical to what
> > MiNT
> >    too must return for such cases.  The only problem with this is if
> > another
> >    similar call is made by another task, switched to while TOS
> gemdos work
> >    is in progress.  A solution for all such problems is given further
> > below.
> >    The 'linking down' for unknown functions will allow other
> dispatchers,
> >    such as the one of BetaDOS, to add new functions (eg: MagiC 6 type
> > SLBs)
> >    to maximize compatibility with other systems of the TOS platform,
> > without
> >    requiring all such things to be incorporated into MiNT.

Again, I don't see the use case. The example mentions shared libraries,
which clearly can not be implemented by any layer "below" MiNT as MiNT owns
the free memory.

> > 3: Bios and Xbios functions should always be 'passed down', when they
> > concern
> >    anything that MiNT can not deal with completely.  There are many TOS
> > clone
> >    machines in existence, and it is necessary to allow patch programs to
> > fix
> >    compatibility problems. MiNT can never be expected to do it all
> > internally
> >    as the family of TOS machines is constantly growing.
> Another important
> >    aspect is that they often have conflicting needs, and trying
> to include
> >    code for all those needs in the kernel would make it ridiculously
> > large.

I agree, and this certainly happens for XBIOS, otherwise MetaXBS would not
work. However I am not sure about BIOS.

In general I see lots of areas where MiNT could be improved which would have
a much higher priority -- like shared libraries (see remark above), virtual
memory or reentrant dispatchers ultimately leading to background I/O. But
there's not much point in just asking -- the source is available to
everybody, and I am sure that Frank would welcome good contributions.