One of the least heralded new features of System 7, but nonetheless a very important
one, is full support for faceless background applications (FBAs). An FBA is a
full-fledged application that's invisible to the user. It has its own event loop, and it
receives time and some events like any other application, but it doesn't have a menu
bar, windows, dialogs, or other graphic components. An FBA is a normal file of type
'APPL'.
FBAs are, by a stretch of the imagination, similar to UNIX® daemons. The purpose of
an FBA is to provide services to other applications or to monitor the system. For
instance, an application that periodically checks your hard drive for files that haven't
been backed up lately is a perfect candidate for FBA status. Thus, an FBA can be a silent
partner to your application, INIT, cdev, desk accessory, or driver.
An FBA is the best way to provide certain services. For example, an FBA paired with a
desk accessory can enable the DA to send Apple events, something a DA cannot usually
do. (See the AECDEV/AEDAEMON sample in the snippets provided with the DTS Sample
Code on theDeveloper CD Series disc.) An FBA can replace an INIT that patches traps to
get time and provides services, or it can replace a driver that depended on periodic run
messages to operate. Converting to an FBA not only frees you from having to patch to
get the time you need, but also gives you a fully supported and documented interface
and design. You get all the advantages of a full application, without the overhead of a
user interface.
An FBA can also be an application manager for a suite of applications. With an FBA, you
can control the launching of and communication between applications, using
LaunchApplication and Apple events.
Writing an FBA is simple. An FBA is a subset of a standard Macintosh application,
consisting of a minimal event loop and the code to handle two types of events, null
events and high-level events. No other events are sent to an FBA. This makes a great
deal of sense, since every other event (keystroke, mouse click, and such) is designed
for foreground applications.
The SmallDaemon backgrounder shell included on theDeveloper CD Series disc shows
just how simple the basics of an FBA are:
Boolean gQuit = false;
EventRecord gERecord;
unsigned long gMySleep = 50000; /* A long, long time */
main()
{
/* Routine for installing my Apple event handlers.
Need to install the four required
handlers, plus handlers for any other events
I want to accept. */
InitAEStuff();
while (gQuit == false) {
/* A normal call to WaitNextEvent. I want
only highLevelEvents, since all other
events relate to interface actions, and I
have no interface. */
if (WaitNextEvent(highLevelEventMask, &gERecord, gMySleep,
0)) {
/* I'll get only null and high-level events. */
switch (gERecord.what) {
case nullEvent:
/* No null processing in this sample. */
break;
case kHighLevelEvent:
/* Get a high-level event (an Apple event) and process */
/* it. */
DoHighLevel(&gERecord);
break;
}
}
}
}
As you can see, there's not much there. The first thing you'll notice is that an FBA
doesn't start up any managers. All the managers you normally start are based on user
interface actions. Thus, they should not be called in an FBA--in fact, calling them will
cause your FBA to crash. There's one exception to this rule: you can initialize
QuickDraw, butonly to provide yourself with off-screen grafPorts or to use some
QuickDraw functions. Do not do any actual screen drawing from an FBA.
You'll also notice that you don't pass a mouse region to WaitNextEvent. That's obvious,
since you're never in the foreground and have no windows or mouse control to track.
And the only events you'll be handling are null events and high-level events (Apple
events).
The next step is to make sure the system knows that you're a background-only
application. You do this with a SIZE resource, by setting the canBackground and
onlyBackground bits to true. When the Finder launches your FBA, it checks these bits
and finds that you're a background-only application.
Some tips and techniques to keep in mind:
For further information and help with writing an FBA, refer to the Process Manager
chapter ofInside Macintosh Volume VI. Then try it--you'll like it!
C. K. HAUN has been programming Apple computers since 1979, writing
commercial education, utility, and game applications for the Apple II, IIGS, and
Macintosh, with some occasional dark forays into the Big Blue world. (It paid the
rent.) He currently works in Developer Technical Support and focuses mainly on
Apple events and the Edition Manager. Besides working to provide the best possible
support to developers, he's been trying to organize the Silicon Valley chapter of Heck's
Moofers, a motorcycle club devoted to the precept that computer nerds on bikes can
raise heck too, darn it. And yes, that really is his mustache.*