Overview of Operating System Concepts

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!

Window Managers and Systems Vs Desktop Shells and Environments

This post assumes minimal understanding of computer software. Today, we'll focus on a widely used, but rarely understood, subset of System Software. If you'd like to learn more about System and Application Software or Operating Systems before moving forward, try reading my earlier post: Difference Between Application Software and System Software. By the time you've finished reading this post, I hope you have a clear image of the subject matter. After all,

“Where there is no vision, there is no hope” -- George Washington Carver

Among my friends, colleagues, classmates, and random Internet-acquaintances; I receive many questions regarding the difference between Window Managers, Window Systems, Desktop Shells, and Desktop Environments. Making this distinction seems especially difficult for those previously assimilated with Microsoft Windows. That isn't to say Windows users are unintelligent; it's merely a testament to Microsoft's lack of transparency. Unfortunately, this limited exposure leaves many new and potential GNULinux users confused, agitated, and ultimately intimidated by their first experience. Fear not fellow warriors! Whether you're a tech-ninja or a not-so-tech-savvy, this post explores the role each concept plays in delivering a Graphical User Interface (GUI).

Let's begin with the definition of a GUI. Assuming you read my previous post, you know that interfaces are mechanisms that allow the exchange of resources between two entities. In computing, Graphical User Interfaces are a subclass of interfaces that enable users to graphically visualize and control software activity. When someone talks about an application's GUI, they refer to its look, feel, and interactive capabilities. Likewise, an Operating System's GUI defines the overall graphical experience of the system platform. OS GUIs establish a graphical framework that applications work within to enhance user experience. Not too surprisingly, this post's four concepts of focus are actually the building blocks of an OS GUI.

If you're reading this post hoping to learn 'the Windows way', the information will be relevant, but not comprehensive. In Unix-like OSs (those modeled after the Unix OS; e.g. GNULinux, Mac OS, Solaris, and BSD), there's a clear distinction between the Window Manager, Window System, Desktop Shell, and Desktop Environment. The Windows family of Operating Systems, however, has a less specific definition for each component. I suspect these blurred definitions originate from the design principles used during development. Microsoft's goal was to design a self-contained OS that supplies Application Software with all the essential goodies required for a satisfying user experience. Contrastingly, Unix-like paradigms encourage the use of stable, modular design principles. This means that system components can, with relative ease, be replaced by other components that serve similar functions. Let's start investigating the roles of each OS GUI module, shall we?

Each GUI module works as part of a hierarchy to form what some call the 'complete desktop experience'. However, this term refers to feature-rich Operating Environments and not to minimal GUI requirements. In fact, a GUI can exist by having only one of the four modules: the Window System. Since it is the lowest layer of the hierarchy, let's begin with it. Window Systems are the most basic interface for graphical output and user input. In other words, the Window System is responsible for drawing graphics to the screen and for handling keyboard and mouse activity. Practically all Unix-like OSs use the X Window System (also called X Server, X11, or X.org) by default. The Window System is mostly inflexible and therefore is rarely used by itself. For example, X Server is very limited in the way graphical applications utilize its resources. By itself, X can only launch applications during initialization and, if a user wishes to launch new graphical applications, they must shutdown and reinitialize the Window Manager. Another limitation of running the Window System as a stand-alone GUI is that application windows are confined to static locations, sizes, appearances, and stacking indices (whether windows are on top of each other).

Next, we have the Window Manager: System Software responsible for handling application window state information. By state information, I mean data regarding a window's location, size, decorations, context menus, stacking index, etc. To clarify, Window Systems handle screen output and user input while Window Managers handle the logistics of application windows. When the two work together, users are able to change window aspects without a great deal of manual effort. Window Managers aren't necessary, but the advantages they afford are certainly a beautiful thing!

At this point, we have a GUI that launches a pre-defined set of applications when the Window System initializes. Also, thanks to our Window Manger, application windows now have several convenient and decorative features. Our GUI is, however, still very inflexible compared to modern expectations. For example, if you hadn't included a word processor in the Window System's set of startup applications, you will need to shutdown your GUI, reconfigure it within a text-only environment, and reinitialize it. Arguably the most desired feature we're lacking is the ability to launch applications by clicking desktop icons. To obtain these and other elastic capabilities, we'll move on to the concept of a Desktop Shell.

In computing, a shell is the place where users call home. Desktop Shells are a type of shell in which users are presented with a familiar graphical representation of their user profile: the 'desktop'. A Desktop Shell defines things like: task menus and panels, desktop icons and appearances, and desktop backgrounds. The key distinguishing features of a Desktop Shell are the convenient utilities and widgets not included by the Window Manager. Widget is a generic term used in computing to describe any sort of graphical element (e.g. buttons, menus, icons, etc). Desktop Shells are sometimes distributed as a monolithic software package, but are typically a collection of smaller applications. Desktop Shells can include several utilities, but the most common are: Terminal Emulators, File Managers, and Application Launchers. Let's take a quick detour and describe each of these.

I've avoided the topic till now (as some users find it intimidating), but a GUI isn't the only method for accessing system resources; there also exists a CLI (Command Line Interface). If you're already familiar CLIs, then kudos! If not, don't be ashamed. Long before computer graphics were 'necessary', users achieved computational goals by typing commands into a text-only prompt. Many OSs default to a CLI and, 'behind the scenes', initialize a GUI for the user. When the GUI initializes, the CLI becomes hidden and inaccessible (this isn't completely true, but we'll avoid the details). As we learned before, the Window System has no built-in features for launching additional applications and, now that our CLI is hidden, we are unable to launch applications via textual commands. To overcome these limitations, early developers created a Terminal Emulator to give users CLI access inside a GUI window. From this terminal, a user can run any command that he/she could have in a pure CLI. Assuming the user launches a GUI application via the Terminal Emulator, that application is inherited by the Window Manager. Thanks to some clever engineers, some semblance of flexibility can exist in our GUI.

In the X Window System, when the last pre-defined application is closed, the entire GUI shuts down. In 'the old days', it was common to set a Terminal Emulator as the last application, but doing this still forces us to use a CLI. File Managers were designed as a graphical alternative to the Terminal Emulator, allowing users to browse their digital File System. File Systems are mechanism used for the logical ordering of data on a block device (e.g. a hard drive). File Managers, sometimes called File Browsers, appear as window(s) containing icons for each file/directory within the current directory. By itself, however, the File Manager can only browse. In order to use icons to launch applications, we need a little help from the next Desktop Shell application.

As implied above, Application Launchers are used to give certain widgets a 'click to launch' capability. What this means, is that applications may invoke the Application Launcher if a user 'clicks' certain widgets. The primary function of an Application Launcher is to find and launch an application's executable file. A launcher has no visual form of its own, but it does, however, act on behalf of many different desktop and application widgets. Application Launchers are also responsible for associating different file types with specific applications. This feature is especially desired as it gives us the ability to open applications by double-clicking our data file instead of the application icons!

Now that we have a Desktop Shell, we should have a very flexible and customizable workspace. Given that we've selected a decent Window Manager and Desktop Shell, it's likely that our desktop looks pretty sweet. At this point, we should have things like panels and task bars, desktop icons, adorable animated widgets, a flashy background, decorated context menus, and sleek window designs. So what's missing from our Desktop Shell that is present in most PC Desktop Environments? Let's check it out!

If you recall, the transition from a Window Manager to a Desktop Shell added a few (or possibly lot) of familiar desktop components. When a user first sits down at their terminal, they see an inviting user interface and (assuming we've installed useful Application Software), he/she can begin using the system regularly. But what happens when the user encounters some undesirable system configuration? For instance, the user becomes unhappy with the system's excess power consumption. A solution to this would be the inclusion of a Power Management utility. Audio volume is another perfect example where a configuration utility would benefit many users (no user wants to blow out their eardrum while searching for 'adorable kittens' on YouTube). When you combine useful configuration utilities with a Desktop Shell, a Desktop Environment begins to emerge. However, adding utilities to the shell is only part of creating a 'complete desktop experience'. Desktop Environments also include a set of System Software whose goal is to add convenience, but remains invisible to the user. Such software is typically known as a daemon and acts as a service running in the background. Examples of daemon software include: flash drive detection, automatic updates, scheduling services, desktop sharing, etc.

And now you know! Well, sort of. Confusion is likely to creep up whenever ambitious developers blur definitions. It's not necessarily a 'bad thing' when certain features overlap, but it can complicate modularity and user understanding. For Windows, this overlap isn't a problem because the OS's self-contained nature leaves plenty of room for 'line blurring'. It could be argued, however, that Windows' strict enforcement of the GUI discourages users that want to switch from GNULinux or Mac OS.

I'd love to go even further with this topic by comparing examples of each GUI module, but I'm afraid if I keep going, I might just write a book! However, if you'd like me to expand on any of the topics I mentioned above, or topics from any other posts, throw some feedback my way and I'll see what I can do. Keep learning and try not to core dump! Till next time, sayonara!

Difference Between Application Software and System Software

This post is meant for that reader who's not-so-tech-savvy, but wants to get a head start in the world of computing. I'm excited to share details about my future projects, but since my primary focus is technology, I realize that certain topics may be over a beginner's head. To help minimize this knowledge gap, I want to offer my readers a starting point. After all,

"a journey of a thousand miles begins with a single step" - Lau Tzu

As the title implies, this post discusses the difference between Application Software and System Software. We'll begin by exploring the concepts of computer Operating Systems (OSs) and user applications. Over the years, many OSs have been developed, each with a different goal in mind. The most familiar type of OS is the General Purpose OS installed on Personal Computers (PCs). There are several flavors of the General Purpose OS, but in recent years, three well-known names have virtually dominated the PC world: Windows, Mac OS, and GNULinux. Since you're reading an online resource, I'll assume you've used a PC at some point in your life. If this is the case, I feel safe assuming the PC was driven by one the Operating Systems listed above. However, with the diffusion of web-enabled mobile devices, it's also possible that you're reading this on a phone, tablet, or MP3 player. In this case, the device is driven by a Mobile OS and not a General Purpose OS. Either way, you've had first-hand experience using two different types of software: System Software and Application Software.

The primary goal of an Operating System is to establish a platform that supports user applications. The term 'platform' is used widely in technology and engineering to define a foundation on which other mechanisms can be built. Examples of user applications include: Web Browsers (for surfing the Internet), File Managers (for browsing digital documents), Word Processors (for creating and editing documents) and Image Viewers (for opening and viewing digital images). These applications are built on OS platforms and use platform services to enhance user experience.

One very important function of an OS is to give applications access to an Operating Environment. An Operating Environment is a user's primary interface to the computer. If you continue down a technology path, you'll encounter the term 'interface' a lot. An interface is a common medium between two things enabling them to exchange resources. In the case of an Operating Environment, users'input data via a keyboard, mouse, microphone, or similar input device (interface). Applications, on the other hand, output data via computer screens, speakers, printers, or similar output devices (interfaces). The Operating Environment most familiar with today's users, is the Desktop Environment on their PC. Here, the user is presented with interactive graphical representations of the underlying software. For example, to open a Web Browser, a user clicks an icon on the desktop and watches as an interactive window loads their homepage. Multiple windows can appear on a single screen, optimizing users' multi-tasking capabilities. Another more recent Operating Environment is the Mobile Environment. Though it's still in its infancy by comparison, certain trends are emerging among the different OS flavors. For instance, mobile platforms add so much constraint to the user interface that 'application windows' are mostly non-existent. Instead, when the user launches an application from the mobile desktop, that application takes control of the entire screen. There are many more differences, but those are beyond the scope of this post.

So how do Operating Systems and user applications relate to System Software and Application Software? The answer is simple! Operating Systems are made from a set of System Software that works to create a platform for user applications. Likewise, applications are a set of Application Software built on an OS platform to serve user needs. It may already be clear at this point, but I'd like to define the key difference between the two software types: System Software supplies service(s) to Application Software while Application Software supplies service(s) to its users. Let's try investigating what this difference actually means.

As mentioned above, System Software is goal-oriented toward providing service to user applications. Since computer hardware is very sensitive, careless software design can easily damage expensive equipment. For this reason, Application Software is not able to access hardware directly. Instead, the OS handles all hardware related tasks and acts as an interface for all user applications. Technically speaking, OSs aren't necessary for a computer system to run. However, this model of computing comes with risks and inconveniences. For starters, app developers no longer have access to stable implementations of hardware and policy services. Since these functions are dangerous, tedious, and difficult to reproduce, app development is made exponentially harder. On the same note, users would lose the OS-provided luxury of simultaneously running multiple applications. Having the freedom to launch more than one app in a single session improves both usability and efficiency.

As you might imagine, the OS does much more than push graphics from an application to the screen. Some OS hardware services include: disk access and management; memory access; network device control; Input and Output device control; expansion card access; etc. For now, try not to worry about any hardware terms you're unfamiliar with. You may recall from an earlier paragraph that I used the word 'policy'. Policies are governed by System Software and define access privileges and restraints on a 'user by user', 'group by group' and 'application by application' basis. Some examples of OS policies include: limiting user access to his/her data; managing Application Software's hardware utilization; managing shared resources between multiple applications; setting system securities and Access Control Lists (ACLs); etc.

In summary, we define a General Purpose Operating System as a set of System Software meant to deliver hardware and policy services to Application Software. In turn, users can access data (either locally or remotely) by using the services offered by Application Software. Remember that we've only covered the surface of General Purpose (or Mobile) OSs. There are other Operating Systems with similar features, but not all follow a similar model. For example, it's likely that a production computer is driven by an embedded OS designed to control machinery rather than interface with users. Other computing devices, such as communication systems, are likely to run a Real-Time OS (RTOS), whose primary goal is to receive, process, and transmit data within predictable margins of time. Regardless, the information here can act as a foundation when further investigating other OS types. Keep your head high and your sight toward a brighter tomorrow! Till then, chow.

Related Posts by Zack Sims:
Window Managers and Systems Vs Desktop Shells and Environments