Tue, 13 Nov 2007
I found this entry that I'd written 3 Aug. 2007, but never pressed the button to post for some reason.
And one other note on writing retro Mac programs in general. You have a
lot of freedom working on a dead system, because Apple isn't going to
update Classic Mac OS any more. For example, hiding the menu bar
involves fiddling with the
MBarHeight, both low-memory
global variables. (Both of which I accessed through accessors, but
they're still lowmem globals.) Apple finally, round about Mac OS 8.5,
ShowMenuBar system routines. I could test
for their availability and use them if so, but why bother? The old way
works on 9.2.2, the last verion of Classic Mac OS, and the unnecessary
test just adds complexity.
You shouldn't take that approach on a live system (the old way, of course, stopped working entirely on OS X), but on a dead system, you can bend the rules a little more because you know things won't change.
Of course, you still need to look at the circumstances your program will be used in and be a good citizen. Classic Mac OS is dead in that there's no further development from Apple, but it's still very much alive in that it's being used by many people. On a Plus, I basically try to get as much CPU time as I can because the routines to draw the clock take a while on a 68000 and I want to be sure that updates are smooth. And on a 68000 system, you typically aren't going to have any other processes going while the clock is up, so it's not unfriendly.
That approach on a modern system just hordes the CPU unnecessarily, and, on a G4 or G5 (especially in Classic mode), probably wastes energy by defeating some of the power-saving measures built into those systems. So I do check for the 68000 case specially, and only run flat-out on a real 68000, allowing the program to sleep for split-second chunks of time on faster processors.
This project has been a wonderful opportunity to geek out in the magical land of Classic Mac OS.