Re: [MiNT] MiNT and MetaDOS

[Jo Even Skarstein <jo-even.skarstein@stryn.online.no>]

Martin-Eric wrote:

> See previous osts by myself and Kellis, over the last few months.

I can only remember one post right now, and that was Kellis
explaining a problem with GFA-basic.

> _Many_ applications don't like FATFS _and_ ext2, probably because
> they are processed through the same "new and improved generic XFS
> interface."

The XFS-interface has absolutely nothing to do with how
applications interact with the filesystem. It's all handled
by two different APIs, the normal unix-like API (Dreaddir etc) and the old GEMDOS-interface (DTA, Fsfirst/Fsnext etc). The behaviour of these is also dependant on which
domain the applications run in.

If there are problems that shows up on FATFS and other filesystems except TOSFS that suggests two things, atleast
for my simple brain:

1. The application in question does not run in the
   MiNT-domain, and it use the old GEMDOS-interface.
2. MiNT does not emulate the old GEMDOS-interface closely
   enough.

In some cases (2) is expected (like ext2, where Frank has
said that he won't support this), but FATFS is supposed to
work so there's probably a bug somewhere. What you do then
is to boot with a debug-kernel (1), run the problematic app
and either attempt to fix the bug yourself or mail a
bug-report to this list. Otherwise there's no way this can
be resolved.

Personally I haven't seen any apps that fails on TOSFS, but
then I don't use many real old apps anyway.

> > This can only be caused by bugs in the AES or bugs in the old
> > GEMDOS-interface in MiNT. This is no reason to keep TOSFS.
> 
> MiNT 1.15.5 and N.AES 2.0 both say your assumptions on my
> configuration are wrong.  Besides, if an application stops

So you're saying that 1.15.5 is bug-free? Then what's the
problem? ;-)

The reason I mentioned the AES is that you explicitly said
that applications had problems finding their RSC-file, which
indicate that the problem might be assumptions in the AES'
implementation of rsrc_load(). I know that MultiTOS' AES 4.0
and 4.1 has problems in this area.

> working when running over a kernel without any TOSFS, the 
> cause _is_ rather clear:  missing TOSFS.

Definitely not. The problem is either that the application
in question is bugged (i.e. only works with TOSFS because
it use undocumented features) or that there's a problem
with the TOSFS-replacement. The solution is obvious: Find and fix that (possible) problem.

> But it still needs MetaDOS to support audio CD; it is _not_
> a completely standalone XFS.

By that definition you can't say that ext2fs, minixfs,
TOSFS or even good old TOS are standalone filesystems
either, since none of them has integrated hardware-drivers.

Jo Even Skarstein