Mail To: Vassilis Papathanassiou <papval@otenet.gr>
Subject: Re: Source archives
----------------------------------------------------------------------------

Hi again Vassilis

>>Well, after seeing your obvious disappointment with Peter's response time,
>>I felt you needed something speedier to cheer you up...
>>
>I'm afraid 'Peter's response time' means 'never' for me :-) I hope i'll have
>better luck with Ethernet...

Yes, but don't feel shy about sending him a reminder occassionally.
Sooner or later he probably will send the stuff, he just needs some 'nagging'.

In fact there are some (rather unimportant) dialog sources I was promised
long ago which I still nag him about, with little result so far...  But in
the meantime he has sent me sources for TCP, the STinG kernel, and various
other stuff,  so there is no general secretiveness involved.


>>That will be great...  I am working on steady improvements of BetaDos and
>>its DOS filesystems, especially Cluster.Dos.  The latter now has functional
>>user defined symbolic links and the next stage will involve adding support
>>for long names with free casing.
>>
>Huh, i needed this also for the XFS (it has Dopendir AND fsfirst etc) so i
>needed a way to convert between the two. MagiC gives a path2DD (directory
>descriptor) though, so it makes things a little, hmm, easier.

'Hmm' indeed...
Easier for whoever has managed to absorb all the complex MagiC definitions
and declarations involved that is.  In other words, not easy at all...!

Still, at present the symbolic links of Cluster.Dos do work quite compatibly
with those of MagiC, with or without MagiC itself in the system, so I have
no complaints on that score.  MiNT compatibility is a bit trickier, because
the MiNT kernel interferes with functions intended for non-XFS filesystems.

Thus a function call like 'Fsymlink' directed at a BetaDos-type gemdos drive
never arrives in the device driver of that drive, because MiNT won't allow it.
(That is downright sick...  it should not interfere with non-XFS drives.)

Even so, for all 'normal' file/folder access I do have compatibility with MiNT
too, so I think I will leave this stuff as-is now.


NB: For most 'old-fashioned' functions, such as Fsfirst/Fsnext/Fattrib, the
    correct result for using a link should be the same as if using the path
    that the link 'points at'.  This is _not_ the case for two old functions
    though...  Both Fdelete and Ddelete must affect only the link itself,
    and not the object pointed to.  Thus 'Fdelete "V:\somelink"' should only
    remove the 'somelink' entry of the 'V:' root.  This applies to pure direct
    link reference only though, so if we have 'sln C:\DUMMY\ V:\SOMELINK'
    then 'Fdelete "v:\somelink\dumbfile.dmb"' deletes C:\DUMMY\DUMBFILE.DMB
    since this is not a 'pure' reference to the link name.

    Take great care if experimenting with this, because most desktops will
    insist on making a recursive delete on subdirectories if you attempt to
    remove a link by dragging it to the trashcan.  Usually the link will be
    removed, but not before all the data it 'points to' has been destroyed !!!

    I have made a super-simple tool program, called 'Kill_SLN.GTP' which
    just makes an 'Fdelete argpath' call, with 'argpath' being the path
    that was 'dropped' on its icon.  This is a good way to experiment with
    these functions, so you may want to make a similar tool yourself.


>>  That is a 'biggie', since the 'subdrives'
>>may (normally will) be a mixture of 'old_fashioned TOS' and 'longname' types,
>>so that longname support and case forcing will have to be simulated by the
>>Cluster.Dos driver for some of them.

That simulating part is not yet quite complete, but that is only of interest
with access programs that do not have any ability to fall back on Fsfirst/next
at all, such as MagXDesk.  All normal applications should have such ability,
and in fact MagXDesk is the only one I have seen that does not work this way.


>That was a great deal of work for the XFS also (and the main reason for the
>delay so far) but now i think i'm close. I've made lots of path tricks again
>but i hope this time its better than BNET's original.

I also 'interfere' with paths in BetaDos, so as to ensure that applications
are each allowed separate 'active' drives that may include BetaDos drives.
I don't really see why it was not so coded in the original code of either
standard TOS or MagiC though, since all drives existing should be legal to
use as 'active' drive (as per Dgetdrv/Dsetdrv).  The fact is that original
code did not allow non-standard drives to be used as 'active' drive, so I
had to change that. (above, 'standard drives' == hard_disk/floppy + XFS/U:)

This change also interacts with Dsetpath/Dgetpath, as well as (indirectly)
with all use of relative paths (so they expand correctly for all drives).


>>If you've missed that point, let me point out that Cluster.Dos then does all
>>of the things for local drives that a future BNet.Dos will need to do for the
>>remote drives...  Thus all it will take to make the latter work is to build
>>the linkage you have from your BNet.XFS to the BNet.APP into a copy of the
>>Cluster.Dos (replacing gemdos calls for local access) and we have a BNet.Dos !
>>
>I've changed this again ! (the linkage that is) Now BNET.APP installs a
>cookie (like STinG's tpl ) so the XFS finds it (when tou try to open the
>'bnet' drive for the first time) and then uses the BNET.APP functions.

Sounds just like what I had in mind, except for one thing...
It is not legal for an APP to install any cookie...

Let the XFS install the cookie, in an uninitialized form,
then let the APP modify that cookie into a usable form.
This way everything is legal...

Well, almost, as there should also be some way for the XFS to verify
that the APP has not been killed since modifying the cookie.
Otherwise a call through the cookie interface may bomb...!


>This (IMO) has two advantages: 1st the XFS stays 'clean' (so for example
>Peter can use it for the NFS (in it's XFS or DOS form)) and 2nd (and most
>important for now) i can use a debugger to see what the XFS is doing (it's
>unfortunately almost impossible to debug a running XFS and i'd love it if
>you could prove me wrong !)

No, I'm afraid I can't...
My own best trick is to debug BetaDos stuff under normal TOS, so I can use
AMON breakpoints, but that technique obviously won't work for MagiC XFS code.


>I hope this week BNET_XFS will be ready for first betatesting. Well, i'm
>going back to work with it.

Ok, I'm quite eager to see it, so I hope it will be ready (for testing) soon.
