[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions on EDASM reloc ($FE) files
John B. Matthews wrote:
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.
Or vice versa...
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 understood that it knew the file was correctly typed. What I was
referring to is some further, or ongoing, check on the validity of
that file's contents. Assembler authors make mistakes, too! And
file corruption is also an issue. In short, if the file directs
the relocator to do something patently unreasonable, then it would
be reasonable for it to detect an error. ;-)
Microcomputer system programmers frequently assumed that data errors
never occur and their programs ploughed on senselessly. Mainframe and
Mini programmers tended to be a bit more suspicious of data errors,
often through rude experience. (Of course, more is at risk if much
data is on line and potentially vulnerable to corruption.)
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.
Many linking loaders allocated "BSS" or uninitialized storage over
themselves, so that they didn't actually "occupy space" in the way
of the program being loaded. They cleared the BSS memory space
just prior to giving control to the program.
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>
Yes, and I have often wondered about the value of this system that
no longer has a type allocator--and practically has no more types
to be allocated. ;-( It's a little like Ozymandias...
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.
That sounds very reasonable.
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.
Which, I think you would agree, is overkill as a pure type space.
(The documentation alone would be quite unmanageable. ;-)
In fact, the "aux type" is used as metadata by many file types
(including the REL type).
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.
Hear, hear! ;-)
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.
"Fraught" seems a bit exaggerated--it works quite well for most
people. There is a kind of market combat for some types--the most
popular program covers the land with *its* type, and thereby "wins".
But that is actually a pretty reasonable process for determining the
outcome. (.doc comes immediately to mind... ;-) Some are not so
much name space issues as warfare.
And surely, a quarter million file types is enough--until we start
expanding into the essentially unlimited .xxxxxxxx space presented
by the current file systems. Actually, I quite like making the
type of a file manifest in its name (as well as in its content).
-michael
Music synthesis for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."