[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help finding info on Apple 2 executables



In article <4vkp0l$ph7@news.aros.net>,
Lawrence Gold <gold@shell.aros.net> wrote:
>Could someone on here please direct me to a file describing the layout of 
>an Apple 2 executable file?  Specifically, the format of the header (if 
>any) and any information about where in memory the file is loaded, and 
>where execution begins.

   You're going to have to be a heck of a lot more specific than "an
Apple II executable file" if you want a more targeted answer. As I'm
going to demonstrate, there's no easy answer to all of this, and if you
want better information, it is in your best interest to 1) purchase the
manual (usually way bigger than an arbitrary file) on the OS version in
particular, 2) disassemble any file to be absolutely sure what the
heck it's doing.

   There are three main revisions of the OS for the Apple II, each
with its own variations:
 
DOS 3.x (x=.2, .2.1, or .3)
   Most binary programs (as opposed to Basic programs, which are
executable also, but have very different structures) are stored as
type 'B' on disk. This is a raw dump of memory plus a 4 byte header
saying where in memory it was saved from, and what its length is.
Execution for this and other Apple II formats, starts at the very
first program byte.

   Binary files can be easily loaded in and run at other addresses,
though, however no relocation is done. (In other words, the address
information could lie. This is a cheap method of copy protection;
you'd have to watch the calls to DOS to see where it was really being
loaded.) There's also the 'R' format, which is supposed to be program
written relocatably, i.e. with no hardcoded memory locations in it.

ProDOS 8
   Binary files now have type 'BIN', with the auxtype saying where
their address is. (And if you blindly transferred the files off
through a medium that doesn't preserve the ProDOS auxtype, you're
going to have a real hard time figuring out what it was originally.)
The length is also stored in the directory entry, so the 4 byte
header is no more. Once again, zero relocation information, and
the address information could be a lie. Watch where it ends up to
be sure.

   System files (type 'SYS') designed to be run automatically at boot
(name ending in .SYSTEM), are always loaded in at address $2000 before
being started. However, many can and do (the 'ProDOS' file is a prime
example) move themselves off to other memory locations by having most
of the code hardcoded for that address, and then a short boot stub
located at the start of the program to do the moving of the code to
that address, then run that. In other words, watch and see what the
heck the program does to be sure.

ProDOS 16, GS/OS
   'OMF' (Object Module Format) files (many filetypes and auxtypes)
allow things to be loaded in at any address; it consists of many
internal segments.  The description of OMF is _way_ too long to bother
to try and post here; your best bet is to get the GS/OS Reference
Manual (currently out of print, but check out
comp.sys.apple2.marketplace) and read the appendix on it. (Said
appendix is probably about 15+ pages, and not complete-- system 6.x
has a few new formats if I recall correctly.)

  Note that many OMF files are not designed to be run directly (such
as Toolsets, Desk Accessories, and the like); they have a header which
is particular to what they do, and contains entry point(s). Further,
in GS/OS 5.x and later, OMF files can be shoved into Resources, which
further complicates trying to get info from an arbitrary file later.

Nathan Mates


--
<*> Nathan Mates http://www.visi.com/~nathan/      <*>
# What are the facts? Again and again and again-- what are the _facts_?
# Shun wishful thinking, avoid opinion, care not what the neighbors
# think-- what are the facts, and to how many decimal places?  -R.A. Heinlein