In a previous post, I introduced the concept of Operating Systems (OSs) while discussing the differences between System Software and Application Software. If you're unfamiliar with these topics or if you're new to the study of technology, I strongly encourage you to read about the DifferenceBetween Application Software and System Software before moving forward. As you read on, you will learn about the software mechanisms that form an Operating System and how each mechanism plays a role in the bigger picture. From this, you may even learn a bit about bettering the world. After all,
“Alone we can do so
little; together we can do so much” -- Helen Keller
Operating Systems are essentially a
modular set of System Software that works together as part of a
'system' to help users perform certain 'operations'. Simple, no?
Despite the simplicity of our definition, tasks performed by an OS
are anything but simple. In this post, however, I spare my readers
the complex details and offer an easy-to-follow breakdown of the
typical General Purpose OS. I hope the lessons that follow will help
bridge the gap between the world's tech-ninjas and its
not-so-tech-savvy.
Like many other module-based concepts from
science and engineering, OS modules form a hierarchical structure
whose lower layers act as a support for the upper layers. We'll
begin our discussion with the OS's lowest layer and then work our way
up.
At the Operating System's core, we find
a software layer known as the Kernel. OS Kernels are small, but very
complex, pieces of software. They act as the system's main hardware
interface; requiring that all hardware requests be addressed to the
Kernel. This layer of abstraction is valuable for practical and
integrity-related reasons. To start, computer hardware is very
fragile. Direct access by poorly crafted software can easily lead to
damaged circuits. However, if all direct access is handled by a
well-designed and trusted Kernel, software packages can now obtain
hardware resources with limited risk. Kernels offer hardware
resources as services to other software on the system. These
services are accessed via a common signaling technique known as
System Calls.
Not only is hardware access dangerous,
it's often considered difficult and tedious. With modern Application
and System Software development, programmers write code in
'human-readable' languages that are later transformed into
'machine-readable' languages. However, this is not the case for
Kernel programming. Since Kernels communicate directly with
hardware, the languages used in their creation (often known as
assembly languages) are closely coupled with the hardware they
interact with. Non-Kernel software, on the other hand, is programmed
using a more flexible language that is hardware independent. In
other words, assembly requires its developers to have a detailed
understanding of the hardware being accessed and to take
responsibility for manual management of system resources (details
that other languages abstract from their developers). Using
available System Calls, software developers are given the luxury to
use 'high-level' languages rather than relying on system-specific
assembly languages.
As mentioned above, Kernels also
address integrity concerns. Since software must consult the Kernel
before performing tasks, Kernel-owned policies act as a central
enforcer of user and application privileges. These policies protect
the system from certain threats and enhance the way resources are
shared within the system. Threats come in many forms, but can
seperated between two categories: accidental threats and malicious
threats. May policies exist to protect users from themselves and
from external forces. For instance, the Kernel is responsible for
restricting a user's access to the files and folders he/she owns.
This policy can prevent a harmless user from accidentally deleting
important system files. Likewise, the same policy restricts
malicious users from accessing other users' private information.
Another example of Kernel policy is time-sharing. Since computers
can only run one process at a time, time-sharing policies were set to
allow the OS to 'Context Switch' between running processes.
Processes are software instructions that are queued for execution by
the OS. Without time sharing, users could only run one application
at a time (e.g. they could not download a file while typing in their
word processor).
In the same way that cars can be driven
by someone that doesn't understand the engine, applications can be
run by users that are ignorant of the OS. This is made possible
through the use of abstract software layers; as seen in our
discussion of the Kernel. The further we abstract software from the
hardware, the more flexible it becomes. Throughout OS design, you
will find more and more abstractions that further divorce a user from
what's 'under the hood'. Application Software is a well-known
abstraction that builds and isolates a set of actions that help users
complete tasks. But how exactly does your run-of-the-mill Web
Browser or Word Processor use Kernel services? Let's dig a little
deeper to find out.
It is possible (in most OSs) to use
direct system calls for Kernel access. However, though the Kernel
has simplified hardware access, its services are still low-level and
are somewhat difficult to use. This is especialy true when
developing very large and complex software packages. To facilitate
this difficulty, Operating Systems include a set of commonly used
software routines known as Shared System Libraries. These routines
expand programming language(s) (usually C or C++) by invoking complex
combinations of Kernel-level commands through single lines of code.
This abstraction layer highly simplifies the way developers implement
the Operating System's remaining System Software.
Unfortunately, with each additional
layer of abstraction, we are forced to sacrifice some level of
performance.
In many cases, you'll find that the advantages of
abstraction outweigh the losses. However, the weight of this
decision depends on the software's intended purpose. For example, if
you were developing a top-of-the-line computer game, performance is
very important and abstraction should be limited. On the other hand,
if your goal is to design and create server management tools, you're
likely to use a very flexible and highly abstracted scripting
language (e.g. languages like bash, perl, or python).
Now that the OS has a powerful set of
system libraries, we can investigate the System Software that
supports users and their applications. Operating Systems come with
software packages that run as Background Processes. Such processes
are often referred to as daemons or daemon processes. Daemon
services can fill many different roles, buth their primary objective
is offer services that enhance Application Software capabilities.
Network Services, for instance, set up and manage network and
Internet configurations. Other examples include: Window Systems,
which supply GUI capabilities; Print Services, which enable access to
local and network printers; and System Loggers, which maintains a
collection of system activity and error reports.
The last OS concept I'll cover here is
the shell. Loosely defined, a shell is the user's interface to the
system. The combination of a shell and certain system utilities
forms what we like to call an Operating Environment. Today's most
common type of shell is the Desktop Shell used on PCs. However, in
this post we're going discuss an older, more stable, type of shell
that acts as the foundation of modern computing systems; a Command
Shell. However, if you're interested in learning more about Desktop
Shells, I've written a previous post, Window Managers and Systems VsDesktop Shells and Environments, which goes into great detail about
the subject.
In a cold and lonely server room, some
IT administrator is sitting at a strange, text-only, user interface.
That's right; she's using the system without any graphics! During
the time when computer technology first began to blossom, this was
the only interface users and administrators had to the computer.
Because of its stability and limited resource requirements, many
systems administrators still prefer to use this approach today. A
text-only shell is known more commonly as a Command Shell and is made
of a Command-Line Interface (CLI) and a set of daemon utilities. The
CLI job is to interpret commands that users have typed into the
terminal. Command Shells tend to come with several 'built-in'
commands and operators that allow users to: navigate the file system,
print file and folder contents to the screen, redirect input/output
of streams to/from files, and manage running processes. CLIs also
support Environment Variables which can affect the way shells locate
executable files and cane change the default behavior of certain
software.
Congratulations! You're now one step
closer to understanding exactly how your computer works. Keep in
mind, however, that this has been a basic introduction to OS
concepts. Each of the modules mentioned in this post can be broken
down even further and, not surprising, grow more complex the deeper
you go. For now, let's pat ourselves on the back and review what
we've learned.
In summary, an OS is made up of System
Software that acts as building blocks for other software through the
use of abstraction. Abstraction simplifies the way we build
particular elements of a system and drives the system through a chain
of common interfaces. Depending on our intended purpose, we may find
that further abstraction will inhibit our design. In other cases, we
may not be limited by system performance and can therefore enjoy the
luxuries of a highly abstracted system. We learned that the Kernel
drives our hardware and manages system policies while the Shared
System Libraries simplify the way System Calls give access to Kernel
services. Daemon services and utilities run in the background and
support the system by managing tasks on behalf of user applications.
Lastly, a shell supplies an interface to the user whereby they can
access and run executable binaries from the Operating System. There
are several types of shells, including the Command Shell. This type
allows its users to invoke command by typing them into the CLI. I
hope you've learned a lot from this post and I hope to bring you more
knowledge in the future. Till then, bye bye!