Operating System

The 's master control program. When the computer is turned on, a small "boot program" loads the . Although additional modules may be loaded as needed, the main part, known as the "kernel" resides in memory at all times.

The operating system (OS) sets the standards for all application programs that run in the computer. Applications "talk to" the operating system for all and file management operations. Also called an "executive" or "supervisor," an operating system performs the following functions.

User Interface

All graphics based today, the user interface includes the windows, menus and method of interaction between you and the computer. Prior to graphical user interfaces (GUIs), all operation of the computer was performed by typing in commands. Not at all extinct, command-line interfaces are alive and well and provide an alternate way of running programs on all major operating systems.

Operating systems may support optional interfaces, both graphical and command line. Although the overwhelming majority of people work with the default interfaces, different "shells" offer variations of appearance and functionality.

Job Management

Job management controls the order and time in which programs are run and is more sophisticated in the mainframe environment where the daily work has always been routine. IBM's (JCL) was developed decades ago. In a , batch files can be written to perform a sequence of operations that can be scheduled to start at a given time.

Task Management

Multitasking, which is the ability to simultaneously execute multiple programs, is available in all operating systems today. Critical in the mainframe and server environment, applications can be prioritized to run faster or slower depending on their purpose. In the desktop world, multitasking is necessary for keeping several applications open at the same time so you can bounce back and forth among them. See multitasking.

Data Management

Data management keeps track of the data on disk, tape and optical storage devices. The application program deals with data by file name and a particular location within the file. The operating system's knows where that data are physically stored (which sectors on disk) and interaction between the application and operating system is through the programming interface. Whenever an application needs to read or write data, it makes a call to the operating system (see API). Device Management

Device management controls peripheral devices by sending them commands in their own proprietary language. The software routine that knows how to deal with each device is called a "driver," and the OS requires drivers for the peripherals attached to the computer. When a new peripheral is added, that device's driver is installed into the operating system. See driver.

Security

Operating systems provide password protection to keep unauthorized users out of the system. Some operating systems also maintain activity logs and accounting of the user's time for billing purposes. They also provide backup and recovery routines for starting over in the event of a system failure.

Operating System and This diagram shows the components of the operating system and typical application .programs that run in a desktop computer

Drivers and Peripherals This diagram shows the interaction between the operating system, the drivers and the peripheral devices

Process management

Every program running on a computer, be it a service or an application, is a . As long as a von Neumann architecture is used to build , only one process per CPU can be run at a time. Older OSes such as MS-DOS did not attempt to bypass this limit, with the exception of processing, and only one process could be run under them (although DOS itself featured TSR as a very partial and not too easy to use solution). Mainframe operating systems have had multitasking capabilities since the early 1960s. Modern operating systems enable concurrent execution of many processes at once via multitasking even with one CPU. Process management is an operating system's way of dealing with running multiple processes. Since most computers contain one processor with one core, multitasking is done by simply switching processes quickly. Depending on the operating system, as more processes run, either each time slice will become smaller or there will be a longer delay before each process is given a chance to run. Process management involves and distributing CPU time as well as other resources. Most operating systems allow a process to be assigned a priority which affects its allocation of CPU time. Interactive operating systems also employ some level of feedback in which the task with which the user is working receives higher priority. Interrupt driven processes will normally run at a very high priority. In many systems there is a background process, such as the System Idle Process in Windows, which will run when no other process is waiting for the CPU.

Memory management

Current computer architectures arrange the computer's memory in a hierarchical manner, starting from the fastest registers, CPU cache, random access memory and disk storage. An operating system's memory manager coordinates the use of these various types of memory by tracking which one is available, which is to be allocated or deallocated and how to move data between them. This activity, usually referred to as management, increases the amount of memory available for each process by making the disk storage seem like main memory. There is a speed penalty associated with using disks or other slower storage as memory – if running processes require significantly more RAM than is available, the system may start thrashing. This can happen either because one process requires a large amount of RAM or because two or more processes compete for a larger amount of memory than is available. This then leads to constant transfer of each process's data to slower storage.

Another important part of is managing virtual addresses. If multiple processes are in memory at once, they must be prevented from interfering with each other's memory (unless there is an explicit request to utilise shared memory). This is achieved by having separate address spaces. Each process sees the whole virtual address space, typically from address 0 up to the maximum size of virtual memory, as uniquely assigned to it. The operating system maintains a page table that match virtual addresses to physical addresses. These memory allocations are tracked so that when a process terminates, all memory used by that process can be made available for other processes.

The operating system can also write inactive memory pages to secondary storage. This process is called "paging" or "swapping" – the terminology varies between operating systems.

It is also typical for operating systems to employ otherwise unused physical memory as a page cache; requests for data from a slower device can be retained in memory to improve performance. The operating system can also pre-load the in-memory cache with data that may be requested by the user in the near future; SuperFetch is an example of this.

Disk and file systems

All operating systems include support for a variety of file systems.

Modern file systems comprise a hierarchy of directories. While the idea is conceptually similar across all general-purpose file systems, some differences in implementation exist. Two noticeable examples of this are the character used to separate directories, and .

Unix demarcates its components with a slash (/), a convention followed by operating systems that emulated it or at least its concept of hierarchical directories, such as , OS and Mac OS X. MS-DOS also emulated this feature, but had already also adopted the CP/M convention of using slashes for additional options to commands, so instead used the backslash (\) as its component separator. continues with this convention; Japanese editions of Windows use ¥, and Korean editions use ₩[citation needed]. Versions of Mac OS prior to OS X use a (:) for a path separator. RISC OS uses a period (.).

Unix and Unix-like operating systems allow for any character in file names other than the slash (including line feed (LF) and other control characters). Unix file names are case sensitive, which allows multiple files to be created with names that differ only in case. By contrast, Microsoft Windows file names are not case sensitive by default. Windows also has a larger set of punctuation characters that are not allowed in file names.

File systems may provide journaling, which provides safe recovery in the event of a system crash. A journaled file system writes information twice: first to the journal, which is a log of file system operations, then to its proper place in the ordinary file system. In the event of a crash, the system can recover to a consistent state by replaying a portion of the journal. In contrast, non-journaled file systems typically need to be examined in their entirety by a utility such as fsck or chkdsk. Soft updates is an alternative to journalling that avoids the redundant writes by carefully ordering the update operations. Log-structured file systems and ZFS also differ from traditional journaled file systems in that they avoid inconsistencies by always writing new copies of the data, eschewing in-place updates. Many Linux distributions support some or all of ext2, ext3, ReiserFS, Reiser4, GFS, GFS2, OCFS, OCFS2, and NILFS. Linux also has full support for XFS and JFS, along with the FAT file systems, and NTFS.

Microsoft Windows includes support for FAT12, FAT16, FAT32, and NTFS. The NTFS file system is the most efficient and reliable of the four Windows file systems, and as of Windows Vista, is the only file system which the operating system can be installed on. Windows Embedded CE 6.0 introduced ExFAT, a file system suitable for flash drives.

Mac OS X supports HFS+ as its primary file system, and it supports several other file systems as well, including FAT16, FAT32, NTFS and ZFS.

Common to all these (and other) operating systems is support for file systems typically found on removable media. FAT12 is the file system most commonly found on floppy discs. ISO 9660 and are two common formats that target Compact Discs and DVDs, respectively. Mount Rainier is a newer extension to UDF supported by Linux 2.6 kernels and Windows-Vista that facilitates rewriting to DVDs in the same fashion as what has been possible with floppy disks.

Networking

Most current operating systems are capable of using the TCP/IP networking protocols. This means that computers running dissimilar operating systems can participate in a common network for sharing resources such as computing, files, printers, and scanners using either wired or wireless connections.

Many operating systems also support one or more vendor-specific legacy networking protocols as well, for example, SNA on IBM systems, DECnet on systems from Digital Equipment Corporation, and Microsoft-specific protocols on Windows. Specific protocols for specific tasks may also be supported such as NFS for file access.

Security

Many operating systems include some level of security. Security is based on the two ideas that:

• The operating system provides access to a number of resources, directly or indirectly, such as files on a local disk, privileged system calls, personal information about users, and the services offered by the programs running on the system; • The operating system is capable of distinguishing between some requesters of these resources who are authorized (allowed) to access the resource, and others who are not authorized (forbidden). While some systems may simply distinguish between "privileged" and "non-privileged", systems commonly have a form of requester identity, such as a user name. Requesters, in turn, divide into two categories: o Internal security: an already running program. On some systems, a program once it is running has no limitations, but commonly the program has an identity which it keeps and is used to check all of its requests for resources. o External security: a new request from outside the computer, such as a login at a connected console or some kind of network connection. To establish identity there may be a process of authentication. Often a username must be quoted, and each username may have a password. Other methods of authentication, such as magnetic cards or biometric data, might be used instead. In some cases, especially connections from the network, resources may be accessed with no authentication at all.

In addition to the allow/disallow model of security, a system with a high level of security will also offer auditing options. These would allow tracking of requests for access to resources (such as, "who has been reading this file?").

Security of operating systems has long been a concern because of highly sensitive data held on computers, both of a commercial and military nature. The United States Government Department of Defense (DoD) created the Trusted Computer System Evaluation Criteria (TCSEC) which is a standard that sets requirements for assessing the effectiveness of security. This became of vital importance to operating system makers, because the TCSEC was used to evaluate, classify and select computer systems being considered for the processing, storage and retrieval of sensitive or classified information.

Internal security

Internal security can be thought of as protecting the computer's resources from the programs concurrently running on the system. Most operating systems set programs running natively on the computer's processor, so the problem arises of how to stop these programs doing the same task and having the same privileges as the operating system (which is after all just a program too). Processors used for general purpose operating systems generally have a hardware concept of privilege. Generally less privileged programs are automatically blocked from using certain hardware instructions, such as those to read or write from external devices like disks. Instead, they have to ask the privileged program (operating system kernel) to read or write. The operating system therefore gets the chance to check the program's identity and allow or refuse the request.

An alternative strategy, and the only sandbox strategy available in systems that do not meet the Popek and Goldberg virtualization requirements, is the operating system not running user programs as native code, but instead either emulates a processor or provides a host for a p-code based system such as Java.

Internal security is especially relevant for multi-user systems; it allows each user of the system to have private files that the other users cannot tamper with or read. Internal security is also vital if auditing is to be of any use, since a program can potentially bypass the operating system, inclusive of bypassing auditing. External security

Typically an operating system offers (or ) various services to other network computers and users. These services are usually provided through ports or numbered access points beyond the operating systems network address. Services include offerings such as file sharing, print services, email, web sites, and file transfer protocols (FTP), most of which can have compromised security.

At the front line of security are hardware devices known as firewalls or intrustion detection/prevention systems. At the operating system level, there are a number of software firewalls available, as well as intrusion detection/prevention systems. Most modern operating systems include a software firewall, which is enabled by default. A software firewall can be configured to allow or deny network traffic to or from a service or application running on the operating system. Therefore, one can install and be running an insecure service, such as Telnet or FTP, and not have to be threatened by a security breach because the firewall would deny all traffic trying to connect to the service on that port.

Graphical user interfaces

Today, most modern operating systems contain Graphical User Interfaces . A few older operating systems tightly integrated the GUI to the kernel—for example, in the original implementations of Microsoft Windows and Mac OS the Graphical subsystem was actually part of the operating system. More modern operating systems are modular, separating the graphics subsystem from the kernel (as is now done in Linux, and Mac OS X) so that the graphics subsystem is not part of the OS at all.

Many operating systems allow the user to install or create any user interface they desire. The X System in conjunction with GNOME or KDE is a commonly found setup on most Unix and Unix derivative (BSD, Linux, ) systems.

Graphical user interfaces evolve over time. For example, Windows has modified its user interface almost every time a new major version of Windows is released, and the Mac OS GUI changed dramatically with the introduction of Mac OS X in 2001.

Device drivers

A is a specific type of computer software developed to allow interaction with hardware devices. Typically this constitutes an interface for communicating with the device, through the specific computer bus or communications subsystem that the hardware is connected to, providing commands to and/or receiving data from the device, and on the other end, the requisite interfaces to the operating system and software applications. It is a specialized hardware-dependent which is also operating system specific that enables another program, typically an operating system or applications software package or computer program running under the operating system kernel, to interact transparently with a hardware device, and usually provides the requisite interrupt handling necessary for any necessary asynchronous time-dependent hardware interfacing needs. The key design goal of device drivers is abstraction. Every model of hardware (even within the same class of device) is different. Newer models also are released by manufacturers that provide more reliable or better performance and these newer models are often controlled differently. Computers and their operating systems cannot be expected to know how to control every device, both now and in the future. To solve this problem, OSes essentially dictate how every type of device should be controlled. The function of the device driver is then to translate these OS mandated function calls into device specific calls. In theory a new device, which is controlled in a new manner, should function correctly if a suitable driver is available. This new driver will ensure that the device appears to operate as usual from the operating systems' point of view for any person..

Mainframe computers

The earliest operating systems were developed for architectures in the 1960s. The enormous investment in software for these systems caused most of the original computer manufacturers to continue to develop hardware and operating systems that are compatible with those early operating systems. Those early systems pioneered many of the features of modern operating systems. Mainframe operating systems that are still supported include:

• Burroughs MCP -- B5000,1961 to Clearpath/MCP, present. • IBM OS/360 -- IBM System/360, 1964 to IBM zSeries, present • UNIVAC 8 -- UNIVAC 1108, 1964, to Unisys Clearpath IX, present.

Modern mainframes typically also run Linux or Unix variants. A "Datacenter" variant of 2003 is also available for some mainframe systems.

Embedded systems

Embedded systems use a variety of dedicated operating systems. In some cases, the "operating system" software is directly linked to the application to produce a monolithic special-purpose program. In the simplest embedded systems, there is no distinction between the OS and the application. Embedded systems that have certain time requirements are known as Real-time operating systems.

Unix-like operating systems

A customized KDE desktop running under Linux.

The Unix-like family is a diverse group of operating systems, with several major sub- categories including System tag">V, BSD, and Linux. The name "UNIX" is a trademark of The Open Group which licenses it for use with any operating system that has been shown to conform to their definitions. "Unix-like" is commonly used to refer to the large set of operating systems which resemble the original Unix.

Unix systems run on a wide variety of machine architectures. They are used heavily as server systems in business, as well as workstations in academic and engineering environments. Free software Unix variants, such as Linux and BSD, are popular in these areas. The market share for Linux is divided between many different distributions. Enterprise class distributions by Red Hat or SuSe are used by corporations, but some home users may use those products. Historically home users typically installed a distribution themselves, but in 2007 Dell began to offer the Ubuntu Linux distribution on home PCs. Linux on the desktop is also popular in the developer and hobbyist operating system development communities. (see below)

Market share statistics for freely available operating systems are usually inaccurate since most free operating systems are not purchased, making usage under-represented. On the other hand, market share statistics based on total downloads of free operating systems are often inflated, as there is no economic disincentive to acquire multiple operating systems so users can download multiple, test them, and decide which they like best,

Some Unix variants like HP's HP-UX and IBM's AIX are designed to run only on that vendor's hardware. Others, such as Solaris, can run on multiple types of hardware, including x86 servers and PCs. Apple's Mac OS X, a -based BSD variant derived from NeXTSTEP, , and FreeBSD, has replaced Apple's earlier (non- Unix) Mac OS.

Open source See POSIX -- full Unix interoperability heavily depends on full POSIX standards compliance. The POSIX standard applies to any operating system.

Over the past several years, the trend in the Unix and Unix-like space has been to open source operating systems. Many areas previously dominated by UNIX have seen significant inroads by Linux; Solaris is now the basis of the OpenSolaris project.

The team at Bell Labs that designed and developed Unix went on to develop Plan 9 and Inferno, which were designed for modern distributed environments. They had graphics built-in, unlike Unix counterparts that added it to the design later. Plan 9 did not become popular because, unlike many Unix distributions, it was not originally free. It has since been released under Free Software and Open Source Lucent Public License, and has an expanding community of developers. Inferno was sold to Vita Nuova and has been released under a GPL/MIT license.

Mac OS X

Mac OS X is a line of proprietary, graphical operating systems developed, marketed, and sold by Apple Inc., the latest of which is pre-loaded on all currently shipping computers. Mac OS X is the successor to the original Mac OS, which had been Apple's primary operating system since 1984. Unlike its predecessor, Mac OS X is a UNIX operating system built on technology that had been developed at NeXT through the second half of the 1980s and up until Apple purchased the company in early 1997.

The operating system was first released in 1999 as Mac OS X Server 1.0, with a desktop-oriented version (Mac OS X v10.0) following in March 2001. Since then, four more distinct "end-user" and "server" editions of Mac OS X have been released, the most recent being Mac OS X v10.4, which was first made available in April 2005. Releases of Mac OS X are named after big cats; Mac OS X v10.4 is usually referred to by Apple and users as "Tiger". In October 2007, Apple will release Mac OS X 10.5, nicknamed "Leopard".

The server edition, Mac OS X Server, is architecturally identical to its desktop counterpart but usually runs on Apple's line of Macintosh server hardware. Mac OS X Server includes workgroup management and administration software tools that provide simplified access to key network services, including a mail transfer agent, a Samba server, an LDAP server, a domain name server, and others.

Microsoft Windows

The Microsoft Windows family of operating systems originated as a graphical layer on top of the older MS-DOS environment for the IBM PC. Modern versions are based on the newer Windows NT core that first took shape in OS/2 and borrowed from VMS. Windows runs on 32-bit and 64-bit Intel and AMD processors, although earlier versions also ran on the DEC Alpha, MIPS, Fairchild (later Intergraph) Clipper and PowerPC architectures (some work was done to port it to the SPARC architecture).

As of July 2007, Microsoft Windows held a large amount on the worldwide desktop market share, although some [attribution needed] predict this to dwindle due to Microsoft's restrictive licensing, (-Key) registration, and customer practices causing an increased interest in open source operating systems. Windows is also used on low-end and mid-range servers, supporting applications such as web servers and servers. In recent years, Microsoft has spent significant marketing and research & development money to demonstrate that Windows is capable of running any enterprise application, which has resulted in consistent price/performance records (see the TPC) and significant acceptance in the enterprise market.

The most widely used version of the Microsoft Windows family is Microsoft Windows XP, released on October 25, 2001. The latest release of Windows XP is Windows XP Service Pack 2, released on August 6, 2004.

In November 2006, after more than five years of development work, Microsoft released Windows Vista, a major new version of Microsoft Windows which contains a large number of new features and architectural changes. Chief amongst these are a new user interface and visual style called Windows Aero, a number of new security features such as User Account Control, and new multimedia applications such as Windows DVD Maker. Hobby operating system development

Operating system development, or OSDev for short, as a hobby has a large cult following. As such, operating systems, such as Linux, have derived from hobby operating system projects. The design and implementation of an operating system requires skill and determination, and the term can cover anything from a basic "Hello World" boot loader to a fully featured kernel. One classical example of this is the Minix Operating System -- an OS that was designed as a teaching tool but was heavily used by hobbyists before Linux eclipsed it in popularity.

Other

Mainframe operating systems, such as IBM's z/OS, and embedded operating systems such as VxWorks, eCos, and Palm OS, are usually unrelated to Unix and Windows, except for Windows CE, Windows NT Embedded 4.0 and Windows XP Embedded which are descendants of Windows, and several *BSDs, and Linux distributions tailored for embedded systems. OpenVMS from Hewlett-Packard (formerly DEC), is still under active development.

Older operating systems which are still used in niche markets include OS/2 from IBM; Mac OS, the non-Unix precursor to Apple's Mac OS X; BeOS; XTS-300.

Popular prior to the Dot COM era, operating systems such as AmigaOS and RISC OS continue to be developed as minority platforms for enthusiast communities and specialist applications.

Research and development of new operating systems continues. GNU Hurd is designed to be backwards compatible with Unix, but with enhanced functionality and a architecture. Singularity is a project at Microsoft Research to develop an operating system with better based on the .Net managed code model.2008

The history of computer operating systems recapitulates to a degree, the recent history of computing.

Operating systems (OS) provide a set of functions needed and used by most application-programs on a computer, and the necessary linkages for the control and sychronization of the computer's hardware. On the first computers, without an operating system, every program needed the full hardware specification to run correctly and perform standard tasks, and its own drivers for peripheral devices like printers and card-readers. The growing complexity of hardware and application- programs eventually made operating systems a necessity.

Background

Early computers lacked any form of operating system. The user had sole use of the machine and would arrive armed with program and data, often on punched paper and tape. The program would be loaded into the machine, and the machine would be set to work until the program completed or crashed. Programs could generally be debugged via a front panel using switches and lights. It is said that Alan Turing was a master of this on the early Manchester Mark I machine, and he was already deriving the primitive conception of an operating system from the principles of the Universal Turing machine.

Later machines came with libraries of support code, which would be linked to the user's program to assist in operations such as input and output. This was the genesis of the modern-day operating system. However, machines still ran a single job at a time; at Cambridge University in England the job queue was at one time a washing line from which tapes were hung with different colored clothes-pegs to indicate job- priority.

As machines became more powerful, the time needed for a run of a program diminished and the time to hand off the equipment became very large by comparison. Accounting for and paying for machine usage moved on from checking the wall clock to automatic logging by the computer. Run queues evolved from a literal queue of people at the door, to a heap of media on a jobs-waiting table, or batches of punch- cards stacked one on top of the other in the reader, until the machine itself was able to select and sequence which magnetic tape drives were online. Where program developers had originally had access to run their own jobs on the machine, they were supplanted by dedicated machine operators who looked after the well-being and maintenance of the machine and were less and less concerned with implementing tasks manually. When commercially available computer centers were faced with the implications of data lost through tampering or operational errors, equipment vendors were put under pressure to enhance the runtime libraries to prevent misuse of system resources. Automated monitoring was needed not just for CPU usage but for counting pages printed, cards punched, cards read, disk storage used and for signalling when operator intervention was required by jobs such as changing magnetic tapes.

All these features were building up towards the repertoire of a fully capable operating system. Eventually the runtime libraries became an amalgamated program that was started before the first customer job and could read in the customer job, control its execution, clean up after it, record its usage, and immediately go on to process the next job. Significantly, it became possible for to use symbolic program- code instead of having to hand-encode binary images, once task-switching allowed a computer to perform translation of a program into binary form before running it. These resident background programs, capable of managing multistep processes, were often called monitors or monitor-programs before the term OS established itself.

An underlying program offering basic hardware-management, software-scheduling and resource-monitoring may seem a remote ancestor to the user-oriented OSes of the personal computing era. But there has been a shift in meaning. With the era of commercial computing, more and more "secondary" software was bundled in the OS package, leading eventually to the perception of an OS as a complete user-system with utilities, applications (such as text editors and file managers) and configuration tools, and having an integrated . The true descendant of the early operating systems is what we now call the "kernel". In technical and development circles the old restricted sense of an OS persists because of the continued active development of embedded operating systems for all kinds of devices with a data-processing component, from hand-held gadgets up to industrial robots and real-time control-systems, which do not run user-applications at the front-end. An embedded OS in a device today is not so far removed as one might think from its ancestor of the 1950s.

The broader categories of systems and application software are discussed in the computer software article.

The mainframe era

Early operating systems were very diverse, with each vendor producing one or more operating systems specific to their particular hardware. Every operating system, even from the same vendor, could have radically different models of commands, operating procedures, and such facilities as debugging aids. Typically, each time the manufacturer brought out a new machine, there would be a new operating system. This state of affairs continued until the 1960s when IBM developed the System/360 series of machines which all used the same instruction architecture. Because there were enormous performance differences across the range, a single operating system could not be used and a family of operating systems were developed. See: OS/360. (The problems encountered in the development of the OS/360 are legendary, and are described by Fred Brooks in The Mythical Man-Month—a book that has become a classic of software engineering).

OS/360 evolved to become successively MFT, MVT, SVS, MVS, MVS/XA, MVS/ESA, OS/390 and z/OS, that includes the UNIX kernel as well as a huge amount of new functions required by modern mission-critical applications running on the zSeries mainframes. It is worth mentioning, that IBM maintained full compatibility with the past, so that programs developed in the sixties can still run under z/OS with no change. Although z/OS runs UNIX applications, it is a proprietary OS.

Control Data Corporation developed the Scope operating system in the 1960s, for . In cooperation with the University of Minnesota, the KRONOS and later the NOS operating systems were developed during the 1970s, which supported simultaneous batch and timesharing use. Like many commercial timesharing systems, its interface was an extension of the Dartmouth BASIC operating systems, one of the pioneering efforts in timesharing and programming languages. In the late 1970s, Control Data and the University of Illinois developed the PLATO operating system, which used plasma panel displays and long-distance time sharing networks. Plato was remarkably innovative for its time, featuring real-time chat, and multi-user graphical games.

UNIVAC, the first commercial computer manufacturer, produced a series of EXEC operating systems. Like all early main-frame systems, this was a batch-oriented system that managed magnetic drums, disks, card readers and line printers. In the 1970s, UNIVAC produced the Real-Time Basic (RTB) system to support large-scale time sharing, also patterned after the Dartmouth BASIC system.

General Electric and MIT developed General Comprehensive Operating System (or General Electric Comprehensive Operating System) known as GECOS and later GCOS when General Electric's computer business was acquired by Honeywell. GECOS introduced the concept of ringed security privilege levels. Digital Equipment Corporation developed many operating systems for its various computer lines, including the simple RT-11 system for its 16-bit PDP-11 class machines, the VMS system for the 32-bit VAX computer, and TOPS-10 and TOPS-20 time sharing systems for the 36-bit PDP-10 class systems. Prior to the widespread use of UNIX, TOPS-10 was a particularly popular system in universities, and in the early ARPANET community.

Minicomputers and the rise of UNIX

The beginnings of the UNIX operating system was developed at AT&T Bell Laboratories in the late 1960s. Because it was essentially free in early editions, easily obtainable, and easily modified, it achieved wide acceptance. It also became a requirement within the Bell systems operating companies. Since it was written in a high level language, when that language was ported to a new machine architecture UNIX was also able to be ported. This portability permitted it to become the choice for a second generation of and the first generation of workstations. By widespread use it exemplified the idea of an operating system that was conceptually the same across various hardware platforms. It still was owned by AT&T and that limited its use to groups or corporations who could afford to license it.

Many early operating systems were collections of utilities to allow users to run software on their systems. There were some companies who were able to develop better systems, such as early Digital Equipment Corporation systems, but others never supported features that were useful on other hardware types.

In the late 1960s through the late 1970s, several hardware capabilities evolved that allowed similar or ported software to run on more than one system. Early systems had utilized Microprogramming to implement features on their systems in order to permit different underlying architecture to appear to be the same as others in a series. In fact most 360's after the 360/40 (except the 360/165 and 360/168) were microprogrammed implementations.

One system which evolved in this time frame was the . The Pick system was developed and sold by Microdata Corporation who created the precursors of the system . The system is an example of a system which started as a database application support program, graduated to system work, and still exists across a wide variety of systems supported on most UNIX systems as an addon database system.

Other packages such as Oracle are middleware and contain many of the features of operating systems, but are in fact large applications supported on many hardware platforms.

As hardware was packaged in ever larger amounts in small packages, first the bit slice level of integration in systems, and then entire systems came to be present on a single chip. This type of system in small 4 and 8 bit processors came to be known as microprocessors. Most were not microprogrammed, but were completely integrated general purpose processors. The case of 8-bit home computers and game consoles

Home computers

Although most smallest 8-bit home computers of the 1980s, such as the Commodore 64, the Amstrad CPC, ZX Spectrum series and others could use a "normal" disk- loading operating system, such as CP/M or GEOS they could generally work without one. In fact, most if not all of these computers shipped with a built-in BASIC interpreter on ROM, which also served as a crude operating system, allowing minimal file management operations (such as deletion, copying, etc.) to be performed and sometimes disk formatting, along of course with application loading and execution, which sometimes required a non-trivial command sequence, like with the Commodore 64.

The fact that the majority of these machines were bought for entertainment and educational purposes and were seldom used for more "serious" or business/science oriented applications, partly explains why a "true" operating system was not necessary.

Another reason is that they were usually single-task and single-user machines and shipped with minimal amounts of RAM, usually between 4 and 256 kilobytes, with 64 and 128 being common figures, and 8-bit processors, so an operating system's overhead would likely compromise the performance of the machine without really being necessary.

Even the rare word processor and office suite applications were mostly self-contained programs which took over the machine completely, as also did video games.

Finally, most of these machines didn't even ship with a built-in flexible disk drive, which made using a disk-based OS impossible or a luxury option.

Game consoles and video games

Since virtually all video game consoles and arcade cabinets designed and built after 1980 were true digital machines (unlike the analog Pong clones and derivatives), some of them carried a minimal form of BIOS or built-in game, such as the ColecoVision, the Sega Master System and the SNK Neo Geo. There were however successful designs where a BIOS was not necessary, such as the Nintendo NES and its clones.

Modern day game consoles and videogames, starting with the PC-Engine, all have a minimal BIOS that also provides some interactive utilities such as memory card management, Audio or Video CD playback, copy prevention and sometimes carry libraries for developers to use etc. Few of these cases, however, would qualify as a "true" operating system.

The most notable exceptions are probably the Dreamcast game console which includes a minimal BIOS, like the PlayStation, but can load the Windows CE operating system from the game disk allowing easily porting of games from the PC world, and the Xbox game console, which is little more than a disguised Intel-based PC running a secret, modified version of Microsoft Windows in the background.

Furthermore, there are Linux versions that will run on a PlayStation or Xbox and maybe other game consoles as well, provided they have access to a large mass storage device and have a reasonable amount of RAM (the bare minimum for a GUI is around 512 kilobytes, as the case of the Commodore Amiga or early ATARI ST shows. GEOS however ran on a stock C64 which came with as little as 64 kilobytes).

Long before that, Sony had released a kind of development kit called the Net Yaroze for its first PlayStation platform, which provided a series of programming and developing tools to be used with a normal PC and a specially modified "Black PlayStation" that could be interfaced with a PC and download programs from it. These operations require in general a functional OS on both platforms involved.

In general, it can be said that videogame consoles and arcade coin operated machines used at most a built-in BIOS during the 1970s, 1980s and most of the 1990s, while from the PlayStation era and beyond they started getting more and more sophisticated, to the point of requiring a generic or custom-built OS for aiding in development and expandability.

The era: Apple, PC/MS/DR-DOS and beyond

The development of microprocessors made inexpensive computing available for the small business and hobbyist, which in turn led to the widespread use of interchangeable hardware components using a common interconnection (such as the S-100, SS-50, Apple II, ISA, and PCI buses), and an increasing need for 'standard' operating systems to control them. The most important of the early OSes on these machines was Digital Research's CP/M-80 for the 8080 / 8085 / Z-80 CPUs. It was based on several Digital Equipment Corporation operating systems, mostly for the PDP-11 architecture. MS-DOS (or PC-DOS when supplied by IBM) was based originally on CP/M-80. Each of these machines had a small boot program in ROM which loaded the OS itself from disk. The BIOS on the IBM-PC class machines was an extension of this idea and has accreted more features and functions in the 20 years since the first IBM-PC was introduced in 1981.

The decreasing cost of display equipment and processors made it practical to provide graphical user interfaces for many operating systems, such as the generic X Window System that is provided with many UNIX systems, or other graphical systems such as Microsoft Windows, the RadioShack Color Computer's OS-9, Commodore's AmigaOS, Level II, Apple's Mac OS, or even IBM's OS/2. The original GUI was developed at Xerox Palo Alto Research Center in the early '70s (the Alto computer system) and imitated by many vendors.

Distributed systems

A distributed system consists of a collection of autonomous computers linked by a and equipped with distributed system software. This software enables computers to coordinate their activities and to share the resources of the system hardware, software, and data. Users of a distributed system should perceive a single, integrated computing facility even though it may be implemented by many computers in different locations. This is in contrast to a network, where the user is aware that there are several machines whose locations, storage replications, load balancing, and functionality are not transparent. Benefits of distributed systems include bridging geographic distances, improving performance and availability, maintaining autonomy, reducing cost, and allowing for interaction. See also Local- area networks; Wide-area networks.

The object-oriented model for a distributed system is based on the model supported by object-oriented programming languages. Distributed object systems generally provide remote method invocation (RMI) in an object-oriented together with operating systems support for object sharing and persistence. Remote procedure calls, which are used in client-server communication, are replaced by remote method invocation in distributed object systems. See also Object-oriented programming.

The state of an object consists of the values of its instance variables. In the object- oriented paradigm, the state of a program is partitioned into separate parts, each of which is associated with an object. Since object-based programs are logically partitioned, the physical distribution of objects into different processes or computers in a distributed system is a natural extension. The Object Management Group's Common Object Request Broker (CORBA) is a widely used standard for distributed object systems. Other object management systems include the Open Software Foundation's Distributed Computing Environment (DCE) and Microsoft's Distributed Common Object Manager (DCOM).

CORBA specifies a system that provides interoperability among objects in a heterogeneous, distributed environment in a way that is transparent to the . Its design is based on the Object Management Group's object model.

This model defines common object semantics for specifying the externally visible characteristics of objects in a standard and implementation-independent way. In this model, clients request services from objects (which will also be called servers) through a well-defined interface. This interface is specified in Object Management Group Interface Definition Language (IDL). The request is an event, and it carries information including an operation, the object reference of the service provider, and actual parameters (if any). The object reference is a name that defines an object reliably.

The central component of CORBA is the object request broker (ORB). It encompasses the entire communication infrastructure necessary to identify and locate objects, handle connection management, and deliver data. In general, the object request broker is not required to be a single component; it is simply defined by its interfaces. The core is the most crucial part of the object request broker; it is responsible for communication of requests.

The basic functionality provided by the object request broker consists of passing the requests from clients to the object implementations on which they are invoked. In order to make a request, the client can communicate with the ORB core through the Interface Definition Language stub or through the dynamic invocation interface (DII). The stub represents the mapping between the language of implementation of the client and the ORB core. Thus the client can be written in any language as long as the implementation of the object request broker supports this mapping. The ORB core then transfers the request to the object implementation which receives the request as an up-call through either an Interface Definition Language (IDL) skeleton (which represents the object interface at the server side and works with the client stub) or a dynamic skeleton (a skeleton with multiple interfaces).

Many different ORB products are currently available; this diversity is very wholesome since it allows the vendors to gear their products toward the specific needs of their operational environment. It also creates the need for different object request brokers to interoperate. Furthermore, there are distributed and client-server systems that are not CORBA-compliant, and there is a growing need to provide interoperability between those systems and CORBA. In order to answer these needs, the Object Management Group has formulated the ORB interoperability architecture.

The interoperability approaches can be divided into mediated and immediate bridging. With mediated bridging, interacting elements of one domain are transformed at the boundary of each domain between the internal form specific to this domain and some other form mutually agreed on by the domains. This common form could be either standard (specified by the Object Management Group, for example, Internet Inter- ORB Protocol or IIOP), or a private agreement between the two parties. With immediate bridging, elements of interaction are transformed directly between the internal form of one domain and the other. The second solution has the potential to be much faster, but is the less general one; it therefore should be possible to use both. Furthermore, if the mediation is internal to one execution environment (for example, TCP/IP), it is known as a full bridge; otherwise, if the execution environment of one object request broker is different from the common protocol, each object request broker is said to be a half bridge.

In computing, a system call is the mechanism used by an application program to request service from the operating system.

Background

In addition to processing data in its own memory space, an application program might want to use data and services provided by the system. Examples of the system providing a service to an application include: reporting the current time, allocating memory space, reading from or writing to a file, printing text on screen, and a host of other necessary actions.

Since the machine and its devices are shared between all the programs, the access must be synchronized. Some of the activities may fail the system or even destroy something physically. For these reasons, the access to the physical environment is strictly managed by the BIOS and operating system. The code and data of the OS is located in a protected area of memory and cannot be accessed/damaged by user applications. The only gate to the hardware is system calls, which are defined in the operating system. These calls check the requests and deliver them to the OS drivers, which control the hardware input/output directly.

Modern processors can typically execute instructions in several, very different, privileged states. In systems with two levels, they are usually called user mode and supervisor mode. Different privilege levels are provided so that operating systems can restrict the operations that programs running under them can perform, for reasons of security and stability. Such operations include accessing hardware devices, enabling and disabling , changing privileged processor state, and accessing memory management units.

With the development of separate operating modes with varying levels of privilege, a mechanism was needed for transferring control safely from lesser privileged modes to higher privileged modes. Less privileged code could not simply transfer control to more privileged code at any arbitrary point and with any arbitrary processor state. To allow it to do so could allow it to break security. For instance, the less privileged code could cause the higher privileged code to execute in the wrong order, or provide it with a bad stack.

Mechanism

System calls often use a special CPU instruction which causes the processor to transfer control to more privileged code, as previously specified by the more privileged code. This allows the more privileged code to specify where it will be entered as well as important processor state at the time of entry.

When the system call is invoked, the program which invoked it is interrupted, and information needed to continue its execution later is saved. The processor then begins executing the higher privileged code, which, by examining processor state set by the less privileged code and/or its stack, determines what is being requested. When it is finished, it returns to the program, restoring the saved state, and the program continues executing.

Note that in many cases, the actual return to the program may not be immediate. If the system call performs any kind of lengthy I/O operation, for instance disk or network access, the program may be suspended (“blocked”) and taken off the “ready” queue until the operation is complete, at which point the operating system will again make it a candidate for execution.

The as an intermediary

Generally, operating systems provide a library that sits between normal programs and the rest of the operating system, usually the library (libc), such as glibc and the Microsoft C runtime. This library handles the low-level details of passing information to the kernel and switching to supervisor mode, as well as any data processing and preparation which does not need to be done in privileged mode. Ideally, this reduces the coupling between the operating system and the application, and increases portability. On based systems, the library is especially important as an intermediary. On , OSes shield user applications from the very low level kernel API, and provide abstractions and resource management.