Lesson 2. Writing Executable Code.
Prev || Home || Next
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
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:
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.
Prev || Home || Next