Re: Questions on EDASM reloc ($FE) files

["mdj" <mdj.mdj@gmail.com>]

John B. Matthews wrote:

> Indeed, the huge variety of subtypes in LBR ($E0) can be a problem when
> the metadata gets lost in transit.

That's true, which is why the rest of the computing world has ignored
filesystem metadata in preference of naming convention. I always liked
the metadata approach, assuming that
there was still a way to deduce a files type from it's contents, which
unfortunately on the
Apple II isn't the case very often. But then, the metadata in
SOS/ProDOS is there precisely for that reason, so limited machine
resources don't need to be consumed on validating a file.

I agree that it's safe in  practice... nobody is going to be RLOADing a
REL module that they either didn't assemble themselves or know exactly
what it is - it's a use case that just will not occur. But, the
computer scientist in me says, no, that's currently a unique identifier
for EDASM REL files, and reusing it defeats it's purpose.

If I had a dollar for every hour of computing time/my time I've had to
'waste' by resorting to temporal inference or even some more obscure
and approximate heuristic to establish the uniqueness of some data
entity, simply because somebody decided to reuse defunct identifiers,
I'd be a very wealthy man.

I know, I know, it really doesn't 'matter' in this case, but then, it
mattered enough to discuss it. The benefits of doing it right mean we
absolutely don't break anything for anyone, cc65 will have it's own
recognisable type, and the historical record of SOS/ProDOS filetype
assignment will be preserved. To me, it's worthwhile simply for reasons
of nostalgia.

While we're on nostalgia, there appears to not be a technote to
describe the EDASM file format for REL. Somebody who knows the guts or
has the documentation should write one and submit it.

> EDASM is one of the original wastrels. It uses the auxiliary type for
> origin metadata, so it appears to "own" the entire REL ($FE) type. In
> practice, EDASM declines to generate a REL file with auxiliary type in
> the range $0000-$00FF. Although the related RLOAD tool doesn't reject
> auxiliary types in this range, I would consider the range open.

Oh yes, but this one pales in comparison to AppleWorks. 3(!) primary
filetypes gone, and the aux word used to (quite cleverly) allow
filenames to appear to contain spaces and lowercase letters. Ironic
considering that this 'limitation' is both arbitrarily imposed, and
very easily defeated :-)

I'm hopeful that metadata in filesystems will make a comeback soon, and
Apple appears to be leading the way here. Spotlight computes
interesting metadata about files from their content and stores it as
extended attributes, and follows established metadata standards in
doing so. Kudos to them. Unfortunately, the other company will
undoubtedly come up with something equivalent in functionality but
totally incompatible with the rest of the know world.

It's most amusing to be having this conversation in 2006, but it's fun.
Good to have the dialogue and establish a consensus on the 'right' way
to go, even if it no longer really matters.

Matt