Operating system: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Pat Palmer
(Up-And-Running)
imported>Pat Palmer
(more on booting up)
Line 5: Line 5:
== Phases of Operating ==
== Phases of Operating ==


=== Booting Up ===
=== Booting=Up ===
In this phase, the [[computer]] begins loading the operating system itself, progressively testing hardware and loading more of the software that makes up the operating system into memory.  A simplified description of the booting up phase follows:
In this phase, the [[computer]] begins loading the operating system itself, progressively testing hardware and loading more of the software that makes up the operating system into memory.  A simplified description of the booting up phase follows:
   A. execution begins in special [[firmware]] (programs in non-volative memory)  
   A. execution begins in special [[firmware]] (programs in non-volative memory)  
Line 20: Line 20:
     problems were encountered, this phase ends and the Up-And-Running phase
     problems were encountered, this phase ends and the Up-And-Running phase
     begins
     begins
The Booting-Up phase is largely invisible to users, who experience it as a boring wait right after a [[computer]] is turned on.  The operating system may display a logo and either more or less audit information during this phase.  If an error occurs and the operating system does not boot correctly, the information displayed to a user may be limited to a few lines of text, or even worse, to a series of sound patterns (if hardware fails before software starts to run).


=== Up-And-Running ===
=== Up-And-Running ===
In this phase, the operating system software is ready to respond to commands from users and allow user programs to run.  The majority of this article describes services offered during the Up-And-Running phase.
In this phase, the operating system software is ready to respond to commands from users and allow user programs to run.  The majority of this article describes services offered during the Up-And-Running phase.


=== Closing Down ===
=== Closing-Down ===
In this phase, the computer ceases to respond to user commands and attempts a graceful, in-order shutdown of any running software and hardware.  This is especially important in case of a sudden, unexpected power outage.  NOTE: More description is needed here.
In this phase, the computer ceases to respond to user commands and attempts a graceful, in-order shutdown of any running software and hardware.  This is especially important in case of a sudden, unexpected power outage.  NOTE: More description is needed here.



Revision as of 23:20, 26 April 2007

An operating system (OS) is the underlying software that controls the applications and hardware resources of a computer. The typical major components of an operating system are a kernel, drivers, and its user interface. These components are generally bundled together.

Operating systems can be written so that they are basically not seen by the user; in fact on embedded systems such as cell phones, this is intentional.

Phases of Operating

Booting=Up

In this phase, the computer begins loading the operating system itself, progressively testing hardware and loading more of the software that makes up the operating system into memory. A simplified description of the booting up phase follows:

 A. execution begins in special firmware (programs in non-volative memory) 
    and performs several steps in order:
     1. consulting the BIOS to see what hardware is installed
     2. running diagnostics on the installed hardware
     3. locating a disk drive that has a "bootable" partition on it
     4. loading a special program (the bootstrap loader) on the "bootable"  
        partition that will then load the operating system
     5. transferring control to the now-loaded bootstrap program
 B. the bootstrap loader begins loading software components of the 
    operating system into memory
 C. when enough of the operating system is in memory, and if no critical 
    problems were encountered, this phase ends and the Up-And-Running phase
    begins

The Booting-Up phase is largely invisible to users, who experience it as a boring wait right after a computer is turned on. The operating system may display a logo and either more or less audit information during this phase. If an error occurs and the operating system does not boot correctly, the information displayed to a user may be limited to a few lines of text, or even worse, to a series of sound patterns (if hardware fails before software starts to run).

Up-And-Running

In this phase, the operating system software is ready to respond to commands from users and allow user programs to run. The majority of this article describes services offered during the Up-And-Running phase.

Closing-Down

In this phase, the computer ceases to respond to user commands and attempts a graceful, in-order shutdown of any running software and hardware. This is especially important in case of a sudden, unexpected power outage. NOTE: More description is needed here.

Typical Services of an Operating System (in the Up-And-Running Phase)

To modularize the functions performed by an operating system, its major responsibilities are usually further divided into subsystems. These subsystems are covered in the sections that follow.

Kernel

note: for a more detailed explanation see kernel

Overall a kernel is responsible for managing the resources provided by the computer, especially the CPU and the memory, for providing hardware access, often in conjunction with drivers, and for providing hardware abstractions such as the file system or network e.g. providing sockets. As such management tasks often involve the need to protect certain resources from user access, the kernel is also responsible for managing access rights and user identification.

It also typically runs in a special "privileged mode" where it has unrestricted access to all the hardware of the system it is running on. The exact amount and kind of services provided by the kernel depends on its design and architecture.

There are literally hundreds of different kernel designs, however they typically fall into one of three categories:

  • Micro-kernel architectures such as Mach only contain the basic functions within the kernel and run user space sub-systems in a separate address space. The kernel's main function is to coordinate the different sub-systems' requests for hardware and processor time. This design encourages modularity, and is intended to increase the kernel's reliability. For example, if the video card driver crashed in a micro-kernel design, only the video subsystem would be affected. The service could even restart automatically, only affecting the user for a short period of time. In other kernel designs such a low-level driver crashing could possibly take the entire system down with it. While compelling in theory, the design of a micro-kernel has proven to be much more complicated in practice, especially when considering that all the sub-system's accesses to hardware have to be coordinated. Usually this is accomplished with "message passing," where the different subsystems coordinate access to resources by "passing messages" to the kernel. The complexity of this design multiplies exponentially when factors such as multi-threading and multi-processor machines are taken into account, however. Minix is a popular example of a micro-kernel architecture.
  • A Monolithic kernel, as the name implies, is one in which all the kernel's functions are run in the same address space to simplify development and improve performance. The Linux kernel is a popular example of a monolithic kernel.

Some kernels are tied to one set of drivers or user interface, while some are interchangeable in one or both. The Microsoft Windows and Macintosh OS series have only one user interface per kernel, but can interchange drivers to work with different types of hardware. In comparison, the BSD and Linux kernel has no defined hardware nor user interface, and there are several different drivers and interfaces available for it.

Process management

Memory management

Drivers

Drivers provide a layer of abstraction that allow an operating system to access hardware. With drivers, the operating system needs to know only how to correctly interface with a certain class of driver, the details of that specific piece of hardware are left to the driver itself. For example, in the past video games that ran on the DOS operating system had to be specifically written for the underlying video card because of this lack of abstraction. This made programming for a wide audience difficult, and gamers that bought one type of video card might not be able to play a new game that had come out simply because the game hadn't been specifically written for their video card. Abstracting the "raw hardware" with drivers was one way that this problem was solved. Now the video game only had to be written to run on the operating system in question; the driver for the specific video card handled "translating" between the video game's requests and the actual commands sent to the hardware itself.

In closed source operating systems drivers are generally written by the manufacturer, which means the hardware manufacturer can decide what operating system or systems their products support. On open source operating systems such as Linux or the BSDs, if the manufacturer of the hardware doesn't publish documentation on the hardware, or better yet provide drivers written for these operating systems, the hardware has to be reverse engineered if it is to be supported.

Drivers are often loaded on bootup to ensure correct operations of all hardware. This means that hardware can only be changed while the computer is off. Plug and play hardware, however, can load the driver into memory as it is plugged in, as long as the driver has already been installed. If drivers are visible from user space as with the kernel module concept in Linux, it is also possible for a user with sufficient access rights to unload one driver and load another.

User interface

A user interface allows for humans to interact with a computer. If a system is not designed to be interacted with directly, the interface may be nonexistent, or perhaps only have a simple interface for debugging. The two major tasks of a user interface are to provide access to core functions, and to organize them into as seamless and intuitive a system as possible.

A command line-driven user interface (CLI), such as MS-DOS and Unix shells, of which there are many, work by parsing and executing text commands. Although they have largely phased out since the dawn of the fifth generation of computers, their low memory requirements make them useful for highly specialized purposes, such as computer repair, accessing a computer over a network or performing a large number of tasks in a sequential order very quickly.

A graphic user interface (or GUI). Graphic user interfaces generally emulate the system used in the Microsoft Windows series, with control panels to handle access system functions, icons, mouse-controlled pointers, context menus on a right click, multiple windows for multiple windows, and some analogue for the Start button. Some interfaces (such as BumpTop), while graphical, use completely different elements to present control structures.

Much rarer are voice-driven interfaces. These interfaces are usually used alongside with a GUI, although some computers are beginning to use them, due to purpose (such as certain GPS navigation systems) or experimentation.

Evolution of the Operating System

Operating systems as they are known today trace their lineage to the first distinctions between hardware and software. The first digital computers of the 1940s had no concept of abstraction; their operators inputted machine code directly to the machines they were working on. As computers evolved in the 1950s and 1960s however, the distinction between hardware such as the CPU and memory (or Core as it was called then) and the software that was written on top of it became apparent.

Time sharing systems in the 1960s and 1970s

  • CTSS / ITS
  • Multics / Unix

The dawn of the Personal Computer in the 1970s and 1980s

(note: personal computer includes Macs)

GUI driven operating systems in the 1980s and 1990s

Operating systems today (2007)

See also