Re: standard file extensions for exported apple dos files ?

[Andy McFadden <fadden@fadden.com>]

Jonno Downes <jonnosan@gmail.com> wrote:
> I want to record just the file type (not the auxtype), for DOS 3.3
> (not ProDOS) files, and I want the host file system to be able to
> identify the file type so specific actions can be taken on it (e.g.
> launch it in an emulator when double clicked). I can see some of this
> is touched on in the discussion of "extended" mode, but there's
> nothing specificly there I can see for handling the case of files that
> are meant to be BRUNed - doing so would require the use of a file
> extension that is specifically understood by the host file system, and
> that doesn't seem to exist yet, hence my original question.

Ah, now I understand.

I think there are a couple of approaches:

(1) provide a unique file type for "launchable" Apple II stuff, as you
    suggested;
(2) use a Windows shortcut with a "startup" argument defined.

If you use #2, you can leave the files stored inside the disk image and
use the usual disk-image-launch mechanism, and the emulator will see the
arguments and open the appropriate disk image and start the file inside.

For example, if you create a shortcut to CiderPress, then right-click on
it and select Properties then the Shortcut tab, you'll see the "Target"
field, which will be something like

  "C:\Program Files\faddenSoft\CiderPress\CiderPress.exe"

If you change that to:

  "C:\Program Files\faddenSoft\CiderPress\CiderPress.exe" "C:\foo.po"

then it will open C:\foo.po automatically when it starts.  To do what
you want, you'd need a third argument that specifies which file inside
the disk image you want to open.

This requires some work in an emulator, but probably no more than you would
need to create a temporary disk image, copy the file from Windows onto it,
and start it up in the emulator.  It has the advantage that you can still
launch something that is split into separate code/data files (like a basic
program with shape tables).  You still have one file visible and directly
usable from Windows, but now it's a shortcut instead of the Apple II data.


> Sorry I can see I wasn't very clear. The data I was referring to is
> the load address - it looks like it's possible to end up with the load
> address being both encoded in the filename and also as the first 2
> bytes of the exported file (I know this would not be the case for
> ProDOS files where load address is stored in the auxtype not in the
> file data, but as I say my specific interest is DOS 3.3 binary files).

It looks like you will end up with two copies -- CiderPress only does the
DOS<->ProDOS conversion when transferring between volumes, not when adding
or extracting to/from Windows -- so you'll have to pick one or the other
to give priority to.  You may want to stick with the one inside the file
so that you get the same behavior if you add the file back to a disk image,
but OTOH using the one from the filename makes it easy to change the load
address of the file.

-- 
Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/