Confirming Pages
Chapter 1 Getting Started 5
Increasingly, certain parts of the OS—particularly those handling user and
application program interaction—are visible to users and programmers and often
may be critical in marketing a computer or electronic—or even mechanical—
device. Buyers are becoming very critical and have higher expectations of what the
OS should provide them. More than ever before, the system must not only provide
new features and be easier to use but it must also support those old features and
applications that we are used to. Of course, as we add new devices—video devices
and disks, high fidelity sound, and wireless networking, for example—we want the
system to easily adapt to and handle those devices. In fact, a good OS architecture
should even allow the connection of new devices that were not yet available and
may not even have been thought of when the OS was created!
1.2 WHAT ARE OPERATING SYSTEMS ALL ABOUT?
In this section, we give a simple example—a simple handheld game system—to
illustrate some of the basic functionalities that an OS should provide.
Think about a handheld electronic game system, one that is very cheap but has a
small screen, a few buttons, and several games. Although this game system might not
require an OS, it probably has one. The main reason is to consolidate the common
functions needed by the various games installed on the game system.
The games typically have some common parts. For example, each game needs to
get some input from the buttons, and to display something on the screen. While those
actions sound easy, they do require some not-so-simple software programming. Get-
ting the input from a button—that sounds easy. Well, except that the user may push two
buttons at once—what then? It is also likely that a cheap game does not use sophis-
ticated and expensive buttons, so there is electronic noise that may distort the signal
coming in—how should the games deal with that? The easy solution is to handle each
of these common issues in one, single place. For example, all button pushes can be read
in, have any noise cleaned up, and so forth in a single software routine. Having a single
read-the-button software routine has the advantage of providing a consistent user inter-
face—all games treat button input in the same way. It also allows the routine to occupy
space in only one place in system memory instead of occupying space in each individ-
ual game. And where should that read-the-button software routine be placed? It should
be in the OS—where every game that needs to read a button can call this routine.
The OS should also handle unexpected events. For example, a user may quit a
game in the middle (when losing) and start another game. No reboot of the game sys-
tem should be necessary. The user’s need to switch from game to game (task to task)
is natural and expected. In fact, users (5-year-olds) may push buttons at unexpected
times and the screen should continue to be updated (refreshed) while the game is being
played—even while waiting for a button to be pushed. This is called asynchronicity,
which can be defined informally as the occurrence of events at random or unexpected
times—a very important feature in even simple systems like a handheld game.
Several important OS concepts are part of this game system: When a game is
started, some part of its software may be loaded into memory, whereas other parts
elm49810_ch01_001-018.indd 5elm49810_ch01_001-018.indd 5 12/10/08 10:15:53 PM12/10/08 10:15:53 PM