Jun 93 Tidbits
|Column Tag:||Tips & Tidbits
Tips & Tidbits
By Neil Ticktin, Editor-in-Chief
This column is your opportunity to spread the word about little bits of information that you find out about. These tidbits can be programming related or they can be user tips that are particularly useful to programmers.
MacTech Magazine will pay $25 for every tip used, and $50 for the Tip of the Month. Or you can take your award in orders or subscriptions.
To submit a tip, send in a letter to the magazine. E-mail is our preferred method, but feel free to send something via the US Mail. See page two for all addresses. If you do send snail mail, enclose a printed copy and a disk copy of the letter so that it does not have to be retyped.
Tip of the month
Ira Ruben has written a useful code disassembler for ResEdit. However, it has drawbacks - in particular, its not very intelligent about handling data interspersed with the code (such as embedded string literals). Also, you cant invoke it on just any resource type: if you come across a new type of code-containing resource (such as those AINI resources that System 7 uses), you have to modify ResEdit to be able to disassemble the new resource type.
MacsBug has much nicer disassembly facilities, and you can dump out different bits of memory using different formats if you choose. Wouldnt it be nice if you could use these facilities on resources you were examining with ResEdit? Well, you can!
First of all, open the resource you want to examine with ResEdit. Make sure the resource is open for editing in a window (using any available editor - even the hex editor). Now, hold down the mouse button over ResEdits menu bar (an unused portion is best), and with your other hand, hit the interrupt button (or keyboard interrupt sequence) to get into MacsBug. Once youre in MacsBug, you can let go of the mouse button.
Check the CurApName on the left of MacsBugs display, to make sure youre in ResEdit (it will be in the middle of calling MenuSelect). Now type
(replace AINI with whatever the type of the resource is that you want to examine). You will get a list of all resources of that type in the current heap zone, along with their starting addresses, lengths, resource IDs and names, and the refnum of the file they come from. Look for the one with the right ID or name. If you want to make sure youve got the right one, you can also use the command
(replacing <refnum> with whatever the file refnum is for that resource) to make sure that the resource comes from the right file. Now youre free to use commands like il and dm to examine bits of that resource.
If youre making patches to code, you can use MacsBugs dh command to check that youve got the right instruction words before making the modifications. Also, if you make any changes to a resource in ResEdits hex editor, you can go into MacsBug and disassemble that resource, and examine the effects of your changes immediately, before you save them.
- Lawrence DOliveiro
University of Waikato
Hamilton, New Zealand
MPW as a Real Language
I though that I would write in on How MPW scripts can perform tasks that might otherwise require you to code in a "real" computer language. In the past few years, I've had to answer many users' questions on MPW, and I've accumulated a supply of interesting scripts and techniques. As an example, I could have answered Mike Scanlin's March Programmers' Challenge (count unique words) with this script:
`GetFilename -t TEXT -b Count -m "UNIQUE WORD COUNT"` ;
Translate "A-Z ,." a-zn |
Sort -unique |
Count -l` - 1
Obviously, this entry doesnt qualify because it is not in C, but it is yet another demonstration of MPW's power.
- Lee D. Rimar, Absoft
Source and Line info
After reading the tip of the month in the May issue, I thought others might like to see what I use for debug formatting. It has the same benefits as the DebugFStr routine (i.e., formatted output), but adds automatic source file and line number information to the debug output. Using the routine is identical to using printf, except it is now called dprintf. The dprintf routine itself is actually a macro that invokes one routine to store the caller's file name and line number, then calls the actual output routine.
To use dprintf, include dprintf.h in any files that use it, and make sure you've added ANSI or ANSI-small to your project. Call it anywhere just like you'd call printf.
/*-------- dprintf.h ---------*/
#define dprintf dprintf_setup(__FILE__,__LINE__), dprintf_output
extern int dprintf_setup(const char *file, int line);
extern int dprintf_output(const char *fmt, ...);
/*-------- dprintf.c ---------*/
static int d_line;
static char d_file;
dprintf_setup(const char *file, int line)
d_line = line;
strncpy(d_file, file, sizeof(d_file));
d_file[sizeof(d_file)-1] = 0;
dprintf_output(const char *fmt, ...)
sprintf(buf, "%s %d: ", d_file, d_line);
vsprintf(buf + strlen(buf), fmt, ap);
- Mark Nagel
System 7 FindFolder
There is a neat little function in System 7 called FindFolder(). It lets you find important system folders with little effort. I used it to find the preferences folder into which I placed my own folder. This worked fine under MacOS. I had a nice little combination of FindFolder(), FSOpen() and Create() calls. The problem begins with the A/UX way of seeing directories. These are more like Unix than Apple folders.
A/UX preferences folder = /mac/sys/System Folder/Preferences
Mac preferences folder = System Folder:Preferences
The A/UX path as presented is what FindFolder() returns. Unfortunately this does not work as a path for older Mac function calls. All the PB, PBH and other pre-System 7 calls do not understand this. to use this format directly you need to do either a) or b):
a) Use the FSSpec type of calls everywhere, which works very well after you get used to them; or b) Convert all your paths to the following:
A/UX FindFolder() gives:
The key here being the '/:' at the beginning.
[Remember to keep them cards and letters coming. The more entries, the better the entries. - Ed.]