[Coco] Drivewire on Windows Vista?

[Christopher Smith]

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