BE OUR GUEST

BACKGROUND-ONLY APPLICATIONS IN SYSTEM 7

C. K. HAUN

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:

• Always remember that an FBA is invisible to the user. An FBA doesnot  show up in the Process menu or in the Finder About window. Also, its heap memory is added to the system size thermometer bar in the Finder About window, even though it has its own application heap. The user often will have no idea that it's running, so be friendly.
• Being friendly means yielding time. Have a very large sleep time when you're not actually doing some processing. If you don't, users will think that their machine has slowed down inexplicably. You can always use the new Process Manager call WakeUpProcess to get yourself back into fast processing when you need to.
• Being friendly also means making sure you're occupying thesmallest  heap size you can possibly run in. Again, users may never know that your FBA exists, so if you eat up a bunch of memory in your FBA, users will not understand why they've lost so much memory. Be conservative.
• Putting your FBA in the Startup Items folder in the System Folder is also a good idea. That will ensure that your FBA is launched right after Finder startup and will put the FBA high in the Process Manager's heap, preventing fragmentation of application memory space.
• Use WakeUpProcess to get your FBA running. Keep your sleep time at maximum normally, and when you need to start doing null processing (in response to an Apple event or PPC completion routine, for example) use the Process Manager to wake yourself up. WakeUpProcess can be called at interrupt time. Then, when you've finished processing, drop back to a maximum sleep time.

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