Running in System 7.0
The guidelines given in the previous sections apply to all Macintosh
applications, regardless of the version of system software available. If you
heed those guidelines, you are likely to produce applications that run
reasonably well in all environments, including system 7.0 or later. Those
guidelines define a minimal level of conformance necessary for your
applications to run in system 7.0. Applications that conform to the
programming interfaces documented here and violate none of the guidelines
presented are called 7.0-compatible because they run in system 7.0 without
problems.
An application can be 7.0- compatible, however, without taking advantage of
the many new features available in system 7.0 and without exhibiting an
awareness that other applications may be present and may wish to use
processor time that would otherwise go unused. Among applications that do take
advantage of new features, there are at least two levels of involvement with
system 7.0.
An application is 7.0-friendly if it takes advantage of some of the special
features of system 7.0 when executing in that environment, but is still able to
perform all its principal functions when executing in system 6.0. An
application is 7.0-dependent if it requires the existence of features that are
available only in system 7.0; it might not even run in system 6.0. Even if 7.0
-dependent applications do execute in system 6.0, they are virtually
guaranteed to offer far fewer features there than in system 7.0.
The situation is similar to deciding whether your applications should use
Color QuickDraw. If you revise existing black-and-white drawing
programs to incorporate color, your applications operate either with or
Color QuickDraw, they simply won't run on machines that don't support
color.
The rest of this section gives guidelines on what you can do to existing
applications to make them 7.0-friendly and not simply 7.0- compatible. The
following pages describe in overview how to
• be aware that the user may have launched multiple applications
• support the required set of required Apple events
• remove font size restrictions to support outline fonts
• make sure that your application operates correctly with virtual
memory
Each of these items is discussed more completely elsewhere. For example, to
learn what you need to do to support outline fonts in your application, see the
Font Manager . For information about cooperating with other open
This section also discusses features of system 7.0 that simplify the creation
and manipulation of several new or existing user-interface elements. These
new capabilities allow you to
• get user menu selections while a modal dialog box is displayed
• coexist with system menus
• create movable modal dialog boxes
• create pop-up menus
• count and manipulate items in dialog boxes
Most of these features are not available on system software versions earlier
than 7.0. The routines that allow you to count the number of items in a dialog
item list and add or remove items from a dialog box have previously been
available as part of the Communications Toolbox. You can determine
available.
Allowing Multiple Applications
System 7.0 continues the development of the Macintosh Operating System into
a multitasking environment in which multiple applications can be active and
must share the available system resources. The facilities provided with earlier
versions of system software by the optional MultiFinder package are now an
integral part of system 7.0. This means that your application must display a
certain awareness that other applications might be open at the same time and
competing with it for processing time, memory, control of communications
ports, and so forth.
Although most operating systems regulate the sharing of available resources
by having the system parcel them out, the Macintosh Operating System relies
on the willingness of foreground and background applications to share those
resources among themselves. For example, you can indicate your application's
memory requirements by specifying a minimum memory partition size ( below
which that application does not execute) and a preferred partition size (at
which the application executes best). The Operating System itself has very
little control over the partition size allotted to your application, other than by
limiting that size to the available memory. Similarly, the Operating System
has very little control over which applications receive processing time
because the user ultimately decides when to bring a background application
into the foreground. If your application holds onto the micro processor for too
long while being switched into the background, other applications may appear
sluggish and unresponsive.
The lesson to be learned from all this is that in system 7.0 your application
must be a good neighbor. You cannot expect the Operating System to force
responsible behavior on your application; rather, you must ensure that your
application can happily coexist with other open applications by following these
guidelines:
• Include a 'SIZE' resource (with resource ID -1) that specifies
reasonable minimum and preferred memory partition sizes; if you
occasionally need larger amounts of memory, use the temporary
function in your main event loop to obtain events from the
Event Manager; this allows other applications to use processor time
your application doesn't need and allows your application to perform
operations while it is in the background.
• Modify your main event loop to process suspend and resume events;
this reduces the time it takes to switch your application into the
foreground or background
includes a description of the multitasking environment that is standard in
system 7.0.
Possibly the most significant new feature in system 7.0 is inter application
communication (IAC), which will play an increasingly important role in
future versions of the Macintosh Operating System. One central part of IAC is
receives and conveys to applications.
High-level events allow applications to communicate with one another by
putting events in each other's event queues.
Apple has defined a protocol for high-level events called the Apple Event
Interprocess Messaging Protocol. High-level events that adhere to this
protocol are called Apple events. Some Apple events must be supported by an
application that supports any Apple events; these are known as required Apple
events. With a minimal amount of work, you can modify your main event loop
so it supports the required Apple events. In doing so, you increase the level of
compatibility of your application and ease the transition to the day when
applications will expect other applications to support Apple events.
For information on how to support the required Apple events, see the
Removing Font Size Restrictions
can be printed or displayed at any point size without the jagged appearance of
some bitmapped fonts. A 7.0-friendly application should allow its users to take
advantage of this improvement. Minimally, this means that users should be
able to ask for any point size up to 32,768. Many applications now let users
specify font sizes up to 127 points, but you should remove even this limitation
when running in system 7.0. In addition, your application should allow users to
increase or decrease the font size by 1 point.You can use the IsOutline
outline font. If it is, you might wish to indicate that fact in your font size
font looks like the one in the Figure below.
The size menu for a bitmapped font
To provide a visual indication that the selected font is an outline font that
looks good at any size, you might change the menu to look like the one in the
Figure below. One way to do this is by outlining all listed sizes, as well as the
Other... item.
The size menu for an outline font
incorporating outline fonts into your application.
Operating With Virtual Memory
System 7.0 supports virtual memory, a memory management scheme that
extends the logical address space of the machine by using part of the available
secondary storage (usually, a hard disk) to store parts of memory that are not
currently in use. When virtual memory is present, the perceived amount of
RAM can extend up to 14 megabytes on systems with 24-bit ROMs and up to 4
gigabytes on systems with 32-bit clean ROMs. Because the Operating System
has more addressable memory, your applications can ask for and receive
larger blocks of memory than they would if virtual memory were not
available. Virtual memory is available only on machines equipped with a
memory management unit (MMU). Currently, these machines include
68030-based machines (where the MMU is built into the CPU) as well as
68020-based machines that contain the 68851 Paged Memory Management
installed. If it is, you may need to exercise caution to ensure that the normally
invisible operation of virtual memory does not adversely affect the execution
of your application. Applications that might need to be concerned with virtual
memory include those that have critical timing requirements, execute code at
interrupt time, or perform debugging operations.
Note: The vast majority of applications do not need to know whether virtual
memory is installed.
One type of application that might need to know if virtual memory is
operating is a multi-media application that manages very large images or
incorporates many sounds into its presentations. Imagine that such an
application wants to display a large number of intricate color images in rapid
succession, and that some of those images are as large as a megabyte each. If
virtual memory is operating, it is very likely that parts of those images are on
disk when they need to be displayed. This means that in the middle of drawing a