Re: Questions on EDASM reloc ($FE) files

["John B. Matthews" <nospam@nospam.com>]

In article <JbadncanU4w_OafZnZ2dnUVZ_v-dnZ2d@comcast.com>,
 "Michael J. Mahon" <mjmahon@aol.com> wrote:

> John B. Matthews wrote:
> > In article <voOdnfM3qdn3YqTZnZ2dneKdnZydnZ2d@comcast.com>,
> >  "Michael J. Mahon" <mjmahon@aol.com> wrote:
> > 
> > 
> >>John B. Matthews wrote:
> >>
> >>>Contiki could check the auxiliary type for validity, while existing 
> >>>EDASM RLOAD wouldn't need to do anything different. I would advocate 
> >>>choosing an auxiliary type that would be an unlikely ORG of a 
> >>>relocatable segment: e.g. $FFFF.
> >>
> >>That would be a good choice if the assembler can be convinced, but I
> >>think it's REL file format is already settled.  At this point, it would
> >>just be up to the "consuming" programs to check for what they expect.
> >>It seems likely that any "loader" program would do some validity checks,
> >>since they have the potential to overwrite almost anything if they work
> >>"blindly".
> > 
> > 
> > Indeed. The RLOAD program checks the file type, which presumably was 
> > created by EDASM, not Contiki:-) The question is how to use the REL file 
> > type for two different formats without requiring a change to the 
> > existing tools that use the type.
> 
> I agree, moderated by the probablity that any real confusion would
> ever occur in practice.

I agree the probability is low. The user would have to mistake a Contiki 
REL file for a EDASM REL file and proceed to write code to abuse the 
Contiki file.

> > Empirically, when EDASM creates a REL ($FE) file, it sets the auxiliary 
> > type to the value of the (last) ORG directive. As described in Appendix 
> > E of the ProDOS Assembler Tools manual, the file includes the code 
> > length, the code itself and an appended relocation dictionary. At 
> > runtime, RLOAD lowers HIMEM and loads the relocatable file. It uses the 
> > auxiliary type and the relocation dictionary to relocate the code. 
> > 
> > The auxiliary type is used by RLOAD as the base address for relocation. 
> > In the worst case scenario, a user would have to mistakenly use RLOAD 
> > (via USR(0)) on a Contiki REL file. The result is hard to predict. A 
> > cursory look suggests that RLOAD would "relocate" a single byte and 
> > return its address, depending on the value of mode.
> 
> So RLOAD contains no "reasonableness" checks on the file's contents?
> Even so, the result you describe seems relatively benign (compared
> to BRUNning a .GIF file ;-).

Not at all. RLOAD assiduously checks for the correct file type. Since it 
owns the type and EDASM produces no output for erroneous input, it 
reasonably assumes that the REL file contains relocation data in a 
familiar format. It seems unfair to criticize RLOAD for not rejecting a 
forged file type. :-)

> I've implemented a few linker/loaders in the past, and the relocation
> and external fixup data streams were complex enough to warrant some
> validity checking, even if only to confirm that the "producer" got it
> right.  Ah, but the micro world was a "restart" of our computer
> experience, as I recall...

Indeed: EDASM's RBOOT/RLOAD mechanism is just a relocating loader. It 
doesn't resolve external references, although the data is present in the 
relocation dictionary. In practice, conserving memory with the 
relocating loader was valuable in itself.

> > While the "right" answer is not to recycle the type at all, that surely 
> > is overly restrictive. Because an auxiliary type must be defined when 
> > the file is created, it only makes sense to choose the auxiliary type 
> > that is least likely to break existing code. In practice, EDASM forbids 
> > using an ORG < $100 for a relocatable file, so an auxiliary type of 
> > $0000 would be a reasonable alternative.
> 
> I agree with you in principle, John, but there is now so little new
> development in the Apple II world that hijacking a rarely used file
> type doesn't bother me much, particularly when the potential for
> mischief is so remote.  (How many REL files are available for
> download, I wonder?  And how many current users would know what
> to do with them if they were?)

I agree that "the potential for mischief is so remote," but I'm less 
comfortable with "saying it's a "a rarely used file type." Most of the 
registered file types are rarely used, except by the people who use 
them:-)

<http://web.pdx.edu/~heiss/technotes/ftyp/ft.about.html>

> And the "REL file" proposed for Contiki use--a *very* limited use--
> is already defined as the relocatable file format for the cc65
> cross-platform assembler, which is more influenced by the C=64 than
> by Apple conventions.
> 
> It appears that the first five bytes of a cc65 "REL" file are
> $01 $00 $6F $36 $35, and I don't know how the file is stored
> (filetype and auxtype) on an Apple system.  Since it's a cross
> assembler, perhaps when the file is moved to an Apple II, the
> mover has complete freedom in assigning an auxtype.

Whatever program creates the file must specify its auxiliary type at the 
same time it specifies its type. Based on what I've learned so far, I'm 
inclined to advocate a number in the $0000-$00FF range. Zero is 
appealing, but I'd like to hear if anyone sees a reason to use something 
else.

> As I see it, the risk of undesired effects is so small, and the
> convenience factor is sufficiently high, that re-purposing REL for
> Contiki seems acceptable.
> 
> The file typing system on the Apple II, even as extended by ProDOS,
> is relatively weak.

Well, it's 24 bits for a total of 16777216 types. I don't think there is 
a way to register new types.

> The designers of ProDOS recognized this when
> they made it possible to BLOAD and BSAVE from/to any file type, to
> make general tools more useful.

Also to make it easier to write general tools in Basic.

> There are many more "typed" files now in the world, even the Apple II
> world, than Apple "allocated".  The vast majority of these files are
> stored as "BIN" files, and the actual "typing" resides outside the
> file system as file naming conventions and programmed validity checks.
> 
> This is a case in which the PC convention of associating file types
> solely with a naming convention has proven more adaptable and robust,
> particularly in the absence of a central type control authority.

OT: Wouldn't three printable characters provide just 64^3 = 262144 
combinations? I thought Windows was fraught with collisions.

> -michael
[...]
-- 
John
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/