Lesson 2. Writing Executable Code.
An executable code resource is easy to create with a good
software-development application such as THINK C (or C++) or THINK Pascal or MPW. There
are slight differences between the environments, but nothing major. I will be giving
examples for code written in THINK C, for that is the system I use.
An executable code resource usually starts with a
void main(void)
and within such, your executable code exists. Note, as always, that executable code cannot
handle global variables (variables defined above the definition of the main code,
accessible by the whole file/project). THINK C handles ways around this, and MPW uses the
methods in Tech Note #256, but in most cases, you won't really need global variables,
unless the code is complex enough to require separate procedures and/or object-oriented
code. In any case, you can usually define your variables inside the main procedure itself.
There aren't too many rules as far as writing code resources, so long as you know under
which circumstances your code will be called. If you are patching a Toolbox trap, for
example, you must take the same form as the patch you are trapping:
void ModalDialogPatch(ProcPtr procFilter,int *itemHit)
If you are patching an operating system trap, you need to do some register playing, but
you need to take an empty procedure form:
void OpenPatch(void)
even though the FSOpen, PBOpen, etc. take paramBlocks. Note: they are stored in registers
A0, D0, and A1 usually. Check the trap for specifics. You need to save these before you
execute your code, and then restore them upon return.
If you are executing code that is to be run as a VBL or Time Manager task, always remember
that you cannot use code that even thinks about using the Memory Manager (i.e. moves or
purges memory). Make sure all the toolbox calls you use are not in the 'dreaded list' in
the appendix of each volume of Inside Macintosh.
The type of the code resource is very dependent upon which method you wish to use to get
your code executed. Read the next section for details on such execution theories.
After you're done writing the code, check it over for simple things you might have
forgotten (original Quickdraw compatibility, system versions, etc.), and compile the
sucker. For right now, you can throw the code resource into some sort of test file (or
stagnant file, where the code will not be executed and/or reproduce). Note that you should
NOT have any external resource files to compile along with it. Code resources such as this
should preferably be self-contained, and not have to 'carry around the extra luggage', so
to speak. There are methods to carry along bitmaps (as 'unknown data') and use them as
graphics. But you should never rely on things like GetNewDialog, because that requires the
existence of a DITL resource. Instead, use calls like NewDialog, where the code builds the
relevant information in. It might make things harder to read and a bit harder to edit, but
it's what you have to do in order to make everything self-contained.
Most of the compilers create some sort of header at the beginning of each executable code
resource. This header could give away some vital information about the resource which
would make it easy for a virus-detector to find. Double check it after compilation to make
sure it's clean and doesn't look suspicious.