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.*
