[Coco] Drivewire on Windows Vista?

[S Klammer]

Not that it should be done; but, a database (or even just a text file)
could be used to maintain directory information for the Coco side that
would be independant of the underlying OS.  At startup (or queued) it could
scan the OS folder and, where needed, prompt the end-user for any
pertainent info for the Coco side and update accordingly.
On Sep 25, 2013 4:40 PM, "Christopher Smith" <csmith at wolfram.com> wrote:

>
>
> ----- Original Message -----
> > From: "Aaron Wolfe" <aawolfe at gmail.com>
> > To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> > Sent: Wednesday, September 25, 2013 3:12:02 PM
> > Subject: Re: [Coco] Drivewire on Windows Vista?
> >
> > On Wed, Sep 25, 2013 at 3:50 PM, Christopher Smith
> > <csmith at wolfram.com> wrote:
> > > Right, I'm thinking you'd basically have to fake the disk table of
> > > contents -- or whatever the thing is called on a CoCo disk -- and
> > > understand what data it wanted when it made requests for certain
> > > sectors.
> >
> > ignoring problems like the files changing on the PC side after we've
> > made up a FAT, it is still more complicated than that.
>
> Yes, moving files around when a disk operation is proceeding could be
> problematic.  You could help minimize this by holding handles open to all
> files of interest for a period of time.
>
> > Where is the info like the "file type" byte and the ascii/binary flag
> > coming from.. we just guess when we make a FAT?  Use underlying FS
> > attributes somehow?  Remember that DW runs on several different OSes
> > with even more filesystems beneath them.  What about case
> > sensitivity... a Linux system can have files called Run.BAS and
> > run.bas and RUN.BAS in the same directory... who wins?
>
> No, I wouldn't use filesystem attributes.  I'd try to detect the file
> type.  Start with the extension; if it contains non-ASCII and the extension
> is BAS (or something of the sort), it's tokenized basic.  If the extension
> is BAS, but the data is ASCII, it's ASCII basic.  .. I think it should be
> pretty safe to report non-ASCII data as binary.  All of this could probably
> be done by reading a machine-word or two out of the file and doing a quick
> analysis.  It wouldn't be bullet-proof, but for simple uses it may be fine.
>
> ... and I think I'd expect undefined behavior where names clash.  You
> could do something like dynamically rename (on the coco side) the files
> with similar names, but that would introduce a bit more complexity.
>
> > Writes are especially complex.. When a file grows, DECB chooses the
> > sector(s) to use itself.  We wouldn't know which file it was writing
> > to without parsing DECB's writes to the FAT and looking for which
> > cluster chain or whatever DECB calls it was modified, and I'm not
> > even
> > sure this modification occurs prior to the sector being written.  So
> > we might have to defer writes, watch the FAT, and then send them to
> > the file.   On top of that, there is no requirement for the FAT to be
> > updated at all, you can do arbitrary sector based read/write in DECB.
>
> Yes, that would be a problem.  Given the resources we have on a modern
> system, I'm sure it could be done.  I'm not sure I'd do it. :)
>
> Chris
>
> --
> Christopher Smith
> Systems Engineer, Wolfram Research
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>