Operating Systems A Spiral Approach 1st Edition Ramez Elmasri

Operating Systems A Spiral Approach 1st Edition
Ramez Elmasri download
https://ebookbell.com/product/operating-systems-a-spiral-
approach-1st-edition-ramez-elmasri-2451400
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Operating Systems A Concept Based Approach 1st Edition Dhananjay
Dhamdhere
https://ebookbell.com/product/operating-systems-a-concept-based-
approach-1st-edition-dhananjay-dhamdhere-2451384
Operating Systems A Systematic View 5 Signed William S Davis
https://ebookbell.com/product/operating-systems-a-systematic-
view-5-signed-william-s-davis-4430710
Operating Systems A Multiperspective Episodic Approach First Edition
Jae Oh
https://ebookbell.com/product/operating-systems-a-multiperspective-
episodic-approach-first-edition-jae-oh-6806870
Embedded Operating Systems A Practical Approach 1st Edition Alan Holt
https://ebookbell.com/product/embedded-operating-systems-a-practical-
approach-1st-edition-alan-holt-4929566

Practical Operating Systems A Handson Approach With Python Shafiei
https://ebookbell.com/product/practical-operating-systems-a-handson-
approach-with-python-shafiei-55772584
Global Information Society Operating Information Systems In A Dynamic
Global Business Environment Yichen Lan
https://ebookbell.com/product/global-information-society-operating-
information-systems-in-a-dynamic-global-business-environment-yichen-
lan-978714
Embedded Operating Systems A Practical Approach 2nd Ed Alan Holt
https://ebookbell.com/product/embedded-operating-systems-a-practical-
approach-2nd-ed-alan-holt-6851524
Performance Modeling Of Operating Systems Using Objectoriented
Simulation A Practical Introduction 1st Edition Jos M Garrido Auth
https://ebookbell.com/product/performance-modeling-of-operating-
systems-using-objectoriented-simulation-a-practical-introduction-1st-
edition-jos-m-garrido-auth-4199634
Comptia A Core 2 Exam Guide To Operating Systems And Security 10th
Edition Jean Andrews
https://ebookbell.com/product/comptia-a-core-2-exam-guide-to-
operating-systems-and-security-10th-edition-jean-andrews-10809698

Elmasri, Carrick, and Levine’s “spiral approach” to teaching operating systems develops
student understanding of various OS components early on and helps students approach the
more difficult aspects of operating systems with confidence. While operating systems have
changed dramatically over the years, most OS books use a linear approach that covers each
individual OS component in depth, which is difficult for students to follow and requires
instructors constantly to put material in context.
Elmasri, Carrick, and Levine do things differently by following an integrative or “spiral”
approach to explaining operating systems. The spiral approach alleviates the need for an
instructor to “jump ahead” when explaining processes and other concepts by helping
students “completely” understand a simple, working, functional operating system as a
whole in the very beginning. This is more effective pedagogically, and it inspires students
to continue exploring more advanced concepts with confidence.
Key Features:
The authors use a conversational style to avoid boring the students with excessive pedantry.
The book not only uses the normal, accepted terms for describing operating systems, but
also discusses alternative terms when no accepted standard terminology exists or where
other terms were used historically.
For each OS that is treated separately, whether in the spiral section or in the case studies, the
book includes some history of the industry at the time, and sometimes the key companies or
individuals involved. This follows from the authors’ basic belief that a student can understand
OSs better if they are placed in a meaningful context.
The book covers modern OSs found in devices not conventionally regarded as computers since
the students use these devices every day and have an operational familiarity with them.
The authors discuss algorithmic solutions as well as providing pseudocode, since students
at different schools will have been exposed to different languages.
An abundance of figures are incorporated as an aid to those who learn better visually than
by reading sequences of words.
Each chapter ends with a set of questions that a student can use to assess the level of
understanding of the material in the chapter.
Projects are outlined for many chapters to help ground the students’ understanding in reality.
Operating Systems
A Spiral Approach
Ramez Elmasri
A. Gil Carrick
David Levine
Operating
Systems
A
Spiral
Approach
Elmasri
Carrick
Levine
MD
DALIM
#999865
12/17/08
CYAN
MAG
YELO
BLK

Confirming Pages
Operating Systems:
A Spiral Approach
Ramez Elmasri, Professor
University of Texas, Arlington
A. Gil Carrick, Lecturer
Formerly of the University of Texas, Arlington
David Levine, Senior Lecturer
University of Texas, Arlington
elm49810_fm_i-xiv.indd i
elm49810_fm_i-xiv.indd i 12/17/08 7:45:04 AM
12/17/08 7:45:04 AM

Confirming Pages
OPERATING SYSTEMS: A SPIRAL APPROACH
Published by McGraw-Hill, a business unit of The McGraw-Hill Companies, Inc., 1221 Avenue of the
Americas, New York, NY 10020. Copyright © 2010 by The McGraw-Hill Companies, Inc. All rights
reserved. No part of this publication may be reproduced or distributed in any form or by any means,
or stored in a database or retrieval system, without the prior written consent of The McGraw-Hill
Companies, Inc., including, but not limited to, in any network or other electronic storage or transmission,
or broadcast for distance learning.
Some ancillaries, including electronic and print components, may not be available to customers outside the
United States.
This book is printed on acid-free paper.
1 2 3 4 5 6 7 8 9 0 DOC/DOC 0 9
ISBN 978–0–07–244981–5
MHID 0–07–244981–0
Global Publisher: Raghothaman Srinivasan
Director of Development: Kristine Tibbetts
Senior Marketing Manager: Curt Reynolds
Project Manager: Joyce Watters
Senior Production Supervisor: Kara Kudronowicz
Senior Media Project Manager: Jodi K. Banowetz
Associate Design Coordinator: Brenda A. Rolwes
Cover Designer: Studio Montage, St. Louis, Missouri
(USE) Cover Image: © Getty Images
Compositor: Laserwords Private Limited
Typeface: 10/12 Times Roman
Printer: R. R. Donnelley Crawfordsville, IN
Library of Congress Cataloging-in-Publication Data
Elmasri, Ramez.
Operating systems : a spiral approach / Ramez Elmasri, A. Gil Carrick, David Levine. —1st ed.
p. cm.
Includes index.
ISBN 978–0–07–244981–5 — ISBN 0–07–244981–0 (hard copy : alk. paper)
1. Operating systems (Computers)—Textbooks. I. Carrick, A. Gil. II. Levine, David (David E.) III. Title.
QA76.76.O63E4865 2010
005.4'3—dc22
2008051735
www.mhhe.com
elm49810_fm_i-xiv.indd ii
elm49810_fm_i-xiv.indd ii 12/17/08 7:45:08 AM
12/17/08 7:45:08 AM

Confirming Pages
Dedication
“To peace, knowledge, and freedom.”
—Ramez Elmasri
“To Judith, whose limited patience was strongly tested.”
—Gil Carrick
“To close family and friends.”
—David Levine
elm49810_fm_i-xiv.indd iii
elm49810_fm_i-xiv.indd iii 12/17/08 7:45:09 AM
12/17/08 7:45:09 AM

Confirming Pages
iv
Table of Contents
Preface viii
Par t 1
Operating Systems Overview
and Background 1
Chapter 1
Getting Started 3
1.1 Introduction 4
1.2 What Are Operating Systems
All about? 5
1.3 User versus System View of an OS 6
1.4 Some OS Terms, Basic Concepts,
and Illustrations 10
1.5 A Small Historical Diversion 15
1.6 Summary 17
Chapter 2
Operating System Concepts, Components,
and Architectures 19
2.1 Introduction: What Does the OS
Do? 20
2.2 Resources Managed by the OS
and Major OS Modules 22
2.3 The Process Concept
and OS Process Information 25
2.4 Functional Classes of OSs 29
2.5 Architectural Approaches to Building
an OS 33
2.6 Some OS Implementation Techniques
and Issues 35
2.7 Minimalist versus Maximalist Approaches
to OS Functionality
and Backward Compatibility 40
2.8 Summary 42
Par t 2
Building Operating Systems
Incrementally: A Breadth-Oriented
Spiral Approach 45
Chapter 3
A Simple, Single-Process
Operating System 47
3.1 Introduction: Monitors and CP/M 48
3.2 Characteristics of a Simple PC System 50
3.3 Input/Output Management 52
3.4 Disk Management and the File System 54
3.5 Process and Memory Management 58
3.6 Summary 63
Chapter 4
A Single-User Multitasking
Operating System 67
4.1 Introduction: A Simple Multitasking
System 69
4.2 The Palm OS Environment
and System Layout 71
4.3 Process Scheduling 73
4.4 Memory Management 75
4.5 File Support 80
4.6 Basic Input and Output 82
elm49810_fm_i-xiv.indd iv
elm49810_fm_i-xiv.indd iv 12/17/08 7:45:09 AM
12/17/08 7:45:09 AM

Confirming Pages
Table of Contents v
4.7 Display Management 82
4.8 Event-Driven Programs 84
4.9 Summary 86
Chapter 5
A Single-User Multitasking/Multithreading
Operating System 89
5.1 Introduction 89
5.2 The Origin of the Macintosh Computer 90
5.3 The Macintosh OS—System 1 91
5.4 System 2 96
5.5 System 3 98
5.6 System 4 98
5.7 System 5 100
5.8 System 6 101
5.9 System 7 101
5.10 System 8 105
5.11 System 9 107
5.12 Mac OS X 109
5.13 Summary 111
Chapter 6
A Multiple-User Operating
System 113
6.1 Introduction 113
6.2 The Multiuser OS Environment 121
6.3 Processes and Threads 123
6.4 Summary 125
Chapter 7
Parallel and Distributed Computing, Clusters,
and Grids 127
7.2 Key Concepts 128
7.3 Parallel and Distributed Processing 128
7.4 Distributed System Architectures 132
7.5 How Operating System Concepts Differ
in SMPs, Clusters, and Grids 138
7.6 Examples 142
7.7 Summary 147
Par t 3
CPU and Memory
Management 149
Chapter 8
Process Management: Concepts, Threads,
and Scheduling 151
8.1 Introduction to Processes 152
8.2 Process Descriptor–Process
Control Block 152
8.3 Process States and Transitions 154
8.5 One Good Process Deserves Another 164
8.6 Threads 166
8.7 Case Studies 173
8.7 Summary 178
Chapter 9
More Process Management: Interprocess
Communication, Synchronization,
and Deadlocks 181
9.1 Why Have Cooperating Processes? 182
9.2 Interprocess Communication 184
9.3 Synchronization 190
9.4 Deadlocks 197
9.5 Summary 206
Chapter 10
Basic Memory Management 209
10.1 Introduction: Why Manage
Primary Memory? 209
10.2 Binding Model: Steps
in Development Cycle 210
elm49810_fm_i-xiv.indd v
elm49810_fm_i-xiv.indd v 12/17/08 7:45:10 AM
12/17/08 7:45:10 AM

Confirming Pages
10.3 A Single Process 211
10.4 Multiple Processes with a Fixed Number
of Processes 216
10.5 Multiple Processes with a Variable Number
of Processes 218
10.6 Summary 223
Chapter 11
Advanced Memory Management 225
11.1 Why Do We Need Hardware Help? 225
11.2 Paging 226
11.3 Segmentation 233
11.4 Segmentation with Paging 236
11.5 Demand Paging 238
11.6 Special Memory Management Topics 248
11.7 Summary 252
Par t 4
A Depth-Oriented Presentation of OS
Concepts: Files Systems
and Input/Output 255
Chapter 12
File Systems—Basics 257
12.2 Directories 259
12.3 Access Methods 265
12.4 Free Space Tracking 269
12.5 File Allocation 273
12.6 Summary 280
Chapter 13
File Systems—Examples
and More Features 283
13.2 Case Studies 284
13.3 Mounting 288
13.4 Multiple File Systems and Redirection 290
13.5 Memory Mapped Files 292
13.6 File System Utilities 293
13.7 Log-Based File Systems 294
13.8 Summary 295
Chapter 14
Disk Scheduling
and Input/Output Management 297
14.2 Device Characteristics 298
14.3 I/O Technology 299
14.4 Physical Disk Organization 302
14.5 Logical Disk Organization 305
14.6 RAID 309
14.7 Disk Operation Scheduling 314
14.8 DMA and Disk Hardware Features 322
14.9 Summary 325
Par t 5
Networks, Distributed Systems,
and Security 329
Chapter 15
Introduction to Computer Networks 331
15.1 Why Do We Want
to Network Computers? 332
15.2 The Basics 333
15.3 Application Layer Protocols 338
15.4 TCP/IP 341
15.5 The Data Link Layer 345
15.6 WANs 350
15.7 The Physical Layer 352
15.8 Network Management 354
15.9 Summary 356
Chapter 16
Protection and Security 359
16.1 Introduction: Problems and
Threats 360
16.2 OS Protection 366
vi Table of Contents
elm49810_fm_i-xiv.indd vi
elm49810_fm_i-xiv.indd vi 12/17/08 7:45:10 AM
12/17/08 7:45:10 AM

Confirming Pages
16.3 Policies, Mechanisms, and Techniques 370
16.4 Communication Security 373
16.5 Security Administration 380
16.6 Summary 381
Chapter 17
Distributed Operating Systems 385
17.2 Distributed Application Models 388
17.3 Abstractions: Processes, Threads,
and Machines 391
17.4 Naming 394
17.5 Other Distributed Models 396
17.6 Synchronization 400
17.7 Fault Tolerance 406
17.8 Summary 409
Par t 6
Case Studies 413
Chapter 18
Windows NT™
through Vista™
415
18.1 Introduction: Windows NT
Family History 416
18.2 The User OS Environment 421
18.5 File Support 428
18.7 GUI Programming 439
18.8 Networking 440
18.9 Symmetric Multiprocessing 441
18.10 Startup Speed of XP 441
18.11 Summary 442
Chapter 19
Linux: A Case Study 445
19.7 Networking 460
19.8 Security 462
19.9 Symmetric Multiprocessing 463
19.10 Other Linux Variants 463
19.11 Summary 466
Chapter 20
Palm OS: A Class Case Study 469
20.1 Overview 469
20.2 The Multi-Process OS Environment 470
20.3 Palm Process Scheduling 471
20.4 Palm Memory Management 471
20.6 Input/Output Subsystems 472
20.8 Network Programming 473
20.9 Programming Environments 475
20.10 Similar Systems
and Current Developments 476
20.11 Summary 480
Appendix
Overview of Computer System
and Architecture Concepts
A.1 Typical Computer System
Components 484
A.2 The Processor or Central
Processing Unit 485
A.3 The Memory Unit and
Storage Hierarchies 496
A.4 Input and Output 502
A.5 The Network 504
A.6 A More Detailed Picture 507
A.7 Summary 507
Index 511
Table of Contents vii
elm49810_fm_i-xiv.indd vii
elm49810_fm_i-xiv.indd vii 12/17/08 7:45:10 AM
12/17/08 7:45:10 AM

Confirming Pages
viii
Preface
WHY WE WROTE YET ANOTHER OPERATING SYSTEMS BOOK
We have long felt that the traditional approach to teaching about Operating Systems
(OSs) was not the best approach. The purpose of this book is to support a different
approach to this task. When studying any complex domain of knowledge, the order
in which one learns the hierarchy of principles, laws, ideas, and concepts can make
the process easier or more difficult. The most common technique is to partition the
subject into major topics and then study each one in great detail. For OSs, this has
traditionally meant that after a brief introduction to some terms and an overview, a
student studied isolated topics in depth—processes and process management, then
memory management, then file systems, and so on. We can call this a depth-oriented
approach or a vertical approach. After learning a great mass of unrelated details in
these isolated topic areas, the student then examined case studies, examples of real
OSs, and finally saw how the different topics fit together to make a real OS.
We believe that a better model is that followed by children when learning a
language: learn a few words, a little grammar, a little sentence structure, and then
cycle (or spiral) through; more words, more grammar, more sentence structure. By
continuing to spiral through the same sequence, the complexity of the language is
mastered. We can call this a breadth-oriented or spiral approach.
We have taken this approach to the subject of OSs. The first few chapters give
some basic background and definitions. We then begin to describe a very simple
OS in a simple system—early PCs—and evolve toward more complex systems with
more features: first limited background tasks (such as simultaneous printing), then
multitasking, and so on. In each case we try to show how the increasing requirements
caused each system to be designed the way it was. This is not specifically a his-
torical order of OS development. Rather, we choose a representative system at each
complexity level in order to see how the different OS components interact with and
influence one another. It is our belief that this approach will give the student a greater
appreciation of how the various features of each level of OS were put together.
Part of the motivation for this approach has to do with why Computing Science
students are told they must study OSs at all. It is highly unlikely that many of these
students will work on the development of OSs. However, virtually every system that
they do work on will run on top of an OS, though perhaps a very few will work on
embedded systems with no OS. For the rest of them, the OS will stand between the
applications and the hardware, and failure to thoroughly understand the nature of the
OS will mean that these applications will be underperforming at best and hazardous
at worst. We believe that our approach will lead students to a better understanding of
the entire architecture of modern OSs than does the traditional approach.
elm49810_fm_i-xiv.indd viii
elm49810_fm_i-xiv.indd viii 12/17/08 7:45:10 AM
12/17/08 7:45:10 AM

Confirming Pages
THE ORGANIZATION OF THE BOOK
In Part 1 of the book we give some general background information. This infor-
mation will cover basic principles of OSs and show several different views of an
OS. It will also include an overview of typical computer hardware that an OS
controls. Another chapter addresses such basic concepts as processes, multipro-
gramming, time sharing, resource management, and different approaches to OS
architecture.
Then in Part 2 of the book, we will cover five types of operating systems in
increasing order of complexity, our spiral approach, as follows:
1. A simple single-process OS (CPM)
2. A more complex OS (Palm OS), which allows simple system multitasking
3. An OS with full multitasking for a single user (Apple Mac OS, pre-OS X)
4. An OS that supports multiple users (Linux)
5. A distributed OS (mostly Globus)
In each case we have selected an OS that is typical of the class on which to base
the discussion so as to make it more concrete. This selection was made with an eye
to practicality. We first discuss simple systems in terms of process, memory, file,
and I/O management, and then (slowly) move to more complex systems, gradu-
ally introducing such concepts as multitasking, time sharing, networking, security,
and other issues. Occasionally we will also mention other well-known OSs that
are examples of a class, such as MS-DOS in Chapter 3 and the Symbian OS in
Chapter 4.
In Parts 3–5 of the book, we move to an in-depth approach of covering each OS
topic in more detail: from processes to memory management to file systems. We also
discuss many recent issues in operating systems: threading, object orientation, secu-
rity, and approaches to parallel and distributed systems. In these chapters we revisit
the sample systems discussed in Part 2 and explain the mechanisms in more detail,
especially for the modern OSs.
In Part 6 we look more closely at several OSs in what are typically called case
studies. Now that we know more about the details, we look at some systems in more
depth and see how some features were implemented. In two cases we are revisiting
more closely OSs that were covered in Part 2.
An appendix covers basic computer hardware architecture for those institutions
that do not require such a course as a prerequisite for an Operating Systems course. It
can also be used as a reference for those who need to review a specific topic.
THE STYLE OF THE BOOK
We use a conversational style to avoid boring the students with excessive
pedantry.
We avoid the use of excessive formalisms. A more formal presentation is pro-
vided where needed. This choice stems from our belief that most students will
not develop OSs, but rather will use them to support applications.
Preface ix
elm49810_fm_i-xiv.indd ix
elm49810_fm_i-xiv.indd ix 12/17/08 7:45:11 AM
12/17/08 7:45:11 AM

Confirming Pages
We use the normal, accepted terms but also discuss alternative terms when
no accepted standard terminology exists or where other terms were used
historically.
We discuss algorithmic solutions as opposed to listing actual code since stu-
dents at different schools will have been exposed to different languages.
For each OS that is treated separately, whether in the spiral section or in the case
studies, we include some history of the industry at the time, and sometimes the
key companies or individuals involved. This follows from our basic belief that a
student can understand OSs better if they are placed in a meaningful context.
We cover modern OSs found in devices not conventionally regarded as com-
puters since the students use these devices every day and have an operational
familiarity with them.
Frequent figures are incorporated as an aid to those who learn best visually
rather than by reading sequences of words.
Each chapter ends with a set of questions that a student can use to assess the
level of understanding of the material in the chapter.
Projects are outlined for many chapters, which can be used by the instructor to
ground the students’ understanding in reality.
x Preface
elm49810_fm_i-xiv.indd x
elm49810_fm_i-xiv.indd x 12/17/08 7:45:11 AM
12/17/08 7:45:11 AM

Confirming Pages
xi
We have been teaching OS classes for quite a few years using other materials. We
have developed this text because we felt the need for a different methodology. We all
have served on the faculty of the Department of Computer Science and Engineering
at the University of Texas at Arlington (UTA).
Ramez Elmasri is a Professor at the University of Texas at Arlington. He received
his BS in Electrical Engineering from Alexandria University, Egypt, in 1972, and
his MS and PhD degrees in Computer Science at Stanford University in 1980. His
current research interests are in sensor networks and RFID, mediators for bioinfor-
matics data, query personalization, and systems integration. He is the lead co-author
of the textbook “Fundamentals of Database Systems,” now in its 5th Edition. His
previous research covered various aspects of databases, conceptual modeling, and
distributed systems.
A. Gil Carrick was formerly a Lecturer at UTA and is now retired from teaching.
He received his BS in Electronics Technology from the University of Houston in
1970 and his MSCS in 2000 from the University of Texas at Arlington. He is a mem-
ber of Upsilon Pi Epsilon, the Computer Science Honor Society. His career spans the
information technology industry: end-user organizations, hardware manufacturers,
software publishers, third-party maintenance, universities, and RD firms. He has
written for professional journals and edited IT books, primarily in the networking
field. In his career he has used all the operating systems discussed in this text and
many others besides.
David Levine has been teaching courses in operating systems, software engineer-
ing, networking, and computer architecture. His research interests include mobile
computing, mobile objects, and distributed computing and he has presented the
results of this research in recent publications and several international conferences.
He enjoys discussing Operating Systems, talking about current research with stu-
dents and reading about new OS advances.
HOW TO USE THIS BOOK—FOR INSTRUCTORS
This text is intended to be used for a one-semester undergraduate course in Operating
Systems, probably in the junior or senior year. The first part of the book is designed
to consolidate basic background information necessary for the following chapters.
Chapter 1 sets the discussion and gives some historical perspective. The instructor can
The Authors
elm49810_fm_i-xiv.indd xi
elm49810_fm_i-xiv.indd xi 12/17/08 7:45:11 AM
12/17/08 7:45:11 AM

Confirming Pages
skim this chapter and decide what to include. The appendix is a brief look at fairly
modern hardware architectures. If a course in hardware is not a prerequisite for this
course, then this appendix could be included. Chapter 2 defines some simple terms
used in OSs and offers some more perspective on the larger topic of OS design.Again,
an instructor can review this chapter and select different parts to include or exclude.
Part 2 begins the spiral approach. We believe this is a significant portion of the
book. Here the student is gradually introduced to a series of OSs with more complex
goals. These increasingly more complex goals lead to increasingly more complex
OSs. Only two of these chapters are not normal topics in OS texts—Chapter 4 on a
single-user multitasking operating system and Chapter 7 on a distributed operating
system. They could be left out at the instructor’s discretion, but more and more stu-
dents will be working in such environments as users and as programmers.
Part 3 begins the in-depth chapters. Each chapter is fairly independent of the
others, though Chapters 12 and 13 are strongly related. Beginning with Chapter 14
the individual chapters can probably be left out if the topic is the major subject of
another course that the students will be required to take.
Notes about the bibliographies: The chapters in Part 3 all include a bibliography
section. The reference papers that are cited are widely regarded as being seminal
papers or good summaries. They may cover material that is not covered in the text. If
an instructor or a student is looking for material to provide a better understanding of
a given topic, then they are suggested reading.
HOW TO USE THIS BOOK—FOR STUDENTS
For students the most important thing about using this text is to understand how one
learns best. There are many pathways to get information into the brain. The book
itself directly addresses two of these pathways. There is obviously the text for those
who learn best through reading the words and the illustrations for those who are
more visually oriented. When you attend the lectures you will hear the instructor
talk about the material. This is for those who learn best through hearing words. At
the same time, the instructor will probably use visual aids such as the PowerPoint
slides that are available for the text. Again, this is to the benefit of those who learn
best by reading the words and seeing the illustrations. Some students learn best from
mechanical skills, so the process of outlining the material or making study notes
works well for those students.
Also presented in the book at the end of each chapter are questions about the
material. These questions are designed such that a student who has a reasonable
grasp of the material should be able to answer the question.
As new information is presented to the brain it takes a certain amount of time
to link with other information already there. But the brain gets much information
during the day that is not significant and therefore it does not retain it. Only when
presented with the same or similar material again a short time later will the brain
retain a significant amount of the information. The more different mechanisms that
are used and the more times the information is repeated, the stronger the retention
of the material. So the best method is to use all these methods combined, focusing
xii The Authors
elm49810_fm_i-xiv.indd xii
elm49810_fm_i-xiv.indd xii 12/17/08 7:45:11 AM
12/17/08 7:45:11 AM

Confirming Pages
on what works best for you. What we have found works well for most students is the
following sequence:
Print the slides to be covered in the next section, with several slides per page.
Read the assigned material in the text. Note questions on the slide printouts.
Come to class and listen to the instructor, amplifying any notes, especially things
the instructor says that are not in the text. (Those points are favorite issues for
the instructor and they tend to show up on exams.)
Ask questions about things that are unclear.
When it is time to review the material for an exam, go over the slides. If there
are points that are unclear, go back to the text to fill them in. If any questions
remain, then contact the instructor or teaching assistants.
The review questions can be studied at any time the student finds convenient.
AVAILABLE RESOURCES FOR INSTRUCTORS
The text is supported by a website with separate sections for instructors and students.
Supplements to the text will be made from time to time as the need presents
itself.
A set of suggested projects will be available for instructors. Most of these proj-
ects will have been used by the authors. They should be sufficiently rich and
OS independent that they can be readily adapted to fit any situation. They are
not based on any specific package that the instructor, students, or assistants will
have to master in order to work the labs.
PowerPoint slides are provided for the students to use, as described earlier.
Instructors are encouraged to modify these presentations to fit their needs.
Acknowledgement of their source is requested.
Review question answers are provided for the instructors in order that they not
be embarrassed by not knowing some arcane point the authors thought was
important.
A current list of errata will be maintained on the website.
Reference to web resources are provided for many chapters, but the web is
very volatile. The website for the book will contain an up-to-date set of web
references.
ACKNOWLEDGMENTS
This text has actually been developing for longer than we would like to remember.
The people at McGraw-Hill have been exceptionally patient with us. In particular,
we would like to thank the following folks with McGraw-Hill: Melinda Bilecki,
Kay Brimeyer, Brenda Rolwes, Kara Kudronowicz, Faye Schilling, and Raghu
Srinivasan. We would also like to thank Alan Apt and Emily Lupash, who were our
editors when we started working on the book. Finally, we also thank Erika Jordan
and Laura Patchkofsky with Pine Tree Composition.
The Authors xiii
elm49810_fm_i-xiv.indd xiii
elm49810_fm_i-xiv.indd xiii 12/17/08 7:45:12 AM
12/17/08 7:45:12 AM

Confirming Pages
The chapter on Windows Vista was reviewed by Dave Probert of Microsoft. He
provided valuable feedback on some items we had only been able to speculate on
and brought several problems to our attention. His participation was arranged by
Arkady Retik, also with Microsoft Corporation. Two chapters were reviewed by our
fellow faculty members at University of Texas, Arlington. These included Yonghe
Liu who reviewed the chapter on networking and Matthew Wright who reviewed the
chapter on protection and security. Another faculty member, Bahram Khalili, used
drafts of the text in his OS class. Naturally any remaining problems are our respon-
sibility and not theirs.
We have used drafts of these materials in our teaching for several years and we
wish to thank all our students for their feedback. In particular we wish to thank the
following students: Zaher Naarane, Phil Renner, William Peacock, Wes Parish, Kyle
D. Witt, David M. Connelly, and Scott Purdy.
REMAINING ERRORS
One difficulty with working on a project with multiple authors is that with the best
of intentions, one of the writers can alter a bit of text that he himself did not write,
thinking that he is clearing up some minor point, but actually altering the meaning in
some subtle but important way. Accordingly, you may find minor errors in the text.
Naturally these errors were not the fault of the original author, who doubtless wrote
the original text correctly, but were introduced by another well-meaning author who
was not as familiar with the material.
Still, such errors may be present, and we must deal with them. So, if you do
find errors, we would be very happy to know about them. We will publish any errata,
fix them in the next edition, determine who is to blame, and deal with the offending
authors appropriately.
xiv The Authors
elm49810_fm_i-xiv.indd xiv
elm49810_fm_i-xiv.indd xiv 12/17/08 7:45:12 AM
12/17/08 7:45:12 AM

Confirming Pages
1
In this part:
Chapter 1: Getting Started 3
Chapter 2: Operating System Concepts, Components,
and Architectures 19
T
his part of the book contains two chapters. Chapter 1 gives a basic explanation
about what an Operating System (or OS for short) is. It explains how the OS
provides services to users and programmers. These services make it possible
to utilize a computer without having to deal with the low-level, arcane details, but
rather, being allowed to concentrate on the problem(s) to be solved. Such problems
may be anything, including not only the things we normally consider computing
activities, but also activities such as playing games, dynamically generating art, and
monitoring the performance of an automobile engine.
Chapter 2 provides an initial high-level look at OS concepts, components, and
architecture. General terms are introduced that a student will need to know in order to
study the series of increasingly more complex OSs that are presented in Part 2.
Operating Systems Overview
and Background
Part
Part 1
1
elm49810_ch01_001-018.indd 1
elm49810_ch01_001-018.indd 1 12/10/08 10:15:47 PM
12/10/08 10:15:47 PM

Confirming Pages
2
elm49810_ch01_001-018.indd 2
elm49810_ch01_001-018.indd 2 12/10/08 10:15:48 PM
12/10/08 10:15:48 PM

Confirming Pages
3
Chapter
Chapter 1
1
Getting Started
In this chapter:
1.1 Introduction 4
1.2 What Are Operating Systems All About? 5
1.3 User versus System View of an OS 6
1.4 Some OS Terms, Basic Concepts, and Illustrations 10
1.5 A Small Historical Diversion 15
1.6 Summary 17
O
perating systems are at the heart of every computer. The Operating System
(or OS for short) provides services to users and programmers that make it
possible to utilize a computer without having to deal with the low-level, dif-
ficult-to-use hardware commands. It provides relatively uniform interfaces to access
the extremely wide variety of devices that a computer interacts with, from input/
output devices such as printers and digital cameras, to wired and wireless network
components that allow computers to communicate. It allows users to create, manage,
and organize different types of files. In addition, most modern OSs provide graphical
user interfaces (GUIs) to allow a relatively easy-to-use interface for computer users.
In this opening chapter, we start in Section 1.1 with a brief introduction to
show how important an Operating System is and how they are used not only in
computers but also in many types of electronic devices that we all use in our
daily routines. Section 1.2 is a more technical look at why even simple devices
contain an Operating System. Then in Section 1.3 we discuss the different views
of what an Operating System does by looking at the Operating System from two
perspectives: the user’s perspective and the system’s perspective. We also discuss
the requirements that each type of user has for the Operating System. Section 1.3
next gives a few simple examples to illustrate some sequences of functions that
an Operating System goes through to perform seemingly simple user requests.
In Section 1.4 we present some basic terminology and concepts, and give some
figures to illustrate typical components for a simple Operating System. We give a
brief historical perspective in Section 1.5 and conclude with a chapter summary
in Section 1.6.
elm49810_ch01_001-018.indd 3
elm49810_ch01_001-018.indd 3 12/10/08 10:15:48 PM
12/10/08 10:15:48 PM

Confirming Pages
4 Part 1 Operating Systems Overview and Background
1.1 INTRODUCTION
For many years, OSs were viewed by most people as uninteresting—except for
OS programmers and computer “nerds.” Because of a number of high-profile cases,
OSs have occasionally become front-page news in recent years. Suddenly, the OS
is seen by some as controlling all computing. There are very strongly felt opinions
about what constitutes good versus bad OSs. There is also quite a bit of disagree-
ment about what functionality should be provided by the OS. While many people
(and some courts!) believe that one company dominates the OS market, others say
that the OS is increasingly unimportant—the Internet browser is the OS. In fact,
there is a very wide variety of types of OSs, and OSs exist at some level on every
conceivable computing device, including some that may surprise many people.
For example, handheld personal digital assistants (PDAs) have very capable,
complex, and flexible OSs. Most electronic devices that have some intelligence
have complex, yet easy-to-use OSs and system software to control them. The OS
that was once thought of as the arcane world of process management and memory
management techniques is now occasionally a conversation topic in cafés, bars,
and computer stores. Many people now seem to be experts—or at least have an
opinion—on OSs.
(Perhaps) Surprising places to find an OS:
Personal digital assistants
Cable TV controller boxes
Electronic games
Copiers
Fax machines
Remote controls
Cellular telephones
Automobile engines
Digital cameras
While we also have our opinions, we try to get behind the hype—generated
by marketing and salespeople as well as millions of opinionated users—in order
to explain the real systems. We also throw in our own opinions when needed and
explain why we hold these beliefs. We give many examples of currently used sys-
tems to demonstrate concepts and show what is good and bad about the various sys-
tems. We try to avoid the so-called religious issues, such as: Which is the better OS:
Windows or Mac-OS? Or are UNIX and its variations such as Linux better than
both? Instead, we point out how these systems came about and what they provide to
users and programmers.
elm49810_ch01_001-018.indd 4
elm49810_ch01_001-018.indd 4 12/10/08 10:15:53 PM
12/10/08 10:15:53 PM

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 5
elm49810_ch01_001-018.indd 5 12/10/08 10:15:53 PM
12/10/08 10:15:53 PM

Confirming Pages
may have been preloaded in ROM (read-only memory) or fixed memory1
; dynamic
memory is reserved for use by the game and is initialized; timers may be set. All on
a cheap (but fun) game! What more does one expect from an OS?
1.3 USER VERSUS SYSTEM VIEW OF AN OS
You have probably heard the old adage; “There are two sides to every question.”
(Maybe that should be “two or more sides.”) The idea is that trying to look at some
question from different perspectives often helps our understanding. One of the impor-
tant methods to learning something new is to view it from different perspectives. For
an OS, the two most important perspectives are the user view and the system view.
The user view pertains to how users or programs—programs are the main users
of the OS—utilize the OS; for example, how a program reads a keystroke. The sys-
tem view pertains to how the OS software actually does the required action—how it
gets keystrokes, separates out special ones like shift, and makes them available to the
user or program. We present OS facilities, concepts, and techniques from both user
and system points of view throughout the book. First, we elaborate on the different
types of users and their views of the OS.
1.3.1 Users’ views and types of users
The term user is often too vague—especially for persons whose role in computing
is so critical—so it is important to first describe the various types of users. Trying to
pin down the role of a user of an OS is not simple. There are various types of users.
We primarily want to distinguish among end users, application programmers, system
programmers and system administrators. Table 1.1 lists some of the most important
concerns about what the OS should provide for each of the three main types of users.
Of course, there is some overlap among these concerns. We are merely trying to
show how those viewpoints sometimes diverge. Further complicating the issue is
that sometimes users fit into several of the roles or even all of them. Such users often
find themselves having conflicting needs.
Application Users (or End Users)—this group includes all of us, people who
use (or run) application or system programs. When we use a word processor, a web
browser, an email system, or a multimedia viewer, we are a user of that application.
As users, we expect a quick, reliable response (to keystrokes or mouse movement),
a consistent user view (each type of command—such as scrolling or quitting an
application—should be done in a similar manner), and other features that depend on
each specific type of OS. Other needs are listed in Table 1.1. In general, this group of
users is most often called simply users, or sometimes end users.
Application Programmers—this group includes the people who write appli-
cation programs, such as word processors or email systems. Programmers are very
demanding of the OS: “How do I read and write to a file?”, “How do I get a user’s
keystroke?”, and “How do I display this box?” are typical questions programmers
1
We define these terms in Chapters 2 and 3.
elm49810_ch01_001-018.indd 6
elm49810_ch01_001-018.indd 6 12/10/08 10:15:54 PM
12/10/08 10:15:54 PM

Confirming Pages
ask when learning to use a new OS. The facilities that the OS provide are the pro-
grammers’ view of the OS. Sometimes they are called system calls or an API (appli-
cation program interface). They may also appear as language library functions or
sometimes just as packages of classes. Programmers also want the software they
develop to be easily ported to other platforms.
Systems Programmers—these are the people who write software—either pro-
grams or components—that is closely tied to the OS. A utility that shows the status
of the computer’s network connection or an installable driver for a piece of hardware
are examples of systems programs. Systems programmers need to have a detailed
understanding of the internal functioning of the OS. In many cases, systems pro-
grams need to access special OS data structures or privileged system calls. While OS
designers sometimes are concerned with portability to other platforms, often they
are not—they are charged with developing a specific set of functions for a specific
platform and portability is not a concern.
TABLE 1.1 Concerns of Various User Classes
End Users Easy to use and learn
Adapts to user’s style of doing things
Lively response to input
Provides lots of visual cues
Free of unpleasant surprises (e.g., deleting a file without warning)
Uniform ways to do the same thing (e.g., moving an icon or scrolling down a
window—in different places)
Alternative ways to do one thing (e.g., some users like to use the mouse,
others like to use the keyboard)
Application Programmers Easy to access low-level OS calls by programs (e.g., reading keystrokes,
drawing to the screen, getting mouse position)
Provide a consistent programmer view of the system
Easy to use higher-level OS facilities and services (e.g., creating new
windows, or reading from and writing to the network)
Portability to other platforms
Systems Programmers Easy to create correct programs
Easy to debug incorrect programs
Easy to maintain programs
Easy to expand existing programs
System Managers and
Administrators
Easy addition or removal of devices such as disks, scanners, multimedia
accessories, and network connections
Provide OS security services to protect the users, system, and data files
Easy to upgrade to new OS versions
Easy to create and manage user accounts
Average response is good and predictable
System is affordable
elm49810_ch01_001-018.indd 7
elm49810_ch01_001-018.indd 7 12/10/08 10:15:54 PM
12/10/08 10:15:54 PM

Confirming Pages
System Administrators—this group includes the people who manage computer
facilities, and hence are responsible for installing and upgrading the OS, as well as
other systems programs and utilities. They are also responsible for creating and man-
aging user accounts, and for protecting the system. They need to have a detailed
understanding of how the OS is installed and upgraded, and how it interacts with
other programs and utilities. They must also understand the security and authoriza-
tion features of the OS in order to protect their system and users effectively.
1.3.2 System view
The system view refers to how the OS actually provides services. In other words, it
refers to the internal workings of the OS. This is a less common view. Often only a
few people, the OS designers and implementers, understand or care about the inter-
nal workings of an OS. Indeed this information is often considered secret by com-
panies that produce and sell OSs commercially. Sometimes the overall workings of
major parts of the system—management of files, running of programs, or handling
of memory—may be described to help programmers understand the use of those
subsystems. In some cases, the whole source code for an OS is available. Such sys-
tems are known as open source systems.2
The majority of this book is concerned with the how—how does the system run
a program, create a file, or display a graphic. To understand the actual “how”—the
internal details—we describe algorithms and competing methods for implement-
ing OS functions. We now illustrate the system view (or views) with two examples:
tracking mouse and cursor movement, and managing file operations. Although these
examples may seem a bit complex, they serve to illustrate how the OS is involved in
practically all actions that are performed by a computer user.
1.3.3 An example: moving a mouse (and mouse cursor)
While the movement of a mouse pointer (or cursor) on a screen by moving the
mouse (or some other pointing device such as a pad or trackball) seems straightfor-
ward, it illustrates the many views of an OS. Figure 1.1 illustrates this process. When
the pointing device is moved, it generates a hardware event called an interrupt,
which the OS handles. The OS notes the movements of the mouse in terms of some
hardware-specific units—that is, rather than millimeters or inches the readings are in
number of pulses generated. This is the low-level system view. The actual software
reading the mouse movements is part of the OS, and is called a mouse device driver.
This device driver reads the low-level mouse movement information and another
part of the OS interprets it so that it can be converted into a higher-level system
view, such as screen coordinates reflecting the mouse movements.
On the “other side” or view is the question, What does the user see? The user’s
view is that the cursor will smoothly move on the screen and that as the mouse moves
greater distances faster, the screen movement will appear faster too. In between these
2
The Linux OS is a well-known example of an open source operating system.
elm49810_ch01_001-018.indd 8
elm49810_ch01_001-018.indd 8 12/10/08 10:15:54 PM
12/10/08 10:15:54 PM

Confirming Pages
views is the application programmers’ view, How do I get the mouse movement
information in order to use it and display it in my application? Another issue is how
this information on mouse movements is presented to the application programmer.
This is the higher-level system view mentioned earlier.
And to complete these views a bit let us return to the system’s view, Which
application gets this mouse movement if there are multiple open windows? The
mouse movements may need to be queued up if there are multiple movements
before the application retrieves them. The movements may even be lost if the OS
is busy doing other things—for example, loading a Web page through a network
connection—and cannot receive the device driver’s input in a timely manner.
1.3.4 Another (bigger) example: Files
Sometimes the most critical end user’s view of an OS is the file system—in particu-
lar, file names. Can file names contain spaces? How long can they be? Are upper-
and lowercase letters allowed? Are they treated as different or the same characters?
How about non-English characters or punctuation? An OS may even be called good
or bad simply because long file names are not used or the difference between upper-
and lowercase characters is not distinguished.
In the application programmer’s view, the file system is a frequently used,
critical part of the system. It provides commands for creating a new file, using an
existing file, reading or appending data to a file, and other file operations. There
may even be several different types of files provided by the system. The system
Application
Program
Device
Drivers
Interrupt
Routines
Memory
Mouse
Controller
Video
Controller
Bus
Cursor
motion
Mouse
motion
FIGURE 1.1
The cursor tracking
mouse motion.
elm49810_ch01_001-018.indd 9
elm49810_ch01_001-018.indd 9 12/10/08 10:15:55 PM
12/10/08 10:15:55 PM

Confirming Pages
view of the file system is so large it is usually divided into subparts: file naming and
name manipulation (directory services), file services such as locating and mapping
a file name to its data (file allocation and storage), trying to keep parts of open files
in main memory to speed up access to its data (file buffering and caching), and the
actual management of the storage devices (disk scheduling).
For example, suppose that a user types the name of a file to be copied from a CD
to a hard disk. The program may first need to see whether that file exists on the CD,
and if it would overwrite a file with that name on the hard disk. The OS then needs to
create an entry for the file in the hard disk directory, find space on the hard disk for
storing the data, and find and get the data from the CD, which has been recorded in
pieces (sectors) that will be copied. And all this should be done in a few seconds or
even a fraction of a second! See Table 1.2.
1.4 SOME OS TERMS, BASIC CONCEPTS, AND ILLUSTRATIONS
We now list and define some important OS concepts and terms. Then we give some
diagrams to illustrate these concepts.
1.4.1 Basic terminology
Operating System (or just System). Although we can give different definitions
based on the different views of an OS, the following informal definition is a good
starting point: The OS is a collection of one or more software modules that manages
and controls the resources of a computer or other computing or electronic device,
and gives users and programs an interface to utilize these resources. The managed
resources include memory, processor, files, input or output devices, and so on.
Device. A device is a piece of hardware connected to the main computer system
hardware. Hard disks, DVDs, and video monitors are typical devices managed by
an OS. Many devices have a special electronic (hardware) interface, called a device
controller, which helps connect a device or a group of similar devices to a computer
TABLE 1.2 The Steps in Copying a File from a CD to a Hard Disk
Check for file on CD
Check for file on hard disk—confirm overwrite
Create file name in hard disk directory
Find space for file on hard disk
Read data sectors from CD
Write data sectors to hard disk
Update hard disk directory
Update hard drive space information
Do all this in seconds (or less!)
elm49810_ch01_001-018.indd 10
elm49810_ch01_001-018.indd 10 12/10/08 10:15:55 PM
12/10/08 10:15:55 PM

Confirming Pages
system. Examples include hard disk controllers and video monitor controllers. There
are many types of hard disk controllers that usually follow industry standards such
as SCSI, SATA, and other common but cryptic acronyms. Device controllers are the
hardware glue that connects devices to the main computer system hardware, usually
through a bus.
Device driver. A device driver is a software routine that is part of the OS, and is used
to communicate with and control a device through its device controller.
Kernel. This term usually refers to that part of the OS that implements basic func-
tionality and is always present in memory. In some cases the entire OS is created as
one monolithic entity and this entire unit is called the kernel.
Service. Services are functions that the OS kernel provides to users, mostly through
APIs via OS calls. These services can be conveniently grouped into categories based
on their functionality, for example, file manipulation services (create, read, copy),
memory allocation services (get, free), or miscellaneous services (get system time).
The key to a programmer’s understanding a system is to understand the OS services
it provides.
Utility. These are programs that are not part of the OS core (or kernel), but work
closely with the kernel to provide ease of use or access to system information. A
shell or command interpreter is an example of a utility. The shell utility provides
a user interface to many system services. For example, user requests such as listing
file names in a directory, running a program, or exiting (logging out), may all be
handled by the shell. The shell may invoke other utilities to actually do the work; for
example, directory file listing is sometimes a utility program itself.
1.4.2 How about some pictures?
Figure 1.2 is a simplified view of a small personal computer showing some basic
devices connected to the computer memory and CPU (processor). The OS program
(or kernel) will include various device drivers that handle the peripherals (devices) of
the system under CPU control. For example, part of the contents of memory may be
transferred to the video controller to be displayed on the monitor, or the contents of a
part of the disk (a sector) may be transferred to the disk controller and eventually to
memory (for a disk read operation).
Figure 1.3 is a simplistic view of part of an OS. The OS controls (or manages)
the system resources: it controls the disks, keyboards, video monitor, and other
devices. It controls allocation of memory and use of the CPU by deciding which pro-
gram gets to run. It provides services to the shell and other programs through the use
of system calls. It also provides an abstraction of the hardware by hiding complex
details of hardware devices from programs.
Figure 1.3, a common one used to illustrate OSs, is a logical view, not a physi-
cal one. For example, the OS kernel physically resides inside the memory unit and
it is running (executing) on the CPU. Thus, the arrows between the kernel—which
is software—and the devices—which are hardware—represent a logical control, not
physical.
elm49810_ch01_001-018.indd 11
elm49810_ch01_001-018.indd 11 12/10/08 10:15:55 PM
12/10/08 10:15:55 PM

Confirming Pages
Shell
(Command
Interpreter)
Utilities
Devices
(disks, keyboards)
Memory CPU
Other
Programs
(browsers,
games, word
processing)
Operating System Kernel
FIGURE 1.3
A simplistic view
of the OS software
in relationship to
hardware.
Bus
Bus
CPU
CPU
Memory
Memory
Keyboard
Controller
Keyboard
Controller
Video
Controller
Video
Controller
Disk
Controller
Disk
Controller
Hard
Disk
Hard
Disk
Video
Monitor
Video
Monitor
Keyboard
Keyboard
FIGURE 1.2
Hardware: A very
simplistic view of
a small personal
computer.
(Note: This picture is too
simple. In reality there
are often multiple buses,
say between video and
memory. We will get to
more detailed pictures in
the Appendix.)
Figure 1.4 represents a layered view of the OS, where the outermost circle rep-
resents the utilities/applications layer that accesses the OS kernel layer, which in turn
manages access to the hardware layer.
1.4.3 Closer to reality: A personal computer OS
Figure 1.5 shows more detail of a simple OS for a personal computer or PC. The OS
has two additional components that were not shown in Figure 1.3: device drivers
elm49810_ch01_001-018.indd 12
elm49810_ch01_001-018.indd 12 12/10/08 10:15:57 PM
12/10/08 10:15:57 PM

Confirming Pages
and a BIOS (Basic Input/Output System). The BIOS abstracts the hardware—that
is, the BIOS manages common devices, such as keyboards, basic video, and the sys-
tem clock. This allows the main or higher-level part of the OS to deal with all devices
of the same type—for example, all keyboards—in the same way. Thus, the OS kernel
does not change whether a keyboard has 88 keys, 112 keys, or some other number,
or even in cases where keys may not appear where they might on different keyboards
because of different language characters or accent keys. Device drivers also provide
a similar abstraction to similar devices. For example, a DVD device driver can be
supplied by a device manufacturer to provide an abstract or common view of the
DVD device to the OS, so that the OS does not have to vary with every idiosyncrasy
of DVD drives, regardless of the manufacturer.
The next section elaborates further on why it is important to provide abstraction
layers when designing an OS.
Hardware
OS Kernel
Applications+
Utilities+Shell
FIGURE 1.4
A layered view
of an OS.
Shell
(Command
Interpreter)
Utilities
Operating System Kernel
Device Drivers
Device
(disks, keyboards) Memory CPU
BIOS
(interface to hardware)
Other
Programs
(browsers,
games, word
processing)
FIGURE 1.5
The PC (small
system) model
of an OS.
elm49810_ch01_001-018.indd 13
elm49810_ch01_001-018.indd 13 12/10/08 10:15:57 PM
12/10/08 10:15:57 PM

Confirming Pages
1.4.4 Why the abstraction layers?
Good question. Early in the days of personal computers, computer hobbyists had
fun assembling and building the hardware and getting simple programs to work,
usually written in assembly language or machine language. This was a good learn-
ing tool for some, but programming was very tedious. But people wanted to enjoy
the experience of writing more interesting and therefore larger and more complex
programs. So better tools were needed. These tools include easy-to-use editors and
compilers or interpreters for high-level languages. For end users, the desire was
to use the computer as a business or productivity tool. These users needed word
processing, spreadsheets, and communication software. Certainly there were many
very dissimilar computer hardware systems being built. But there were also a num-
ber of similar, but not identical, computers, built by many manufacturers. These
systems might either have the same CPU from the same CPU manufacturer, or use
a compatible CPU that had the same instruction set. However, they may have video
devices that were quite different. For example, one system might have a terminal-
like device attached to a serial port, whereas another might have a built-in video
controller with many capabilities for advanced graphics. Keyboards would typically
differ in function keys or “arrow” or cursor movement keys, with other keys being
added or missing.
In order for programmers to be able to create programs that would run on these
different systems with minor or no changes required to the program when moving it
to a different system, the OS provided the same interface to the hardware for all the
different devices supported by that OS. For instance, a program could read a key-
stroke from a keyboard regardless of what type of keyboard it was by a system call
to read a key. The OS would take care of translating the keys which were in different
places on different keyboards or which were coded differently.
To avoid the complexity and cost of having different versions of the OS for dif-
ferent keyboards, different video monitors, different disks, and so forth, the OS was
split into a part that was adapted to the different hardware devices (the BIOS and
device drivers) and a part that remained the same for all hardware (shown as the ker-
nel in Figure 1.5). This technique of dividing complicated work into several layers,
or levels, is an established software technique used in large and complex software
systems including OSs. Thus, adapting an OS to a new compatible computer system
with different devices involved changing (or writing) a BIOS but using the same
module for the rest of the kernel and the same programs and utilities. This was a very
attractive idea for everyone—users, manufacturers, and OS writers.
A problem arose when a computer peripheral manufacturer (e.g., a video card
manufacturer) designed a new device and wanted to sell it to users so they could
upgrade their computer to newer hardware designs. Often the existing BIOS in
the computer was installed in ROM (read only memory) and would be difficult
and expensive to replace. The solution to this problem was the creation of a modi-
fiable BIOS by allowing device drivers to be loadable at the time the OS was
loaded into memory. Having BIOS code that could be replaced when the system
was booted allows adding new features to the computer or replacing features in
the BIOS with new software and perhaps supporting new functions on existing
hardware.
elm49810_ch01_001-018.indd 14
elm49810_ch01_001-018.indd 14 12/10/08 10:15:57 PM
12/10/08 10:15:57 PM

Confirming Pages
1.5 A SMALL HISTORICAL DIVERSION
We close this chapter with a historical perspective on how OSs were developed, and
the different views about what type of functionality should be included in an OS. We
give a more detailed historical timeline of OS development at the end of Chapter 3,
after we have introduced some additional concepts.
1.5.1 Origins of operating systems
Before personal computers there were of course many larger computers. Early on
these machines were very large and very expensive, but by modern standards primi-
tive, and there were few programmers. Programs were limited in their capabilities
because main memory was quite small, the CPU processors were very slow, and only
a few simple input and output devices existed. A typical early computer system may
have had a few thousand words3
of main memory, a processor that executed several
thousand instructions per second, and a Teletype4
device for input/output. The lim-
ited capabilities of these early computers required very careful and well-thought-out
programs which were mostly written in the basic machine code of the computer,
machine language or assembly language.
These programs were amazing in that in a few hundred or thousand machine
instructions they accomplished a tremendous amount of work. But they all faced
similar needs: How can a program print some output? How can a program get loaded
into memory to begin execution? These needs—the need to load programs into
memory, to run a program, to get input and produce output—were the impetus for
creating early OSs. At those early times the few programmers on a system knew each
other and would share routines (program code) that had been debugged to simplify
the job of programming. These shared routines (e.g., “print the value in register A on
the Teletype”) would eventually be combined into a library that could be combined
(linked) with an application program to form a complete running program.
These early computers were single-user systems. That is to say that only one
user—and one program—could run at any one time. Typically programmers would
reserve the use of the computer in small blocks of time—perhaps increments of
10–15 minutes. A programmer would use this time to run or debug a program.
Because computers were expensive and computer time was very valuable, often big-
ger blocks of time were available only in the middle of the night or early in the morn-
ing when things were quieter, few managers were around, and one could get much
more done than in the daytime. This tradition, started in the early days of computing,
is one of the few that has lasted until today!
The programs, once written and assembled, were linked or bound with utility
routines for input, output, mathematical functions,5
printout formatting, and other
3
A word was typically six characters, but differed from system to system.
4
A Teletype is an electromechanical printer and keyboard, built for telegraphy, that could print or type at
a speed of a dozen or so characters per second.
5
Early computer hardware often did not have instructions for complex mathematical and even arithmetic
operations—for example, long division—so these operations were implemented in software utility routines.
elm49810_ch01_001-018.indd 15
elm49810_ch01_001-018.indd 15 12/10/08 10:15:58 PM
12/10/08 10:15:58 PM

Confirming Pages
common tasks, into an executable program ready to be loaded into memory and run.
The program might be stored on punched paper tape or punched cards. The computer
hardware would know how to start reading from the input device, but it would only
load the first card or the first block of the tape. So that block had to include a small
routine that would be able to load the rest of the application into memory. This short
routine is called a loader. The loader would in turn read the programmer’s execut-
able program and put it and the needed utility routines into memory at a specified
location, usually either the first memory address or some special fixed location. Then
it would transfer execution—by a branch or “subroutine” call—to the program it
had loaded. The loadable program tape or card deck might look as illustrated in
Figure 1.6.6
The END delimiter tells that loader that there are no more routines to be
loaded since there might be data records following the routines.
As programmers had time to develop more utility routines, the loader grew more
sophisticated. Loaders were soon able to load programs that had been translated
(compiled) from higher-level programming languages. As the size of loaders, util-
ity routines, and users’ programs grew, the card decks or paper tapes became very
large (and it became unfortunately common to drop a card deck or tear a paper tape).
These loaders and utility routines would become the beginnings of early OSs, which
were then often called monitors.
1.5.2 What should an Operating System do (or what should
it support)?
From the early days of computing until today there has been a fierce debate—
ranging from polite discussion to a political or almost religious argument—about
what an OS should do. The two extreme views of this debate could be called the
maximalist view and the minimalist view. The maximalist view argues that the OS
should include as much functionality as possible, whereas the minimalist view is that
only the most basic functionality should be part of the OS. From the early systems,
the question started: “Should all the routines for input and output be included in my
program? I don’t even read from the card reader.” Including too many routines—any
that are not necessary—makes the memory available for my program smaller, and
it is too small to begin with. How can one get just what one needs? Mathematical
routines such as programs for performing floating-point arithmetic could be done
once in the OS rather than separately included in each user’s program. But then
every program incurred the overhead of the extra memory occupied by these routines
in the OS, even programs like accounting applications that did not use floating point
arithmetic.
6
This type of loader is often known as a bootstrap loader.
Bootstrap
Loader
Application
Program
Library
Routines
I/O
Routines
END
Delimiter
FIGURE 1.6
An application
program with a
loader and OS-like
utilities.
elm49810_ch01_001-018.indd 16
elm49810_ch01_001-018.indd 16 12/10/08 10:15:58 PM
12/10/08 10:15:58 PM

Confirming Pages
In more recent times the debate concerning what to include in an OS continues.
For example, a user-friendly OS interface is now commonly considered to have
a pointing device—such as a mouse, trackball, or pad—and some type of screen
windowing with pull-down menus. Whether that interface should be a part of the
OS—thus giving all applications a similar “look and feel,” or part of the shell—to
allow each user to decide the particular look they want is one of the current issues of
the debate about what the OS should include.
To be fair, like many hotly contested issues, both maximalist and minimal-
ist sides have a point. The historical trends are not clear. Newer OSs have been in
some cases smaller, simpler, and more configurable and in other cases exactly the
opposite—larger, more functional, and more constraining. This issue of what func-
tionality should go where (in the OS kernel or not) has created different design
possibilities for OSs, as we discuss further in Chapter 2.
1.6 SUMMARY
In this chapter, we first introduced some of the
basic functionality of operating systems. We gave
a few simple examples to illustrate why OSs are
so important. Then we discussed the different
views of what an OS does by looking at the OS
from two perspectives: the user’s perspective and
the system’s perspective. We then presented some
basic terminology and concepts, and provided some
figures to illustrate typical components of simple
OSs. Next we began to look at a few architectures
that are commonly used to actually create OSs and
discussed the very idea of abstraction that is so
fundamental to the successful design of OSs. We
concluded with a brief historical perspective on the
origins of OSs.
The next chapter gives an overview of the major
components of an OS and discusses the architecture
alternatives in more detail.
REVIEW QUESTIONS
1.1 Give a one-sentence definition of an OS.
1.2 Since most of us are not going to be writing an OS,
why do we need to know anything about them?
1.3 Give three reasons why a simple device such as a
handheld electronic game probably contains an OS.
1.4 What is the primary difference between a user
view of an OS and a system view?
1.5 What are the four different classes of users that
were discussed, and what aspects of an OS are
they mostly interested in?
1.6 The chapter discussed how the different users are
supported from the system view. Two examples
were presented, moving a mouse and file systems.
Consider another aspect of an OS and discuss how
the system view works to support the three differ-
ent classes of users.
1.7 Should OSs be proprietary so that the manufactur-
ers will be able to make enough profit to continue
their development or should the internals and spec-
ifications of OSs be open for all users to know?*7
1.8 With respect to the study of OSs, how is a control-
ler best defined?
1.9 What is the general principle of abstraction?
1.10 What are some of the reasons why we want
abstraction in an OS?
1.11 Distinguish between an OS and a kernel.
1.12 Describe briefly the origins of OSs on the early
large mainframe systems.
1.13 Should the characteristics of a windowing inter-
face—the factors that determine its look and
feel—be a part of the OS kernel or part of the
command shell?
* Note to instructors: Don’t use this question as part of the class
unless you have nothing else to talk about for the day.
elm49810_ch01_001-018.indd 17
elm49810_ch01_001-018.indd 17 12/10/08 10:15:58 PM
12/10/08 10:15:58 PM

elm49810_ch01_001-018.indd 18
elm49810_ch01_001-018.indd 18 12/10/08 10:15:58 PM
12/10/08 10:15:58 PM

Confirming Pages
19
Chapter
Chapter 2
2
Operating System
Concepts, Components,
and Architectures
In this chapter:
2.1 Introduction: What Does the OS Do? 20
2.2 Resources Managed by the OS and Major OS Modules 22
2.3 The Process Concept and OS Process Information 25
2.4 Functional Classes of OSs 29
2.5 Architectural Approaches to Building an OS 33
2.6 Some OS Implementation Techniques and Issues 35
2.7 Minimalist versus Maximalist Approaches to OS Functionality
and Backward Compatibility 40
2.8 Summary 42
I
n this chapter, we discuss in general what the operating system does, and give
an overview of OS concepts and components so that a student has some overall
perspective about OSs. We also discuss some common techniques employed in
nearly all OSs.
To gain some understanding of how the OS is involved in practically all system
operations, we start in Section 2.1 with a simple user scenario and describe some
of the actions within the scenario that are undertaken by the OS. In Section 2.2 we
give an overview of the main types of system resources that the OS manages. These
resources include the processor (CPU), main memory, I/O devices, and files. We
then give an overview of the major OS modules, and the services that each module
provides. These include the process management and CPU scheduling module, the
memory management module, the file system module, and the I/O management
and disk scheduling module. These may or may not be implemented as separate
modules in any particular OS, but looking at each of these separately makes it
easier to explain OS concepts.
elm49810_ch02_019-044.indd 19
elm49810_ch02_019-044.indd 19 12/10/08 9:27:32 PM
12/10/08 9:27:32 PM

Confirming Pages
Then in Section 2.3 we define the concept of a process, which is central to what
the OS does, and describe the states of a process and some of the information that
the OS maintains about each process. A process (sometimes called job or task)1
is
basically an executing program, and the OS manages system resources on behalf of
the processes. In Section 2.4 we discuss the characteristics of different types of OSs,
from systems that can run or execute a single process at a time, to those that manage
concurrently executing processes, to time sharing and distributed systems.
In Section 2.5 we present some of the different architectural approaches that
have been taken for OS construction. These include monolithic OS, microkernels,
and layered architectures. We then describe some implementation techniques that
are used repeatedly by various OS modules in Section 2.6. These include the queues
that are maintained by multitasking OSs to keep track of the jobs that are waiting
to acquire resources or to have certain services performed. For example, processes
could be waiting for disk I/O or CPU time or printing services. We also describe
interrupts and how they are handled in some detail, object-oriented OS design, and
virtual machines. Section 2.7 gives a philosophical discussion concerning what func-
tionality should be part of an OS. Finally, in Section 2.8 we summarize this chapter.
2.1 INTRODUCTION: WHAT DOES THE OS DO?
In this section, we go over a small example scenario, in order to see how the OS is
involved in nearly every aspect of computing. Consider the following simple user
scenario:
A user wants to type a small note to himself.2
Coming into work this morning he
heard a radio advertisement that his favorite music group is coming to town, and he
wants to have a reminder to buy tickets and invite some friends. So he starts a sched-
uling program (or possibly a text editor or a word processing program), types in his
reminder, saves the document, and exits. The user could have used a PDA (personal
digital assistant), a Windows-based system (e.g., Mac, MS Windows or Linux with a
GUI-based text editor), or simply a text-based command shell such as UNIX. Let’s
assume he is using a GUI-based text editor to write a separate note and save it as a
file. Regardless of the type of system used, this scenario caused the OS to create,
manage, and terminate software components to accomplish the work. When the user
started the editor or some other program he created a process (also called task or
job).3
A process is basically a program in execution. A process may be waiting to
run, currently running, waiting for something to happen, or finishing. Some of the
events that a process may be waiting for include a keystroke from the user, or some
data to be read from a disk drive or to be supplied by another program.
Before a process can be started, the executable program file (binary) that will be
run must be brought into main memory. This is usually loaded from a disk or some
1
The terms job and task are used to refer to the same concepts in some of the literature, and to different
concepts in other literature. We discuss this as needed in the footnotes.
2
For grammatical simplicity, this text will assume the user is a male.
3
Starting a program is sometimes called instantiating, executing, loading, or running the program.
elm49810_ch02_019-044.indd 20
elm49810_ch02_019-044.indd 20 12/10/08 9:27:34 PM
12/10/08 9:27:34 PM

Confirming Pages
Chapter 2 Operating System Concepts, Components, and Architectures 21
electronic memory such as a flash drive. Several major OS activities are needed to
accomplish this. First, a portion of main memory is needed to hold the program’s
executable code. Additional memory is needed for the program’s data, variables, and
temporary storage. In our example, the data would be the entry that the user is creat-
ing in the memo file. These activities to allocate memory are part of the memory
management that the OS must do. Often several programs may be in memory at the
same time. The OS memory manager module controls which processes are placed
into memory, where they are placed, and how much memory each is given. Process
management—deciding which process gets to run, for how long, and perhaps at
what priority (or level of importance)—is another key management activity of the
OS, usually handled in part by the OS CPU scheduler.
Once the editor process is running, it needs to accept some keystrokes and
display what has been typed on the screen. Even if the device is a PDA with no
keyboard, characters are input and accepted by the OS in some manner. Acquiring
keystrokes or characters and displaying those characters on the screen are done in a
series of steps through the I/O and device management component of the OS.
When our user hits a key, he enters a character that must be read by the sys-
tem. The device—in this case a keyboard—inputs the information about the raw key
action. This information—the row and column of the key’s position on the keyboard
and whether it was pressed or released—is stored in a temporary buffer. In a PDA
or PC, there may be a special keyboard controller chip that saves the key action
information and then sends an interrupt to the processor. The processor may have its
own keyboard device controller in addition to the controller chip on the keyboard.
The interrupt causes the CPU to stop the process that is running. This may be done
immediately if the CPU is doing lower priority work, or it may be done later if the
CPU had been doing higher priority work. Then an interrupt service routine is started
by the OS to handle the keyboard action. The interrupt service routine is a part of the
interrupt handling and device control in the OS. This processing is repeated for each
character typed. The character must be sent to the editor process and displayed on
the screen—another action that goes through the OS. In this case, an output opera-
tion to the video monitor is performed.
When our user finishes typing his note, he saves his note as a file.This may involve
moving a pointing device such as a mouse to point to the file menu on the screen. The
mouse movement and clicking are handled first by a device controller—which tracks
the mouse coordinates and sends them to the OS. The mouse tracking icon (e.g., an
arrow) must be moved and displayed on the monitor display screen—another output
to the screen. When the mouse button is clicked, the controller sends that informa-
tion to the OS, which forwards the coordinates where the clicking occurred to the
windowing system that is managing the user interface. The windowing system will
have information concerning which window is currently active and the positions of
various buttons and other icons within that window. Using this information, it will
match the coordinates of the cursor when the user clicked the mouse button to the
particular screen button icon (or symbol) that was “clicked.” The windowing system
that handles user interaction is usually quite complex. It is considered by some to be
a systems program, separate from the OS, and by others to be an integral part of the
OS (see Section 2.7 for a discussion on what is and is not part of the OS).
elm49810_ch02_019-044.indd 21
elm49810_ch02_019-044.indd 21 12/10/08 9:27:34 PM
12/10/08 9:27:34 PM

Confirming Pages
Continuing with our scenario, our user may now choose a directory called “personal
notes” within which he wants to store his file. This brings into play the file management
component of the OS. When the user selects the directory (e.g., by double-clicking on a
folder icon), this causes the OS file manager to take several actions. First, it must open
the directory by retrieving the directory information from the OS internal tables. The
directory information includes the names of files (and possibly other directories) stored
under this directory as well as where the directory is stored on disk. The user must then
type a file name such as “concert_remind,” and the file system will check to make sure
that no existing file in that directory has the same name. It may then invoke the disk
space allocation module to find an area of free space on disk to store the file. Finally, the
OS file manager will create a file entry in the directory to contain the information about
the new file such as its name, file type, and disk location.
As we can see from this very simple example, the OS is involved in practically
every aspect of user and program interaction—from low-level actions such as pro-
cessing keyboard strokes and mouse movements, to resource allocation algorithms
such as allocating memory space and processor time, to higher-level actions such as
managing file names and directories. We describe how the OS handles all these vari-
ous tasks throughout this book.
2.2 RESOURCES MANAGED BY THE OS AND MAJOR
OS MODULES
A major role of an OS is the management of the system resources, so this section
covers the main types of resources that the OS manages. Then it covers a conceptual
view of a typical OS, showing the major OS modules, the resources that each module
manages, and the services and functions that each module provides.
2.2.1 Types of resources managed by an OS
This section first addresses some of the major resources managed by a typical OS.
These resources are CPUs (processors), main memory and caches, secondary stor-
age, and I/O devices at the lowest level, and file system and user interface at a higher
level. The OS also manages network access and provides security to protect the vari-
ous resources it is managing.
CPU
The OS needs to schedule which process to run on each CPU at any point in time.
In older single-process systems, this is very simple because only one process will be
memory resident so the OS would mainly be responsible for starting the memory-
resident process by giving it control of the CPU. However, even in such a simple sys-
tem, the OS must do other tasks such as setting up any memory protection registers
and switching to user execution mode before giving the process control of the CPU.
In multitasking systems, managing the CPU resource is quite complex since
multiple processes will be memory resident. It may be further complicated by having
multiple CPUs in the system. The OS will maintain various queues of processes. The
queue most relevant to CPU scheduling is called the ready queue, which contains all
elm49810_ch02_019-044.indd 22
elm49810_ch02_019-044.indd 22 12/10/08 9:27:34 PM
12/10/08 9:27:34 PM

Confirming Pages
processes that are ready to execute. If processes have different priorities a separate
ready queue may exist for each priority level. Each process is typically given control
of the CPU for a maximum period of time, called a time quantum. If the time quan-
tum expires before the process finishes execution, a timer interrupt would initiate
an OS process called context switching that would switch CPU control to another
process. We discuss how the OS manages the CPU resource and CPU scheduling
algorithms in detail in Chapter 9.
Main memory and caches
The OS needs to assign memory space to a process before it can execute. The execut-
able code of a program will typically be stored on hard disk (or some other secondary
storage medium). When a user or program wants to execute a disk-resident program,
the OS must locate the program code file on disk and it must allocate enough mem-
ory space to hold an initial part of the program. Since many programs are quite large,
the OS might load only part of the program from the disk. One of the main memory
management functions is to allocate initial memory space to a process, and perhaps
to load additional parts of the program from disk as the process needs them. If all
memory space is full, the memory management module of the OS must swap out
some of the memory-resident information so it can load additional portions needed
by the process. We discuss memory management techniques in Chapters 10 and 11.
Secondary storage
Another important resource managed by the OS is secondary storage, which is typi-
cally hard disk. Most program code files and data files are stored on hard disk until
there is a request to load some parts of them into main memory. Whenever a process
requires data or code that are not in memory, a request is sent to the disk schedul-
ing module of the OS. The OS would typically suspend the requesting process until
the required data are read into memory. In a multitasking system, there could be
many requests to read (load into memory) and write (store to disk) disk data. The
OS typically maintains one or more queues for the disk read and write requests, and
uses various algorithms to optimize the servicing of these requests. We discuss disk
scheduling in Chapter 14 as part of our discussion of I/O management.
I/O devices
The OS must also control and manage the various input and output devices con-
nected to a computer system.4
The OS will include modules called device drivers
that control access to these devices. Since there are many different types of I/O
devices and users often add new I/O devices to their systems, modern OSs have the
capability to detect new hardware and install the appropriate device drivers dynami-
cally. A device driver handles low-level interaction with the device controllers, and
presents a higher-level view of the I/O devices to the rest of the OS. That way, the OS
can handle similar devices in an abstract, uniform way. We discuss I/O management
in Chapter 12.
4
It is not uncommon to consider disk management as part of I/O management since both disks and I/O
devices either input (read) or output (write) bytes to/from main memory.
elm49810_ch02_019-044.indd 23
elm49810_ch02_019-044.indd 23 12/10/08 9:27:35 PM
12/10/08 9:27:35 PM

Confirming Pages
File systems
The resources discussed so far are considered low level because they are all hardware
resources.The OS also manages higher-level resources that are created through software.
One of the main such resources is the file system. The file system is an OS module that
provides a higher-level interface that allows users and programs to create, delete, mod-
ify, open, close, and apply other operations to various types of files. The simplest type of
file is just a sequence of bytes. More complex file structures are possible—for example,
structuring file contents into records. The file system allows users to give names to files,
to organize the files into directories, to protect files, and to access those files using the
various file operations. We discuss file management in more detail in Chapter 12.
User interfaces
Many modern OSs include another high-level component to handle user interaction.
This includes the functionality for creating and managing windows on a computer
screen to allow users to interact with the system. By having such a component in the
OS, the user can access various resources in a uniform way. For example, access to the
directory of the file system or to Internet documents would be handled through a uni-
form interface.5
We discuss user interfaces in various chapters throughout the book.
Network access
Another resource that the OS manages is network access to allow users and programs
on one computer to access other services and devices on a computer network. An OS
can provide both low- and high-level functionality for network access. An example
of low-level functionality is the capability given to a program to create network ports
and to connect to a port on another machine. An example of high-level functionality
is the capability to access a remote file. We will discuss networks and distributed
systems in Chapters 15 and 17.
Providing protection and security
The OS also provides mechanisms to protect the various resources from unauthor-
ized access, as well as security techniques to allow the system administrators to
enforce their security policies. The simplest type of security is access authorization
through passwords, but generally this is not sufficient. We will discuss security and
protection in Chapter 16.
2.2.2 Major modules of an OS
Figure 2.1 is an illustration of some of the major modules of an OS at an abstract level.
Not surprisingly, many of these modules correspond closely to the resources that are
being managed. Other modules provide common support functions used by several
other modules. The modules provide functions that are accessed by system users and
programs as well as by the other OS modules. Some functionality is restricted so that
it can only be accessed in privileged mode by other OS modules—for example, device
5
As we mentioned earlier, user interfaces are sometimes considered to be part of the systems programs
rather than an integral part of the OS.
elm49810_ch02_019-044.indd 24
elm49810_ch02_019-044.indd 24 12/10/08 9:27:35 PM
12/10/08 9:27:35 PM

Confirming Pages
driver functions are often restricted to OS access. Other functionality is available to
OS modules, users, and application programs—for example, file system functions.
In Figure 2.1, we do not show how the OS modules interact with one another.
This is because the types of interactions depend on the particular architecture used
to implement the OS. For example, in a layered architecture, the modules would be
separated into layers. Generally, modules at one level would call the functions pro-
vided by the modules at either the same level or at lower levels. On the other hand,
in an object-oriented architecture, each module would be implemented as one or
more objects with services, and any object can invoke the services provided by other
objects. In a monolithic architecture, all modules would be implemented as one
giant program. We discuss the most common OS architectures in a later section.
2.3 THE PROCESS CONCEPT AND OS PROCESS INFORMATION
We now introduce the concept of a process, as it is central to presenting OS concepts.
First, we define what a process is, and describe the various states that a process can
go through and the types of events that cause process state transitions. Next, we dis-
cuss the types of information that an OS must maintain on each process in order to
manage processes and resources. We also introduce the concept of a PCB (process
control block), the data structure that the OS maintains to keep track of each process.
Finally, we categorize various types of processes.
2.3.1 Process definition and process states
A process is a running or executing program. To be a process, a program needs to
have been started by the OS. However, a process is not necessarily running all the
time during its existence—for example, it may be waiting for I/O (say, a key to be
pressed) or it may be waiting for the OS to assign it some resource (say, a block of
RAM). Every process has a particular sequence of execution, and hence a program
counter that specifies the location of the next instruction to be executed. It will also
have various resources allocated to it by the OS. For example, it will need some
memory space in which to store all or part of its program code and data (such as
Device
Drivers
Higher-Level
Modules
CPU
Scheduling
Memory/Cache
Management
I/O
Management
Disk
Scheduling
Network
Management
Lower-Level
Modules
Process
Management
File
Management
GUI
Management
Security and
Protection
FIGURE 2.1 The major OS modules.
elm49810_ch02_019-044.indd 25
elm49810_ch02_019-044.indd 25 12/10/08 9:27:35 PM
12/10/08 9:27:35 PM

Confirming Pages
program variables). It will almost certainly be accessing files, so it will probably
have some open files associated with it. A process has also been called a job6
or a
task, and we use these terms interchangeably.
Once a process is created, it may be in one of several states: running (if it has
control of the CPU), ready to run (if other processes currently are using all of the
CPUs), waiting (for some event to occur), and so on. The typical states that a pro-
cess can go through are illustrated in Figure 2.2, which is called a state transition
diagram. The nodes (shown as hexagons) in Figure 2.2 represent process states,
and the directed edges (arrows) represent state transitions. We now discuss these
states, and the events that cause state transitions.7
State transition 0 (zero) creates a new process, which can be caused by one of
the following events:
1. A running OS process may create or spawn a new process. For example, when
an interactive user logs onto a computer system, the OS process that handles
logins typically creates a new process to handle user interaction and commands.
The OS may also create new processes to handle some OS functions such as an
interrupt handler or error handler process.
6
The term job historically referred to a sequence of control that may invoke various tasks using a
language called JCL, or Job Control Language. This interpretation is primarily used in older batch
systems.
7
This state diagram is typical, but for any particular OS there may be other states that the OS designers
want to distinguish among, so one might see fewer or more states internally and in the documentation.
0 - Program
loaded
New
1 - Process
initialized
Ready
4 - Got what
it needed
2 - Gets
CPU time
Run
3 - Needs
something
5 - Interrupted
6 - Finished
or aborted
Exit
7 - Exits
system
Wait
FIGURE 2.2
Simplified diagram
of process states
and transitions.
elm49810_ch02_019-044.indd 26
elm49810_ch02_019-044.indd 26 12/10/08 9:27:35 PM
12/10/08 9:27:35 PM

Confirming Pages
2. A user process may also create another process by calling the OS function for
new process creation. For example, a Web browser might create a new process
to run an external “plug-in” module to handle a particular type of multimedia
content accessed on a website.
3. When a job is started by the OS as a scheduled event (e.g., a “cron” job on a
UNIX system), the OS creates a process to execute that job.
As a new process is being created, it is in the new state. The OS must build the table
that will hold information about the process (see Section 2.2.2), allocate necessary
resources (e.g., memory to hold the program), locate the program executable file and
any initial data needed by the process, and execute the appropriate routines to load
the initial parts of the process into memory. State transition 1 in Figure 2.2 shows
that the OS moves a process from the new state to the ready state, which indicates
that the process is now ready to execute. Note that before this transition can occur
the OS must be ready to add a new process—for example, some OSs may have a
maximum number of allowed processes at a given time and hence would not permit
a new process to be added if the maximum is already reached. In a large mainframe
system or cluster system there might also be resource requirements that the job must
have available before it can run—perhaps a specific I/O device or a certain number
of CPUs. After all this initialization has occurred, the process can be moved to the
ready state.
Even after a process is in the ready state, it does not start executing until the
OS gives it control of the CPU. This is state transition 2 in Figure 2.2. The process
is now executing, and is in the running state. If there is more than one process in
the ready state, the part of the OS that chooses one of those to execute is called
the CPU scheduler or process scheduler. We discuss process scheduling in detail in
Chapter 9.
If a process executes until its end or has an error or exception that causes the
OS to abort it, these events—a process reaching its end or having a fatal error—will
cause state transition 6 in Figure 2.2. This leads a process to the terminated state, at
which point the OS will do cleanup operations on the process—for example, delete
the process information and data structures and free up the process memory and
other resources. When this cleanup is completed, this indicates state transition 7 in
Figure 2.2, which causes the process to exit the system.
Two other state transitions may occur when a process is in its running state—
transitions 3 and 5 in Figure 2.2. State transition 3 occurs if the process requires
some resource that is not available or if it needs some I/O to occur—for example,
waiting for a keystroke or reading from a file—before it can continue processing.
This leads a process to the wait or blocked state. A process remains in the wait
state until the resource it needs is allocated to it or its I/O request is completed, at
which point state transition 4 occurs to move the process from the wait state back
to the ready state. On the other hand, state transition 5 from running state directly
to ready state typically occurs when the OS decides to suspend the process because
it has more urgent processes to run. This may be because of a timer or some other
kind of interrupt, which can occur for various reasons. The most common reason is
to allocate the CPU to another process because of the CPU scheduling algorithm, as
we describe in Chapter 8.
elm49810_ch02_019-044.indd 27
elm49810_ch02_019-044.indd 27 12/10/08 9:27:36 PM
12/10/08 9:27:36 PM

Confirming Pages
2.3.2 Process information maintained by the OS
To keep track of a process, the OS typically assigns to it a unique process identifier
(or process ID). It also creates a data structure called a process control block (or
PCB) to keep track of the process information, such as the process ID, resources it
is using or requesting, its priority, its access rights to various system resources or
files, and so on. The PCB will also include references to other OS data structures that
include information on how to locate the memory space and open files being utilized
by the process. For processes not in the running state, the PCB will save informa-
tion on the hardware processor state for the process, such as the values stored in the
program counter register and other processor registers. This information is needed
to restart the process when it moves back to the running state. Figure 2.3 illustrates
some of the information that is typically kept in a process control block.
The information on open files that the process is using is typically kept in a
separate OS data structure, which is created and used by the OS file manager module
(see Chapter 12). The information on which areas of memory are occupied by the
process is usually kept in page tables or limit registers that are created and used by
the OS memory management module (see Chapters 10 and 11). Both these tables are
referenced from the PCB data structure. Additional information, such as the process
priority level, and a reference to the security or protection levels of the process (see
Chapter 16) will also be included in the PCB.
2.3.3 Types of processes and execution modes
We can categorize processes into several types:
1. User or application processes. These are processes that are executing applica-
tion programs on behalf of a user. Examples include a process that is running an
accounting program or a database transaction or a computer game.
Unique process identifier
Process priority information
Processor state
(CPU register contents,
current instruction location)
Pointer to data structure to access process
memory (typically page tables or limit registers)
Pointer to data structure to access process
files (usually called open files table)
Other process information
Process security and authorization information
FIGURE 2.3
Information the
OS maintains in
a process control
block.
elm49810_ch02_019-044.indd 28
elm49810_ch02_019-044.indd 28 12/10/08 9:27:36 PM
12/10/08 9:27:36 PM

Confirming Pages
2. Systems program processes. These are other application programs that perform
a common system service rather than a specific end-user service. Such programs
often interact closely with the OS and need special information about interfaces
and system structures such as the layout of a relocatable program module or an
executable program file. Examples include programming language compilers
and program development environments. Other programs such as Internet brows-
ers, windowing user interfaces, and OS shell programs are considered by some to
be in this category, and by others to be part of the OS itself (see Section 2.7).
3. OS processes. These are also known as daemons and are processes that are exe-
cuting OS services and functions. Examples include memory management, pro-
cess scheduling, device control, interrupt handling, file services, and network
services.
Almost all processors have two execution modes for processes: privileged mode
and nonprivileged or regular (user) mode. OS kernel processes typically execute
in privileged mode—also known as supervisor mode, kernel mode, or monitor
mode—allowing them to execute all types of hardware operations and to access all
of memory and I/O devices. Other processes execute in user mode, which prohibits
them from executing some commands such as low-level I/O commands. User mode
also brings in the hardware memory protection mechanism, so that a process can
only access memory within its predefined memory space. This protects the rest of
memory—used by the OS and other processes—from erroneous or malicious access
to their memory space that may damage their data or program code.
2.4 FUNCTIONAL CLASSES OF OSs
There are many different types of OSs. Some OSs are quite restricted and provide lim-
ited services and functions, whereas other OSs are very complex, and provide many
services and a wide range of functionality. We now give a brief overview of five types
of OSs: single-user, multitasking, time-sharing, distributed, and real-time systems.
2.4.1 Single-user single-tasking OS
A single-user single-tasking OS runs a single process at a time. The first OSs were
of this type, as were OSs for early personal computers such as CP/M and earlier ver-
sions of MS-DOS. Similar OSs may be found today in systems with limited resources
such as embedded systems. Such an OS is not as complex as the other OSs we discuss
below. However, there are still a lot of details and issues that it must handle. The main
services it provides would be handling I/O and starting and terminating programs.
Memory management would be fairly simple since only the OS and one process
reside in memory at any particular time. There would be no need for CPU schedul-
ing. Following our spiral approach, we describe the basic services and functionality
provided by a single-user OS in Chapter 3. We use primarily CP/M as an example to
illustrate how these concepts were implemented in a real system. We also mention
MS-DOS from time to time since it dominated the OS market for quite some time.
elm49810_ch02_019-044.indd 29
elm49810_ch02_019-044.indd 29 12/10/08 9:27:36 PM
12/10/08 9:27:36 PM

Confirming Pages
2.4.2 Multitasking OS
The next level in OS complexity is a multitasking or multiprogramming OS.
Such an OS will control multiple processes running concurrently. Hence, it must
have a CPU scheduling component to choose which of the ready processes to run
next. The majority of modern-day computers support multitasking. One of the ini-
tial reasons for creating multitasking OSs was to improve processor utilization by
keeping the CPU busy while I/O is performed. In a single-tasking system, if the
single running process requests I/O and needed to wait for the operation to com-
plete, then the CPU would remain idle until the I/O request was completed. By hav-
ing several processes ready to execute in memory, the CPU can switch to running
another process while I/O is performed. Changing from running one process to run-
ning another is known as context switching. But there is a high cost for a context
switch. The entire CPU state must be saved so that it can be restored when the pro-
cess is later restarted. Basically, when a running process—say process A—requests
I/O that can be handled by an I/O controller, the OS CPU scheduler module would
check to see if there are any processes in the ready state. If there are, one of the
ready processes—say, process B—will be selected based on the CPU scheduling
algorithm. The OS will save the processor state of process A (in A’s PCB) and load
the processor state of process B (from B’s PCB) into the appropriate CPU registers.
The OS will then give control of the CPU to process B, which moves to the running
state, while process A moves to the waiting (or blocked) state until the I/O opera-
tion is complete.
Multitasking is now available in most computer OSs, including personal com-
puters. Even though a PC typically has a single interactive user, that user can
create multiple tasks. For example, if there are multiple windows on the display
screen, each is often handled by a separate task or process. In addition, other tasks
may be running in the background. Some early multitasking OSs could handle
only batch jobs—which were loaded on disk in bulk through card readers or other
old-fashioned I/O devices. Many current systems handle both batch jobs and inter-
active jobs. Interactive jobs are processes that handle a user interacting directly
with the computer through mouse, keyboard, video monitor display, and other
interactive I/O devices.
We can further distinguish between two types of multitasking OSs: those that
usually interact with a single user and those that support multiple interactive users.
Single-user multitasking systems include most modern PCs that support windowing.
In such systems it is common that one user is interacting with the system but that the
user may have several tasks started simultaneously. For example, the user may have
an email program, a text editor, and a Web browser, all open at the same time, each in
a separate window. The task that has the current user focus is called the foreground
task, while the others are called background tasks. The other type of multitasking
system handles multiple interactive users concurrently, and hence is called a time-
sharing OS. We discuss these next.
In our spiral approach part we describe two examples of single-user multitasking
OSs: an OS for a handheld Palm Pilot device in Chapter 4 and the Mac OS fromApple
in Chapter 5.
elm49810_ch02_019-044.indd 30
elm49810_ch02_019-044.indd 30 12/10/08 9:27:36 PM
12/10/08 9:27:36 PM

Confirming Pages
2.4.3 Time-sharing OS and servers
A multiuser or time-sharing OS also supports multitasking, but a large number of the
tasks (processes) running are handling users interacting with the machine. These were
called time-sharing systems because the computer time was “shared” by the many
interactive concurrent users. In terms of OS internals, the main difference between
interactive and batch processes is in their response requirements. Interactive jobs typi-
cally support many short interactions, and require that the system respond rapidly to
each interaction. But quick response to interactive users’ requirements calls for a high
level of context switching and this introduces a lot of nonproductive overhead. Batch
jobs, on the other hand, have no live user so rapid response is not a requirement.
Therefore, less context switching is needed and more time is spent on productive
computing. A time-sharing OS will support both interactive and batch jobs and will
typically give higher priorities for interactive jobs. Early time-sharing systems in the
1960s and 1970s, such as IBM’s OS 360 TSO8
and Honeywell’s MULTICS, sup-
ported large numbers of interactive users, which were all logged in to the same system
through dumb monitors and terminals. This was because terminals cost many orders
of magnitudes less than the computer system itself in those days.
As the price of hardware and processors was being dramatically reduced, the
need for time sharing declined. In modern computing the new generation of systems
that can be considered to be the successors of interactive time-sharing systems are
the systems that are used in file, database, and Web servers. File servers and data-
base servers handle requests for file and database access from tens to thousands of
users. Instead of being located at dumb terminals attached to processes running on
the server, the users are working at PCs or workstations and the service requests are
coming to the server through the network. Large database servers are often called
transaction processing systems, because they handle very many user transactions
per second. Web servers handle requests for Web documents, and often retrieve
some of the document information from database servers. Database and Web servers
require OSs that can handle hundreds of concurrent processes.
2.4.4 Network and distributed OS
Most computers today are either permanently connected to a network, or are equipped
so that they can be connected and disconnected from some type of network. This
allows information and resource sharing among multiple machines, and requires that
the OS provide additional functionality for these network connections. This addi-
tional functionality can be categorized into two main levels:
1. Low-level network access services. The OS will typically include additional
functionality to set up network connections, and to send and receive messages
between the connected machines.
2. Higher-level services. Users want to be able to connect to other machines to
browse through information, download files (text, pictures, songs) or programs of
8
OS 360 TSO stands for Operating System 360 Time Sharing Option.
elm49810_ch02_019-044.indd 31
elm49810_ch02_019-044.indd 31 12/10/08 9:27:36 PM
12/10/08 9:27:36 PM

Confirming Pages
various types, or access databases. This is typically done through Web browsers
or specialized services, such as telnet for logging on to remote machines or ftp
for file transfer. As we mentioned earlier, these services are considered by some
to be independent systems programs and by others to be part of the OS.
The standard network protocols actually provide several levels of service, from the
basic hardware level to the user interaction level, as we will see in Chapter 15. Sepa-
rately from the network connection, a distributed OS can provide a wide spectrum of
capabilities. A very basic distributed OS, sometimes called a network OS, provides
the capability to connect from a machine where the user is logged in—called the
client—to a remote machine—called the server, and to access the remote server.
However, the client user must know the name or address of the specific machine
they want to access. Most current systems provide at least this level of service. For
example, telnet and ftp services fall in this category.
At the other end of the spectrum, a completely general distributed OS may
allow a user logged in at a client machine to transparently access all possible services
and files they are authorized to access without even knowing where they reside. The
OS itself will keep directory information to locate any desired file or service, and to
connect to the appropriate machine. This is known as location transparency. The
files and services may be physically replicated on multiple systems so the OS would
choose the copy that is most easily or most efficiently accessible—known as repli-
cation transparency.9
The OS could also do dynamic load balancing to choose a
machine that is not heavily loaded when choosing a server. Such OSs would obvi-
ously be very complicated, and hence do not yet exist except in the realm of special-
purpose systems or research prototypes!
Between the two ends of the spectrum, one can consider many types of distrib-
uted OSs that can provide more than the minimum capabilities but less than the full
wish list of capabilities.
2.4.5 Real-time OS
Real-time OSs are multitasking systems that have the additional requirement of time
deadlines for completing some or all of their tasks. Two types of deadlines are:
1. Hard deadlines. A task with a hard deadline of, say, n milliseconds must be
completed within n milliseconds of submission; otherwise, it would be useless
and there may be very bad consequences for missing the deadline. Examples of
such tasks include industrial control tasks in a steel mill or an oil refinery, or a
task in a weapons guidance system.
2. Soft deadlines. A process with a soft deadline of n milliseconds should be
completed within n milliseconds of submission; however, the deadline may
be missed without catastrophic consequences. An example could be a task to
update the display in a virtual reality game as the user moves about.
Hard real-time OSs have scheduling algorithms that take into account the deadline
of each process and its estimated running time when deciding which process to run
9
There are many additional transparency levels that a distributed OS can achieve; see Chapter 17.
elm49810_ch02_019-044.indd 32
elm49810_ch02_019-044.indd 32 12/10/08 9:27:37 PM
12/10/08 9:27:37 PM

Confirming Pages
next. These OSs are mainly used in embedded systems that are found in devices such
as aircraft or process control systems, where a software process that makes a crucial
decision must be completed within its specified deadline. Soft real-time systems, on
the other hand, only need to give high priority to the tasks that have been designated
as real-time tasks. So most current OSs—for example, Windows 2000 or Solaris—
provide soft real-time support.
Unfortunately, most of the techniques that have evolved to give smooth average
response in most OSs are based on statistical decision making. These techniques will
not work in a hard real-time system. Such systems require unique algorithms for
scheduling time-critical events. As a result, we will not spend much time discussing
such systems. They are best treated separately.
2.5 ARCHITECTURAL APPROACHES TO BUILDING AN OS
2.5.1 Monolithic single-kernel OS approach
The first OSs were written as a single program. This approach to building the OS is
called the kernel or monolithic kernel approach, and was illustrated in Figure 1.3.
As the monolithic kernel OS included more functionality its size grew, in some cases
from a few thousand bytes to many millions of bytes. With limited and expensive
memory, the OS size overhead (the percentage of main memory occupied by the OS)
was considered too large. This bloated OS not only occupied memory, but like most
large programs, the OS was less efficient than a more minimal system, had more
bugs, and was difficult to maintain, either to add features or to fix bugs. This led OS
designers to develop OSs based on a more modular, layered design.
2.5.2 Layered OS approach
The modular approach that was developed was a layered architecture. The OS
would be divided into modules that were limited to a specific function such as pro-
cessor scheduling or memory management. The modules were grouped into layers
of increasing abstraction—each layer provides a more abstract view of the system
and relies on the services of the layers below it. The layered approach would hide
the peculiarities and details of handling hardware devices, and provide a common
abstract view to the rest of the OS. Thus, when new devices entered the market-
place, new device drivers could be added to the kernel without drastically affecting
the other OS modules, which provide memory management, processor schedul-
ing, and the file system interface. This is illustrated in a very rudimentary way in
Figure 2.4.
This approach can be extended to implement an OS with several layers. One
variation would allow modules at layer n to call only the modules in the next lower
layer n-1. Another variation would allow modules at layer n to call modules at any of
the lower layers (n-1, n-2, and so on).A further variation would allow level n modules
to interact with other level n modules, in addition to lower-level modules. Because
of the difficulty of separating complex OS functionality into multiple layers, usually
elm49810_ch02_019-044.indd 33
elm49810_ch02_019-044.indd 33 12/10/08 9:27:37 PM
12/10/08 9:27:37 PM

Confirming Pages
only two or three layers are used in practice. We examine more specific instances
of layered designs in later chapters. Most modern OSs are built on a layered archi-
tecture. However some OS programmers felt that the layered approach was not suf-
ficient, and that OS design should return to a minimum amount of code in the kernel
and the concept of microkernel.
2.5.3 Microkernel OS approach
The microkernel approach is illustrated in Figure 2.5. Here only basic functional-
ity, usually the interfaces to the various types of device drivers, is included in the
microkernel. Specifically, the only code in these modules is code that must run in
supervisor mode because it actually uses privileged resources such as protected
instructions or accesses memory not in the kernel space. The remainder of the OS
functions are still part of the resident OS, but they run in user mode rather than
protected mode. Code running in protected mode literally can do anything, so an
error in this code can do more damage than code running in user mode. So the
theory of the microkernel is that the benefits to this approach arise partly from the
fact that the amount of code that is running in supervisor mode is smaller, making
them more robust. It also makes them easier to inspect for flaws. Also, the extra
design effort required makes it more probable that the implementation will be cor-
rect. Finally, it is easier to port a small microkernel to a new platform than it is to
port a large, layered, but monolithic kernel. On the other hand, a microkernel must
make use of interrupts to make the necessary calls from the user mode portions
of the OS to the supervisor mode portions. These interrupts will often necessitate
context switches. Critics of the microkernel approach say that this makes a micro-
kernel OS run more slowly. (It should be noted that this issue is not resolved in the
OS community.)
Shell
(Command
Interpreter)
Utilities
User Programs
(browsers, games,
word processing)
Memory
Management
Processor
Scheduling
Device Drivers
Devices
(disks,
keyboards)
CPU Memory
File
System
API
Kernel
FIGURE 2.4
Layered model of
an Operating System.
elm49810_ch02_019-044.indd 34
elm49810_ch02_019-044.indd 34 12/10/08 9:27:37 PM
12/10/08 9:27:37 PM

Confirming Pages
2.6 SOME OS IMPLEMENTATION TECHNIQUES AND ISSUES
As we discussed in Sections 2.2 and 2.5, an OS is a complex software system with
many modules and components. As with any such system, there will be many data
structures and algorithms implemented within a typical OS. In this section, we dis-
cuss a few implementation techniques that are part of most or all OSs. These subjects
include the normal method used for handling interrupts, queues and data structure
used in many OS components, an object-oriented approach to OS implementation,
and the topic of Virtual Machines.
2.6.1 Interrupt handling using interrupt vectors
As we have already mentioned several times, an interrupt is a mechanism used by
an OS to signal to the system that some high-priority event has occurred that requires
immediate attention. Many interrupt events are associated with I/O. Some of these
typical interrupt events are signaling that a disk block read or write has been com-
pleted, signaling that a mouse button has been clicked, or signaling that a keyboard
button has been pressed. As we can see, most of these interrupts correspond to some
hardware action. The hardware associates with each interrupt event a particular inter-
rupt number. The interrupting controller typically places this interrupt number in an
interrupt register when the corresponding event occurs. Depending on the particular
type of interrupt event, the OS has to take certain actions. The question that comes up
is, How can the OS efficiently determine which particular interrupt event has occurred,
and how does it start up the appropriate process that services that interrupt?
The normal technique for interrupt handling uses a data structure called an inter-
rupt vector (see Figure 2.6). The vector has one entry for each interrupt number.
That entry contains the memory address of the interrupt service routine for that type
of interrupt. The interrupt number placed in the interrupt register is used as an index
into the interrupt vector. The interrupt vector entry is picked up by the hardware as
Shell
(Command)
Interpreter)
User
Mode
API
Kernel
Mode
Utilities
User Programs
(browsers, games,
word processing)
Memory
Management
Processor
Scheduling
Microkernel
File
System
Devices
(disks,
keyboards)
CPU Memory
FIGURE 2.5
Microkernel model
of an Operating
System.
elm49810_ch02_019-044.indd 35
elm49810_ch02_019-044.indd 35 12/10/08 9:27:37 PM
12/10/08 9:27:37 PM

Other documents randomly have
different content

tribulation. At least you might have seen the wean was dried when
she came back.”
“I'm sure and I don't know what you're talking about, m'em,” said
the maid, astounded.
“You got a letter the day the bairn took ill; what was it about?”
The girl burst into tears and covered her head with her apron.
“Oh, Miss Dyce, Miss Dyce!” she cried, “you're that particular, and
I'm ashamed to tell you. It was only just diversion.”
“Indeed, and you must tell me,” said her mistress, now
determined. “There's some mystery here that must be cleared, as
I'm a living woman. Show me that letter this instant!”
“I can't, Miss Dyce, I can't; I'm quite affronted. You don't ken who
it's from.”
“I ken better than yourself; it's from nobody but Lennox,” said
Miss Bell.
“My stars!” cried the maid, astonished. “Do you tell me that?
Amn't I the stupid one? I thought it was from Charles. Oh, m'em,
what will Charles Maclean of Oronsay think of me? He'll think I was
demented,” and turning to her servant's chest she threw it open and
produced the second sham epistle.
Miss Bell went in with it to Ailie in the parlor, and they read it
together. Ailie laughed till the tears came at the story it revealed.
“It's more creditable to her imagination than to my teaching in
grammar and spelling,” was her only criticism. “The—the little
rogue!”
“And is that the way you look at it?” asked Bell, disgusted. “A pack
of lies from end to end. She should be punished for it; at least she
should be warned that it was very wicked.”
“Stuff and nonsense,” said Miss Ailie. “I think she has been
punished enough already, if punishment was in it. Just fancy if the
Lord could make so much ado about a little thing like that! It's not a
pack of lies at all, Bell; it's literature, it's romance.”

“Well, romancing!” said Miss Bell. “What's romancing if you leave
out Walter Scott? I am glad she has a conviction of the sin of it
herself. If she had slipped away from us on Wednesday this letter
would have been upon her soul. It's vexing her now.”
“If that is so, it's time her mind was relieved,” said Ailie, and,
rising, sped to the garden with the letter in her hand. Her heart bled
to see the apprehension on Bud's face, and beside her Dan stroking
her hair and altogether bewildered.
“Bud,” cried Ailie, kissing her, “do you think you could invent a
lover for me who would write me letters half so interesting as this?
It's a lover like that I have all the time been waiting for: the ordinary
kind, by all my reading, must be very dull in their correspondence,
and the lives they lead deplorably humdrum—
“'Oh, Charlie is my darling, my darling, my darling;
Oh, Charlie is my darling, the young marineer.'
After this I'll encourage only sailors. Bud, dear, get me a nice,
clean sailor. But I stipulate that he must be more discriminating with
his capitals, and know that the verb must agree with its nominative,
and not be quite so much confused in his geography.”
“You're not angry with me, aunt?” said Bud, in a tone of great
relief, with the bloom coming back. “Was it very, very wicked?”
“Pooh!” said Ailie. “If that's wicked, where's our Mr. Shakespeare?
Oh, child! child! you are my own heart's treasure. I thought a girl
called Alison I used to know long ago was long since dead and done
with, and here she's to the fore yet, daft as ever, and her name is
Lennox Dyce.”
“No, it wasn't Lennox wrote that letter,” said Bud; “it was Winifred
Wallace, and oh, my! she's a pretty tough proposition. You're quite,
quite sure it wasn't fibbing.”
“No more than Cinderella's fibbing,” said her aunt, and flourished
the letter in the face of Dan, who she saw was going to enter some
dissent. “Behold, Dan Dyce, the artist b-r-r-rain! Calls sailor
sweethearts from the vasty deep, and they come obedient to her

bidding. Spise and perils, Dan, and the golden horn a trifle out of its
latitude, and the darling boy that's always being drove from home.
One thing you overlooked in the boy, Bud—the hectic flush. I'm sure
Kate would have liked a touch of the hectic flush in him.”
But Bud was still contrite, thinking of the servant. “She was so set
upon a letter from her Charles,” she explained, “and now she'll have
to know that I was joshing her. Perhaps I shouldn't say joshing,
Auntie Ailie—I s'pose it's slang.”
“It is,” said her aunt, “and most unlady-like; let us call it pulling
her le—let us call it—oh, the English language! I'll explain it all to
Kate, and that will be the end of it.”
“Kate'd be dre'ffle rattled to talk about love to a grown-up lady,”
said Bud, on thinking. “I'd best go in and explain it all myself.”
“Very well,” said Auntie Ailie; so Bud went into the house and
through the lobby to the kitchen.
“I've come to beg your pardon, Kate,” said she, hurriedly. “I'm
sorry I—I—pulled your leg about that letter you thought was from
Charles.”
“Toots! Ye needn't bother about my leg or the letter, either,” said
Kate, most cheerfully, with another letter open in her hand, and Mr.
Dyce's evening mail piled on the table before her; “letters are like
herring now, they're comin' in in shoals. I might have kent yon one
never came from Oronsay, for it hadn't the smell of peats. I have a
real one now that's new come in from Charles, and it's just a beauty!
He got his leg broken on the boats a month ago, and Dr. Macphee's
attending him. Oh, I'm that glad to think that Charles's leg is in the
hands of a kent face!”
“Why, that's funny,” said Bud. “And we were just going to write—
oh, you mean the other Charles?”
“I mean Charles Maclean,” said Kate, with some confusion. “I—I—
was only lettin' on about the other Charles; he was only a diversion.”
“But you sent him a letter?” cried Bud.

“Not me!” said Kate, composedly. “I kept it, and I sent it on to
Charles out in Oronsay when you were poorly; it did fine! He says
he's glad to hear about my education and doesn't think much of
gentlemen that dances, but that he's always glad to get the scrape
of a pen from me, because—because—well, just because he loves
me still the same, yours respectfully, Charles Maclean. And oh, my
stars, look at what a lot of crosses!”
Bud scrutinized them with amazement. “Well, he's a pansy!” said
she.

S
CHAPTER XV
UDDENLY all the town began to talk of the pride of Kate
MacNeill. She took to wearing all her best on week-days,
abandoned the kitchen window, and ruined an old-established
trade in pay-night sweeties that used to shower on her in
threepenny packets at the start of every autumn when the days
grew short. No longer blate young lads scraped with their feet
uneasily in the sawdust of P. A. Mac-Glashan's, swithering between
the genteel attractions of Turkish Delight and the eloquence of
conversation lozenges that saved a lot of thinking and made the
blatest equal with the boldest when it came to tender badinage
below the lamp at the back-door close with Dyce's maid. Talk about
the repartee of salons! wit moves deliberately there compared with
the swift giff-gaff that Kate and her lads were used to maintain with
sentiments doubly sweet and ready-made at threepence the quarter
pound. So fast the sweeties passed, like the thrust and riposte of
rapiers, that their final purpose was forgotten; they were sweeties
no longer to be eaten, but scented billets-doux, laconic of course,
but otherwise just as satisfactory as those that high-born maidens
get only one at a time and at long intervals when their papas are out
at business.
“Are you engaged?”
“Just keep spierin'.”
“Absence makes the heart grow fonder.”
“You are a gay deceiver.”
“My heart is yours.”
“How are your poor feet?”
By the hour could Kate sustain such sparkling flirtations, or at
least till a “Kiss me, dearest” turned up from the bottom of the poke,

and then she slapped his face for him. It is the only answer out in
Colonsay unless he's your intended.
But it stopped all at once. P. A. was beat to understand what
way his pay-night drawings fell, until he saw that all the lads were
taking the other side of the street. “That's her off, anyway!” said he
to Mrs. P. A., with a gloomy visage. “I wonder who's the lucky
man? It's maybe Peter—she'll no' get mony lozengers from him.”
And it was not only the decline in votive offerings that showed the
vital change: she was not at the Masons' ball, which shows how
wrong was the thought of P. A., for Peter was there with another
lady. Very cheery, too, exceedingly cheery, ah, desperately gay, but
quite beyond the comprehension of his partner, Jenny Shand, who
was unable to fathom why a spirit so merry in the hall should turn to
groans and bitterness when, feeling a faintish turn, she got him in
behind the draught-screen on the landing of the stair to sit the
“Flowers o' Edinburgh.” He was fidging fain to tell her plainly what
he thought of all her sex, but strove like a perfect gentleman against
the inclination, and only said, “Ha! ha! do you say so, noo?” and
“Weemen!” with a voice that made them all out nothing more nor
less than vipers. Poor Jenny Shand! bonny Jenny Shand! what a
shame she should be bothered with so ill-faured a fellow! When she
was picking bits of nothing off his coat lapel, as if he was her
married man, and then coming to herself with a pretty start and
begging pardon for her liberty, the diffy paid no heed; his mind was
down the town, and he was seeing himself yesterday morning at the
first delivery getting the window of Dyce's kitchen banged in his face
when he started to talk about soap, meaning to work the topic
round to hands and gloves. He had got the length of dirty hands,
and asked the size of hers, when bang! the window went, and the
Hielan' one in among her pots and pans.
It was not any wonder, for other lads as deliberate and gawky as
himself had bothered her all the week with the same demand.
Hands! hands! you would think, said she, they were all at the door
wi' a bunch of finger-rings bound to marry her right or wrong, even
if they had to put them on her nose. Of course she knew finely what

they were after—she knew that each blate wooer wanted a partner
for the ball, and could only clinch the compact with a pair of gloves;
but just at present she was not in trim for balls, and landsmen had
no interest for her since her heart was on the brine. Some of them
boldly guessed at seven-and-a-halfs without inquiry, and were
dumfoundered that she would not look at them; and one had
acquired a pair of roomy white cotton ones with elastic round the
top—a kind of glove that plays a solemn part at burials, having come
upon Miss Minto when her stock of festive kids was done. They
waylaid Kate coming with her basket from the mangle—no, thanky,
she was needing no assistance; or she would find them scratching at
the window after dark; or hear them whistling, whistling, whistling—
oh, so softly!—in the close. There are women rich and nobly born
who think that they are fortunate, and yet, poor dears! they never
heard the whistling in the close. Kate's case was terrible! By day, in
her walks abroad in her new merino, not standing so much as a
wink, or paying any heed to a “Hey, Kate, what's your hurry?” she
would blast them with a flashing eye. By night, hearing their signals,
she showed them what she thought of them by putting to the
shutters. “Dir-r-rt!” was what she called them, with her nose held
high and every “r” a rattle on the lug for them—this to Bud, who
could not understand the new distaste Kate had to the other sex.
“Just dirt below my feet! I think myself far, far above them.”
One evening Mr. Dyce came in from his office and quizzed her in
the lobby. “Kate,” said he, “I'm not complaining, but I wish you
would have mercy on my back door. There's not a night I have come
home of late but if I look up the close I find a lad or two trying to
bite his way into you through the door. Can you no' go out, like a
good lass, and talk at them in the Gaelic—it would serve them right!
If you don't, steps will have to be taken with a strong hand, as you
say yourself. What are they wanting? Can this—can this be love?”
She ran to the sanctuary of the kitchen, plumped in a chair, and
was swept away in a storm of laughter and tears that frightened
Bud, who waited there a return of her aunts from the Women's
Guild. “Why, Kate, what's the matter?” she asked.

“Your un—your un—un—uncle's blaming me for harboring all them
chaps about the door, and says it's l-l-love—oh, dear! I'm black
affronted.”
“You needn't go into hysterics about a little thing like that,” said
Bud. “Uncle Dan's tickled to death to see so many beaux you have,
wanting you to that ball; he said last night he had to walk between
so many of them waiting for you there in front, it was like
shassaying up the middle in the 'Haymakers'.”
“It's not hysterics, nor hersterics, either,” said the maid; “and oh, I
wish I was out of here and back in the isle of Colonsay!”
Yes, Colonsay became a great place then. America, where the
prospects for domestics used to be so fascinating, had lost its
glamour since Bud had told her the servants there were as
discontented as in Scotland, and now her native isle beat paradise.
She would talk by the hour, at a washing, of its charms, of which the
greatest seemed to be the absence of public lamps and the way you
heard the wind! Colonsay seemed to be a place where folk were
always happy, meeting in one another's houses, dancing, singing,
courting, marrying, getting money every now and then from sons or
wealthy cousins in Australia. Bud wondered if they never did any
work in Colonsay. Yes, yes, indeed! Kate could assure her, they
worked quite often out in Colonsay—in the winter-time.
But one thing greatly troubled her—she must write back at once
to the only Charles, who so marvellously had come to her through
Bud's unconscious offices, and she knew she could never sustain the
standard of hand-write, spelling, and information Bud had
established in her first epistle. Her position was lamentable. It was
all very well to be the haughty madam on the street, and show
herself a wise like, modest gyurl, but what was that without the
education? C. Maclean was a man of education—he got it on the
yats among the gentry, he had travelled all the world!
Kate's new airs, that caused such speculation in the town, were—
now let me tell you—all the result of a dash at education. She

wanted to be able to write a letter as good as Bud in a week or two,
and had engaged the child to tutor her.
Bud never found a more delicious game in all her life, and it
hurried her convalescence, for to play it properly she must be Aunt
Ailie, and Aunt Ailie was always so strong and well.
“Education,” said Bud, who had a marvellous memory, and was
now, you will notice, Ailie Dyce, sitting on a high chair, with the maid
on a stool before her—“education is not what a lot of sillies think it
is; it isn't knowing everything. Lots try for it that way, and if they
don't die young, just when they're going to win the bursary, they
grow up horrid bores that nobody asks to picnics. You can't know
everything, not if you sit up cramming till the cows come home; and
if you want to see a brainy person jump, ask him how his mother
raised her dough. Miss Katherine MacNeill, never—never—NEVER be
ashamed of not knowing a thing, but always be ashamed of not
wanting to know. That's Part One. Don't you think you should have
an exercise-book, child, and take it down?”
“Toots! what's my head for?” said the servant.
“Uncle Dan says education is knowing what you don't know, and
knowing where to find it out without the other people knowing; but
he says in most places you can get the name of having it fine and
good by talking loud and pushing all your goods in front of you in a
big enough barrow. And Auntie Bell—she says the fear of God is the
beginning of wisdom, and the rest of it is what she skipped at
Barbara Mushet's Seminary. But I tell you, child (said the echo of
Ailie Dyce), that education's just another name for love.”
“My stars! I never knew that before,” cried the servant. “I'm awful
glad about Charles!”
“It isn't that kind of love,” Bud hurriedly explained, “though it's
good enough, for that's too easy. You're only on the trail for
education when you love things so you've simply got to learn as
much as is good for your health about them. Everything's sweet—
oh, so sweet!—all the different countries, and the different people,
when you understand, and the woods, and the things in them, and

all the animals—'cepting maybe pud-docks, though it's likely God
made them, too, when He was kind of careless—and the stars, and
the things men did, and women—'specially those that's dead, poor
dears!—and all the books, 'cepting the stupid ones Aunt Ailie simply
can't stand, though she never lets on to the ladies who like that
kind.”
“My Lord! must you love them all?” asked the maid, astonished.
“Yes, you must, my Lord,” said Bud. “You'll never know the least
thing well in this world unless you love it. It's sometimes mighty
hard, I allow. I hated the multiplication table, but now I love it—at
least, I kind of love it up to seven times nine, and then it's almost
horrid, but not so horrid as it was before I knew that I would never
have got to this place from Chicago unless a lot of men had learned
the table up as far as twelve times twelve.”
“I'm not particular about the multiplication table,” said the maid,
“but I want to be truly refined, the same as you said in yon letter to
Charles. I know he'll be expecting it.”
“H-m-m-m-m!” said Bud, thoughtfully, “I s'pose I'll have to ask
Auntie Ailie about that, for I declare to goodness I don't know where
you get it, for it's not in any of the books I've seen. She says it's the
One Thing in a lady, and it grows inside you some way, like—like—
like your lungs, I guess. It's no use trying to stick it on outside with
lessons on the piano or the mandoline, and parlor talk about poetry,
and speaking mim as if you had a clothes-pin in your mouth, and
couldn't say the least wee thing funny without it was a bit you'd see
in Life and Work. Refinement, some folk think, is not laughing right
out.”
“My stars!” said Kate.
“And Auntie Bell says a lot think it's not knowing any Scotch
language and never taking cheese to tea.”
“I think,” said Kate, “we'll never mindrefining; it's an awful bother.”
“But every lady must be refined,” said Bud. “Ailie prosists in that.”
“I don't care,” said the maid; “I'm not particular about being very
much of a lady—I'll maybe never have the jewelry for it—but I would

like to be a sort of lady on the Sundays, when Charles is at home.
I'm not hurryin' you, my dear, but—but when do we start the
writin'?” and she yawned in a way that said little for the interest of
Professor Bud's opening lecture.
Whereupon Bud explained that in a systematic course of education
reading came first, and the best reading was Shakespeare, who was
truly ennobling to the human mind. She brought in Auntie Ailie's
Shakespeare and sat upon the fender, and plunged Kate at once into
some queer society at Elsinore. But, bless you, nothing came of it:
Kate fell asleep, and woke to find the fire cold and the child
entranced with Hamlet.
“Oh, dear! it's a slow job getting your education,” she said,
pitifully, “and all this time there's my dear Charles waiting for a
letter!”

I
CHAPTER XVI
CANNA be bothered with that Shakespeare,” Kate cried,
hopelessly, after many days of him; “the man's a mournin' thing!
Could he not give us something cheery, with 'Come, all ye boys!'
in it, the same as the trawlers sing in Colonsay? There was far
more fun last week in the penny Horner”.
So Bud dipped in the bottomless well of knowledge again and
scooped up Palgrave's Golden Treasury, and splashed her favorite
lyrics at the servant's feet. Kate could not stand The Golden Treasury
either; the songs were nearly all so lamentable they would make a
body greet. Bud assured her on the best authority that the sweetest
songs were those that told of saddest thought, but Kate said that
might be right enough for gentry who had no real troubles of their
own, but they weren't the thing at all for working folk. What working
folk required were songs with tunes to them, and choruses that you
could tramp time to with your feet. History, too, was as little to her
taste; it was all incredible—the country could never have kept up so
many kings and queens. But she liked geography, for the map
enabled her to keep an eye on Charles as he went from port to port,
where letters in her name, but still the work of Lennox, would be
waiting for him.
The scheme of education was maintained so long because the
town had come upon its melancholy days and Bud began to feel
depression, so that playing teacher was her only joy. The strangers
had gone south with the swallows; the steamer no longer called
each day to make the pavement noisy in the afternoon with the skliff
of city feet, so different from the customary tread of tackety boots;
the coachman's horn, departing, no longer sounded down the valley
like a brassy challenge from the wide, wide world. Peace came to
the burgh like a swoon, and all its days were pensive. Folk went
about their tasks reluctant, the very smoke of the chimneys loitered

lazily round the ridges where the starlings chattered, and a haze was
almost ever over the hills. When it rose, sometimes, Bud, from her
attic window, could see the road that wound through the distant
glen. The road!—the road!—ah, that began to have a meaning and a
kind of cry, and wishfully she looked at it and thought upon its other
end, where the life she had left and read about was loudly humming
and marvellous things were being done. Charles Maclean of Oronsay,
second mate, whom she loved unto destruction, now that he was
writing regularly, fairly daft himself to get such charming, curious
letters as he thought from Kate, had been adjusted by the doctor,
and was once again on the heaving main. It would be Cardiff or
Fleetwood, Hamburg, Santander, or Bilbao, whose very name is like
a story, and his tarry pen, infected by the child's example, induced to
emulation, always bravely sought to give some picture of the varied
world through which he wandered. Of noisy ports did he
communicate, crowded with ships; of streets and lofty warehouses,
and places where men sang, and sometimes of the playhouse,
where the villain was a bad one and the women were so braw.
“What is braw?” asked Bud.
“It's fine clothes,” said Kate; “but what's fine clothes if you are not
pure in heart and have a figure?” and she surveyed with satisfaction
her own plump arms.
But the child guessed at a wider meaning for the word as Charles
used it, and thought upon the beauteous, clever women of the plays
that she had seen herself in far Chicago, and since her vicarious
lover would have thought them braw and plainly interesting, she
longed to emulate them, at least to see them again. And oh! to see
the places that he wrote of and hear the thundering wheels and
jangling bells! And there was also Auntie Ailie's constant stimulus to
thoughts and aspirations that could meet no satisfaction in this little
town. Bell dwelt continually within the narrow walls of her immediate
duty, content, like many, thank the Lord! doing her daily turns as
best she could, dreaming of nothing nobler. Dan had ranged wider in
his time and knew the world a great deal better, and had seen so
much of it was illusion, its prizes “will-o'-the-wisp,” that now his wild

geese were come home. He could see the world in the looking-glass
in which he shaved, and there was much to be amused at. But Ailie's
geese were still flying far across the firmament, knowing no place of
rest. The child had bewitched her! it was often the distant view for
her now, the region unattainable; and though apparently she had
long ago surrendered to her circumstances, she now would
sometimes silently irk at her prisoning here, in sleep-town, where we
let things slide until to-morrow, while the wild birds of her inclination
flew round the habitable, wakeful world. Unwittingly—no, not
unwittingly always—she charged the child with curiosity
unsatisfiable, and secret discontent at little things and narrow, with
longings for spacious arenas and ecstatic crowded hours. To be
clever, to be brave and daring, to venture and make a glorious name
—how her face would glow and all her flesh would quiver picturing
lives she would have liked to live if only she had had the chance!
How many women are like that—silent by the hearth, seemingly
placid and content as they dam and mend and wait on the whim and
call of dullards!
Bell might be content and busy with small affairs, but she had a
quick, shrewd eye and saw the child's unrest. It brought her real
distress, for so had the roving spirit started in her brother William.
Sometimes she softly scolded Lennox, and even had contemplated
turning her into some other room from the attic that had the only
window in the house from which the high-road could be seen, but
Ailie told her that would be to make the road more interesting for
the child. “And I don't know,” she added, “that it should worry us if
she does indulge herself in dreams about the great big world and its
possibilities. I suppose she'll have to take the road some day.”
“Take the road!” cried Bell, almost weeping. “Are you daft, Ailie
Dyce? What need she take the road for? There's plenty to do here,
and I'm sure she'll never be better off anywhere else. A lot of
nonsense! I hope you are not putting notions in her head; we had
plenty of trouble with her father.”
“It would break my heart to lose her, I assure you,” said Aunt Ailie,
softly; “but—” and she ended with a sigh.

“I'm sure you're content enough yourself?” said Bell; “and you're
not by any means a diffy.”
“Indeed I am content,” admitted Ailie; “at least—at least I'm not
complaining. But there is a discontent that's almost holy, a roving
mood that's the salvation of the race. There were, you mind, the
Pilgrim Fathers—”
“I wish to the Lord they had bided at home!” cried Bell. “There's
never been happy homes in this Christian land since they started
emigration.” And at that Miss Ailie smiled and Dan began to chuckle.
“Does it not occur to you, Bell,” said he, “that but for the Pilgrim
Fathers there would never have been Bud?”
“I declare neither there would!” she said, smiling. “Perhaps it was
as well they went, poor things! And, of course, there must be many
an honest, decent body in America.”
“Quite a number!” said Ailie. “You would not expect this burgh to
hold them all, or even Scotland. America's glad to get the overflow.”
“Ah, you're trying to make me laugh, the pair of you, and forget
my argument,” said Bell; “but I'll not be carried away this time. I'm
feared for the bairn, and that's telling you. Oh, Ailie, mind what her
mother was—poor girl! poor, dear girl! play-acting for her living,
roving from place to place, with nothing you could call a home;
laughing and greeting and posturing before lights for the diversion of
the world—”
“We might do worse than give the world diversion,” said Ailie,
soberly.
“Yes, yes, but with a painted face and all a vain profession—that is
different, is it not? I love a jovial heart like Dan's, but to make the
body just a kind of fiddle! It's only in the body we can be ourselves
—it is our only home; think of furnishing it with shams, and lighting
every room that should be private, and leaving up the blinds that the
world may look in at a penny a head! How often have I thought of
William, weeping for a living, as he had to do sometimes, no doubt,
and wondered what was left for him to do to ease his grief when
Mary died. Oh, curb the child, Ailie! curb the dear wee lassie—it's

you it all depends on; she worships you; the making of her's in your
hands. Keep her humble. Keep her from thinking of worldly glories.
Teach her to number her days that she may apply her heart unto
wisdom. Her mind's too often out of here and wandering elsewhere
—it was so with William—it was once the same with you.”
Indeed, it was no wonder that Bud's mind should wander
elsewhere since the life about her had grown so suddenly dull. In
these days Wanton Wully often let his morning sleep too long
possess him, and hurrying through the deserted dawn with his
breeches scarcely on, would ring the bell in a hasty fury half an hour
behind the proper time. But a little lateness did not matter in a town
that really never woke. Men went to work in what we call a dover—
that is, half asleep; shopkeepers came blinking drowsily down and
took their shutters off and went back to breakfast, or, I sometimes
fear, to bed, and when the day was aired and decency demanded
that they should make some pretence at business they stood by the
hour at their shop doors looking at the sparrows, wagtails, and blue-
bonnets pecking in the street, or at the gulls that quarrelled in the
syver sand. Nothing doing. Two or three times a day a cart from the
country rumbled down the town breaking the Sabbath calm; and on
one memorable afternoon there came a dark Italian with an organ
who must have thought that this at last was Eldorado, so great was
his reward from a community sick of looking at one another. But
otherwise nothing doing, not a thing! As in the dark of the fabled
underland the men who are blind are kings, George Jordon, the silly
man, who never had a purpose, and carried about with him an
enviable eternal dream, seemed in that listless world the only
wideawake, for he at least kept moving, slouching somewhere, sure
there was work for him to do if only he could get at it. Bairns
dawdled to the schools, dogs slept in the track where once was
summer traffic, Kate, melancholy, billowed from the kitchen window,
and into the street quite shamelessly sang sad, old Gaelic songs
which Mr. Dyce would say would have been excellent if only they
were put to music, and her voice was like a lullaby.

One day Bud saw great bands of countless birds depart, passing
above the high-road, and standing in the withering garden heard as
it were without a breath of wind the dry rattle of dead leaves fall. It
frightened her. She came quickly in to the tea-table almost at her
tears.
“Oh, it's dre'ffle,” she said. “It's Sunday all the time, without good
clothes and the gigot of mutton for dinner. I declare I want to yell.”
“Dear me!” said Miss Bell, cheerfully, “I was just thinking things
were unusually lively for the time of year. There's something startling
every other day. Aggie Williams found her fine, new kitchen range
too big for the accommodation, and she has covered it with cretonne
and made it into a whatnot for her parlor. Then there's the cantata; I
hear the U. P. choir is going to start to practise it whenever Duncan
Gill next door to the hall is gone—he's near his end, poor body!
they're waiting on, but he says he could never die a Christian death
if he had to listen to them at their operatics through the wall.”
“It's not a bit like this in Chicago,” said the child, and her uncle
chuckled.
“I dare say not,” said he. “What a pity for Chicago! Are you
wearying for Chicago, lassie?”
“No,” said Bud, deliberating. “It was pretty smelly, but my! I wish
to goodness folk here had a little git-up-and-go to them!”
“Indeed, I dare say it's not a bit like Chicago,” admitted Auntie
Bell. “It pleases myself that it's just like Bonnie Scotland.”
“It's not a bit like Scotland, either,” said Bud. “I calc'lated Scotland
'd be like a story-book all the time, chock-full of men-at-arms and
Covenanters, and things father used to talk about, Sundays, when
he was kind of mopish and wanted to make me Scotch. I've
searched the woods for Covenanters and can't find one; they must
have taken to the tall timber and I haven't seen any men-at-arms
since I landed, 'cepting the empty ones up in the castle lobby.”
“What did you think Scotland would be like, dear?” asked Ailie.
“Between me and Winifred Wallace, we figured it would be a great
place for chivalry and constant trouble among the crowned heads. I

expected there'd be a lot of 'battles long ago,' same as in the
'Highland Reaper' in the sweet, sweet G. T.”
“What's G. T.?” asked Auntie Bell; and Bud laughed slyly and
looked at her smiling Auntie Ailie, and said: “We know, Auntie Ailie,
don't we? It's GRAND! And if you want to know, Auntie Bell, it's just
Mr. Lovely Palgrave's Golden Treasury. That's a book, my Lord! I
expected there'd be battles every day—”
“What a blood-thirsty child!” said Miss Ailie.
“I don't mean truly, truly battles,” Bud hurried to explain, “but the
kind that's the same as a sound of revelry off—no blood, but just a
lot of bang. But I s'pose battles are gone out, like iron suits. Then I
thought there'd be almost nothing but cataracts and ravines and—
and—mountain passes, and here and there a right smart Alick in
short trunks and a feather in his hat winding a hunting-horn. I used
to think, when I was a little, wee, silly whitterick, that you wound a
horn every Saturday night with a key just like a clock; but I've
known for years and years it's just blowing. The way father said, and
from the things I read, I calc'lated all the folk in Scotland'd hate one
another like poison, and start a clan, and go out chasing all the
other clans with direful slogans and bagpipes skirling wildly in the
genial breeze. And the place would be crowded with lovelorn
maidens—that kind with the starched millstones round their necks
like Queen Mary always wore. My, it must have been rough on dear
old Mary when she fell asleep in church! But it's not a bit like that;
it's only like Scotland when I'm in bed, and the wind is loud, and I
hear the geese. Then I think of the trees all standing out in the dark
and wet, and the hills, too, the way they've done for years and
years, and the big, lonely places with nobody in them, not a light
even; and I get the croodles and the creeps, for that's Scotland, full
of bogies. I think Scotland's stone-dead.”
“It's no more dead than you are yourself,” said Miss Bell,
determined ever to uphold her native land. “The cleverest people in
the world come from Scotland.”

“So father used to say; but Jim, he said he guessed the cleverer
they were the quicker they came. I'm not a bit surprised they make
a dash from home when they feel so dead and mopish and think of
things and see that road.”
“Road?” said Uncle Dan. “What road?”
“My road,” said the child. “The one I see from my window—oh,
how it rises and rises and winds and winds, and it just shrieks on
you to come right along and try.”
“Try what?” asked her uncle, curiously.
“I dunno,” said Bud, thinking hard; “Auntie Ailie knows, and I
'spect Auntie Bell knows, too. I can't tell what it is, but I fairly tickle
to take a walk along. Other times I fee I'd be mighty afraid to go,
but Auntie Ailie says you should always do the things you're afraid to
do, for they're most always the only things worth doing.”
Mr. Dyce, scratching the ear of Footles, who begged at the side of
his chair, looked over the rims of his glasses and scrutinized the
child.
“All roads,” said he, “as you'll find a little later, come to the same
dead end, and most of us, though we think we're picking our way,
are all the time at the mercy of the School-master, like Geordie
Jordon. The only thing that's plain in the present issue is that we're
not brisk enough here for Young America. What do you think we
should do to make things lively?”
“Hustle,” said Bud. “Why, nobody here moves faster 'n a funeral,
and they ought to gallop if they want to keep up with the band.”
“I'm not in a hurry myself,” said her uncle, smiling. “Maybe that's
because I think I'm all the band there is myself. But if you want to
introduce the Chicago system you should start with Mrs. Wright's
Italian warehouse down the street—the poor body's losing money
trying to run her shop on philanthropic principles.”
Bud thought hard a while. “Phil—phil—What's a philanthropic
principle?” she asked.

“It's a principle on which you don't expect much interest except in
another world,” said her uncle. “The widow's what they call a Pilgrim
hereabouts; if the meek were to inherit the earth in a literal sense,
she would long ago have owned the whole county.”
“A truly Christian woman!” said Miss Bell.
“I'm not denying it,” said Mr. Dyce; “but even a Christian woman
should think sometimes of the claims of her creditors, and between
ourselves it takes me all my time to keep the wholesale merchants
from hauling her to court.”
“How do you manage it?” asked Ailie, with a twinkle in her eyes;
but Dan made no reply—he coughed and cleaned his spectacles.

T
CHAPTER XVII
HERE was joy a few days later in the Dyces' kitchen when
Peter the postman, with a snort that showed the bitterness of
his feelings, passed through the window a parcel for Kate that
on the face of it had come from foreign parts. “I don't ken
who it's from, and ye're no' to think I'm askin',” said he; “but the
stamps alone for that thing must have cost a bonny penny.”
“Did they, indeed!” said Kate, with a toss of her head. “Ye'll be
glad to ken he can well afford it!” and she sniffed at the parcel
redolent of perfumes strange and strong.
“Ye needna snap the nose off me,” said the postman; “I only made
the remark. What—what does the fellow, do?”
“He's a traveller for railway tunnels,” retorted the maid of
Colonsay, and shut the window with a bang, to tear open the parcel
in a frenzy of expectation and find a bottle of Genuine Riga Balsam—
wonderful cure for sailors' wounds!—another of Florida Water, and a
silver locket, with a note from Charles saying the poem she had sent
was truly grand, and wishing her many happy returns of the day.
Like many of Charles's letters now, its meaning was, in parts,
beyond her, until she could learn from Bud the nature of the one to
which it was an answer—for Bud was so far enraptured with the
wandering sailor that she sometimes sent him letters which the
servant never saw. That day the breakfast service smelled of Florida
Water, for Kate had drenched herself with the perfume, and Miss Bell
was sure she had washed the dishes again with scented soap, as
was the habit of the girl when first she came from Colonsay and
thought that nothing but Brown Windsor would do justice to
Grandma Buntain's tea-set used on Sundays. But Bud could see the
signs of Shipping Intelligence, and as soon as she could she
hastened to the kitchen, for it was Saturday, and on Saturdays there
were no lessons in the Dyce Academy. Oh, how she and Kate

fondled the bottles lovingly, and sniffed passionately at their
contents, and took turn about of the locket! The maid had but one
regret, that she had no immediate use for Riga Balsam; but Bud was
more devoted than that—she gently pricked the palm of her hand
with a pin and applied the Genuine. “Oh, how he must love me—us,
I mean!” she exclaimed, and eagerly devoured his letter.
“What did you say to him in the last?” asked Kate. “He's talking
there about a poetry, and happy returns of the day.”
Bud confessed she had made a poem for him from his beloved
Kate, and had reckoned on fetching a gift of candy by telling him her
birthday was on Monday. “It really I'd just as lief have the balsam,”
said she; “it's perfectly lovely; how it nips!”
“It's not my birthday at all,” said Kate. “My birthday's always on
the second Sunday in September. I was born about the same time as
Lady Anne—either a fortnight before or a fortnight after; I forget
mysel' completely which it was, and I dare say so does she.”
“No, but Monday's my birthday, right enough,” said Bud, “and
seeing that we're sort of loving him in company, I s'posed it would
be all the same.”
“So it is; I'm not complainin',” said the maid. “And now we'll have
to send him something back. What would you recommend?”
They considered many gifts appropriate for a sailor—sou'westers,
Bible-markers, woollen comforters, and paper-knives, scarf-pins,
gloves, and ties. Bud was sure that nothing would delight him like a
book about a desert island, but Kate said no, a pipe was just the
very ticket—a wooden pipe with silver mountings; the very one to
suit was in the window of Mrs. Wright's Italian warehouse.
“What's an Italian warehouse?” asked the child. “You have me
there,” said Kate, “unless, maybe, her husband was Italian before he
went and died on her. 'Italian Warehouse' is the only thing that's on
her sign. She sells a thing for almost any price you like to offer,
because the Bible says it's not the thing at all to argy-bargy.”
“I know,” said Bud; “it's what we call running a business on—on—
on philanthropic principles. I'd love to see a body do it. I'll run out

and buy the pipe from Mrs. Wright, Kate.”
She departed on her errand down the town, at the other side of
the church; and the hours of the forenoon passed, and dinner-time
was almost come, and still there was no sign of her returning. Kate
would have lost her patience and gone to seek for her, but found so
much to interest her at the window that she quite forgot her
messenger. Something out of the ordinary was happening on the
other side of the church. Wanton Wully knew what it was, but of
course he was not telling, for he was out as public crier, rousing the
town with his hand-bell, and shouting “Notice!” with an air that
promised some tremendous tidings; but beyond mysterious words
like “bed-rock prices,” which he mumbled from a paper in his hand,
there was nothing to show this proclamation differed from the
common ones regarding herring at the quay or a sale of delft down-
by at John Turner's corner. “What are ye crying?” they asked him,
but being a man with the belief that he had a voice as clear as a
concert singer he would not condescend to tell them. Only when
some one looked across his shoulder and read the paper for himself
was it found that a sale described as “Revolutionary” was taking
place at the Italian warehouse. Half the town at once went to see
what the decent body was up to. Kate saw them hurrying down, and
when they came back they were laughing. “What's the ploy?” she
asked a passer-by.
“A sale at the Pilgrim weedow's,” she was told. “She's put past her
Spurgeon's Sermons and got a book aboot business, and she's
learnin' the way to keep an Italian warehouse in Scotch.”
Kate would have been down the town at once to see this marvel
for herself, but her pot was on the boil, and here was the mistress
coming down the stair crying, “Lennox, Lennox!” The maid's heart
sank. She had forgotten Lennox, and how could she explain her
absence to a lady so particular? But for the moment she was spared
the explanation, for the bark of Footles filled the street and Mr. Dyce
came into the lobby laughing.
“You're very joco!” said his sister, helping him off with his coat.
“What are you laughing at?”

“The drollest thing imaginable,” said he. “I have just left Captain
Consequence in a terrible rage about a letter that a boy has brought
to him from Mrs. Wright. He's one of the folk who brag of paying as
they go but never make a start. It seems he's as much in debt to her
as to most of the other merchants in the place, but wasn't losing any
sleep about it, for she's such a softy. This letter has given him a
start. He showed it to me, with the notion that it was a libel or a
threat that might be actionable, but I assured him I couldn't have
written one more to the point myself. It said that unless he paid at
once something would be apt to happen that would create him the
utmost astonishment.”
“Mercy on us! That's not very like the widow; she must be getting
desperate.”
“It was the wording of the thing abused me,” said Mr. Dyce,
walking into the parlor still chuckling—“'something will be apt to
happen that will create you the utmost astonishment'—it suggests
such awful possibilities. And it's going to serve its purpose, too, for
the Captain's off to pay her, sure it means a scandal.” Kate took the
chance to rush round the kirk in search of her messenger. “This way
for the big bargains!” cried some lads coming back from the Italian
warehouse, or, “Hey! ye've missed a step”—which shows how funny
we can be in the smallest burgh towns—but Kate said nothing only
“trash!” to herself in indignation, and tried by holding in her breath
to keep from getting red.
The shop of the Pilgrim widow suffered from its signboard, that
was “far too big for its job, like the sweep that stuck in my granny's
chimney,” as Mr. Dyce said. Once the sign had been P. A.'s, but P.
A's good lady tired of hearing her husband nicknamed the Italian,
and it went back to the painter, who partly paid with it a debt to the
Pilgrim widow, who long since rued her acquisition. She felt in her
soul it was a worldly vanity—that a signboard less obtrusive on the
public eye would more befit herself and her two meek little windows,
where fly-papers, fancy goods, sweetmeats, cigarettes, country
eggs, and cordial invitations to the Pilgrims' Mission Bethel every
Friday (D. V.), eight o'clock, kept one another incongruous and dusty

company. A decent, pious widow, but ah! so wanting any saving
sense of guile. The Pilgrim Mission was the thing she really lived for,
and her shop was the cross she bore. But to-day it was scarcely
recognizable: the windows had been swept of their stale contents',
and one was filled with piles of rosy apples, the other with nuts that
poured in a tempting cataract from a cask upset with an air of
reckless prodigality. A large, hand-lettered bill was in each window;
one said:
“HALLOWE'EN! ARISE AND SHINE!” and the other:
“DO IT NOW!”
what was to be done being left to the imagination. All forenoon
there had been a steady flow of customers, who came out of the
shop with more than nuts or apples, greatly amazed at the change
in the Pilgrim widow, who was cracking up her goods like any
common sinner. Behind the railed and curtained box, in which she
was supposed to keep her books and pray for the whole community,
there seemed to be some secret stimulating influence, for when bad
payers tried to-day to get a thing on credit, and she was on the
point of yielding, she would dart into the box and out again as hard
as steel, insisting that at every Revolutionary Sale the terms were
cash. She was giving bargains, but at her own price, never at her
customers', as it used to be. The Health Saline—extract of the finest
fruit, Cooling, Refreshing, Invigorating, Tonic (though indeed it
looked like an old friend from Rochelle with a dash of sugar and
tartaric)—was down a ha'penny, to less than what it cost, according
to another hand-done bill upon the counter. When they asked her
how she could afford to sell the stuff below its cost, she seemed
ashamed and startled, till she had a moment in behind the curtains,
and then she told them it was all because of the large turn-over; she
could not afford to sell the saline under cost if she did not sell it in
tremendous quantities.
Did they want Ward's Matchless Polishing Paste?—alas! (after a
dash behind the curtains) she was completely out of it. Of late it had

been in such great demand that she got tired of ordering it every
other week wholesale. Yes, she was out of Ward's, but (again the
curtained box) what about this wonderful line in calf-foot jelly, highly
praised by the—by the connoisseurs? What were connoisseurs? A
connoisseur (again on reference behind the curtains) was one of
those wealthy men who could swallow anything.
“I'll tell ye what it is,” said the tailor, “I see't at last! She's got a
book in there; I've seen't before—The Way to Conduct a Retail
Business—and when she runs behind, it's to see what she should say
to the customers. That's where she got the notions for her window
and the 'Do it Now!'”
But he was wrong—completely wrong, for when Kate came into
the shop with “Have you seen Miss Lennox, Mrs. Wright? I sent her
here a message hours ago,” Lennox herself came from the curtained
box saying, “Hello, Kate; saw you first! What can we do for you to
day?”
“My stars! you'll catch it!” said the maid. “They're waiting yonder
on you for your dinner.”
“I was just heading for home,” said Bud, making for the door.
“My child! my child! my angel child!” cried the Pilgrim widow,
going to kiss her, but Bud drew back.
“Not to-day, please; I'm miles too big for kissing to-day,” said she,
and marched solemnly out of the Italian warehouse.
“What in the world were you doing away so long?” asked Kate.
“Were you carrying on at anything?”
“I was paying for Charles's pipe,” said the child, returning the
money she had got for its purchase. “That's the sweetest lady, Mrs.
Wright, but my! ain't she Baby Mine when it settles down to
business? When I wanted to buy the pipe, she was so tickled she
wanted me to have it for nothing, seeing I was Mr. Dyce's niece. She
said Uncle Dan was a man of God, who saved her more than once
from bankruptcy, and it was a pretty old pipe anyway, that had been
in the window since the time she got changed and dropped
brocaded dolmans. You'd think it made her ache to have folk come

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Operating Systems A Spiral Approach 1st Edition Ramez Elmasri

More Related Content

Similar to Operating Systems A Spiral Approach 1st Edition Ramez Elmasri (20)

More from shchqashtu (6)

Recently uploaded (20)

Operating Systems A Spiral Approach 1st Edition Ramez Elmasri