Operating system

An operating system (OS) is syst em soft ware t hat manages comput er hardware and
soft ware resources, and provides common services for comput er programs.

Time-sharing operat ing syst ems schedule t asks for efficient use of t he syst em and
may also include account ing soft ware for cost allocat ion of processor t ime, mass
st orage, peripherals, and ot her resources.

For hardware funct ions such as input and out put and memory allocat ion, t he operat ing
syst em act s as an int ermediary bet ween programs and t he comput er hardware,[1][2]
alt hough t he applicat ion code is usually execut ed direct ly by t he hardware and
frequent ly makes syst em calls t o an OS funct ion or is int errupt ed by it . Operat ing
syst ems are found on many devices t hat cont ain a comput er – from cellular phones
and video game consoles t o web servers and supercomput ers.

As of Sept ember 2024, Android is t he most popular operat ing syst em wit h a 46%
market share, followed by Microsoft Windows at 26%, iOS and iPadOS at 18%, macOS
at 5%, and Linux at 1%. Android, iOS, and iPadOS are mobile operat ing syst ems, while
Windows, macOS, and Linux are deskt op operat ing syst ems.[3] Linux dist ribut ions are
dominant in t he server and supercomput ing sect ors. Ot her specialized classes of
operat ing syst ems (special-purpose operat ing syst ems),[4][5] such as embedded and
real-t ime syst ems, exist for many applicat ions. Securit y-focused operat ing syst ems
also exist . Some operat ing syst ems have low syst em requirement s (e.g. light -weight
Linux dist ribut ion). Ot hers may have higher syst em requirement s.

Some operat ing syst ems require inst allat ion or may come pre-inst alled wit h purchased
comput ers (OEM-inst allat ion), whereas ot hers may run direct ly from media (i.e. live
CD) or flash memory (i.e. USB st ick).

Definition and purpose

An operat ing syst em is difficult t o define,[6] but has been called "t he layer of soft ware
t hat manages a comput er's resources for it s users and t heir applicat ions".[7] Operat ing
syst ems include t he soft ware t hat is always running, called a kernel—but can include
ot her soft ware as well.[6][8] The t wo ot her t ypes of programs t hat can run on a
comput er are syst em programs—which are associat ed wit h t he operat ing syst em, but
may not be part of t he kernel—and applicat ions—all ot her soft ware.[8]

There are t hree main purposes t hat an operat ing syst em fulfills:[9]

Operating systems allocate

resources between different
applications, deciding when they
will receive central processing unit
(CPU) time or space in memory.[9]
On modern personal computers,
users often want to run several
applications at once. In order to
ensure that one program cannot
monopolize the computer's limited
hardware resources, the operating
system gives each application a
share of the resource, either in time
(CPU) or space (memory).[10][11]
The operating system also must
isolate applications from each
other to protect them from errors
and security vulnerabilities in
another application's code, but
enable communications between
different applications.[12]
Operating systems provide an
interface that abstracts the details
of accessing hardware details
(such as physical memory) to make
things easier for programmers.[9][13]
Virtualization also enables the
operating system to mask limited
hardware resources; for example,
virtual memory can provide a
program with the illusion of nearly
unlimited memory that exceeds the
computer's actual memory.[14]
Operating systems provide
common services, such as an
interface for accessing network
and disk devices. This enables an
application to be run on different
hardware without needing to be
rewritten.[15] Which services to
include in an operating system
varies greatly, and this functionality
 makes up the great majority of
code for most operating
systems.[16]

Types of operating
systems

Multicomputer operating
systems
Wit h mult iprocessors mult iple CPUs share memory. A mult icomput er or clust er
comput er has mult iple CPUs, each of which has it s own memory. Mult icomput ers
were developed because large mult iprocessors are difficult t o engineer and
prohibit ively expensive;[17] t hey are universal in cloud comput ing because of t he size
of t he machine needed.[18] The different CPUs oft en need t o send and receive
messages t o each ot her;[19] t o ensure good performance, t he operat ing syst ems for
t hese machines need t o minimize t his copying of packet s.[20] Newer syst ems are
oft en mult iqueue—separat ing groups of users int o separat e queues—t o reduce t he
need for packet copying and support more concurrent users.[21] Anot her t echnique is
remot e direct memory access, which enables each CPU t o access memory belonging
t o ot her CPUs.[19] Mult icomput er operat ing syst ems oft en support remot e procedure
calls where a CPU can call a procedure on anot her CPU,[22] or dist ribut ed shared
memory, in which t he operat ing syst em uses virt ualizat ion t o generat e shared memory
t hat does not physically exist .[23]
Distributed systems
A dist ribut ed syst em is a group of dist inct , net worked comput ers—each of which
might have t heir own operat ing syst em and file syst em. Unlike mult icomput ers, t hey
may be dispersed anywhere in t he world.[24] Middleware, an addit ional soft ware layer
bet ween t he operat ing syst em and applicat ions, is oft en used t o improve
consist ency. Alt hough it funct ions similarly t o an operat ing syst em, it is not a t rue
operat ing syst em.[25]

Embedded
Embedded operat ing syst ems are designed t o be used in embedded comput er
syst ems, whet her t hey are int ernet of t hings object s or not connect ed t o a net work.
Embedded syst ems include many household appliances. The dist inguishing fact or is
t hat t hey do not load user-inst alled soft ware. Consequent ly, t hey do not need
prot ect ion bet ween different applicat ions, enabling simpler designs. Very small
operat ing syst ems might run in less t han 10 kilobyt es,[26] and t he smallest are for
smart cards.[27] Examples include Embedded Linux, QNX, VxWorks, and t he ext ra-small
syst ems RIOT and TinyOS.[28]

Real-time
A real-t ime operat ing syst em is an operat ing syst em t hat guarant ees t o process
event s or dat a by or at a specific moment in t ime. Hard real-t ime syst ems require
exact t iming and are common in manufact uring, avionics, milit ary, and ot her similar
uses.[28] Wit h soft real-t ime syst ems, t he occasional missed event is accept able; t his
cat egory oft en includes audio or mult imedia syst ems, as well as smart phones.[28] In
order for hard real-t ime syst ems be sufficient ly exact in t heir t iming, oft en t hey are
just a library wit h no prot ect ion bet ween applicat ions, such as eCos.[28]

Hypervisor
A hypervisor is an operat ing syst em t hat runs a virt ual machine. The virt ual machine is
unaware t hat it is an applicat ion and operat es as if it had it s own hardware.[14][29]
Virt ual machines can be paused, saved, and resumed, making t hem useful for operat ing
syst ems research, development ,[30] and debugging.[31] They also enhance port abilit y
by enabling applicat ions t o be run on a comput er even if t hey are not compat ible wit h
t he base operat ing syst em.[14]

Library
A library operating system (libOS) is one in which t he services t hat a t ypical operat ing
syst em provides, such as net working, are provided in t he form of libraries and
composed wit h a single applicat ion and configurat ion code t o const ruct a unikernel:
[32] a specialized (only t he absolut e necessary pieces of code are ext ract ed from
libraries and bound t oget her [33]), single address space, machine image t hat can be
deployed t o cloud or embedded environment s.

The operat ing syst em code and applicat ion code are not execut ed in separat ed
prot ect ion domains (t here is only a single applicat ion running, at least concept ually, so
t here is no need t o prevent int erference bet ween applicat ions) and OS services are
accessed via simple library calls (pot ent ially inlining t hem based on compiler
t hresholds), wit hout t he usual overhead of cont ext swit ches, [34] in a way similarly t o
embedded and real-t ime OSes. Not e t hat t his overhead is not negligible: t o t he direct
cost of mode swit ching it 's necessary t o add t he indirect pollut ion of import ant
processor st ruct ures (like CPU caches, t he inst ruct ion pipeline, and so on) which
affect s bot h user-mode and kernel-mode performance [35]
History

IBM System/360 Model 50 operator's

console and CPU; the operator's
console is a terminal used by the
operating system to communicate
with the operator.

The first comput ers in t he lat e 1940s and 1950s were direct ly programmed eit her
wit h plugboards or wit h machine code input t ed on media such as punch cards, wit hout
programming languages or operat ing syst ems.[36] Aft er t he int roduct ion of t he
t ransist or in t he mid-1950s, mainframes began t o be built . These st ill needed
professional operat ors[36] who manually do what a modern operat ing syst em would do,
such as scheduling programs t o run,[37] but mainframes st ill had rudiment ary operat ing
syst ems such as Fort ran Monit or Syst em (FMS) and IBSYS.[38] In t he 1960s, IBM
int roduced t he first series of int ercompat ible comput ers (Syst em/360). All of t hem
ran t he same operat ing syst em—OS/360—which consist ed of millions of lines of
assembly language t hat had t housands of bugs. The OS/360 also was t he first popular
operat ing syst em t o support mult iprogramming, such t hat t he CPU could be put t o
use on one job while anot her was wait ing on input /out put (I/O). Holding mult iple jobs in
memory necessit at ed memory part it ioning and safeguards against one job accessing
t he memory allocat ed t o a different one.[39]
Around t he same t ime, t eleprint ers began t o be used as t erminals so mult iple users
could access t he comput er simult aneously. The operat ing syst em MULTICS was
int ended t o allow hundreds of users t o access a large comput er. Despit e it s limit ed
adopt ion, it can be considered t he precursor t o cloud comput ing. The UNIX operat ing
syst em originat ed as a development of MULTICS for a single user.[40] Because UNIX's
source code was available, it became t he basis of ot her, incompat ible operat ing
syst ems, of which t he most successful were AT&T's Syst em V and t he Universit y of
California's Berkeley Soft ware Dist ribut ion (BSD).[41] To increase compat ibilit y, t he
IEEE released t he POSIX st andard for operat ing syst em applicat ion programming
int erfaces (APIs), which is support ed by most UNIX syst ems. MINIX was a st ripped-
down version of UNIX, developed in 1987 for educat ional uses, t hat inspired t he
commercially available, free soft ware Linux. Since 2008, MINIX is used in cont rollers
of most Int el microchips, while Linux is widespread in dat a cent ers and Android
smart phones.[42]

Microcomputers

Command-line interface of the MS-

DOS operating system

Graphical user interface of a

Macintosh
The invent ion of large scale int egrat ion enabled t he product ion of personal
comput ers (init ially called microcomput ers) from around 1980.[43] For around five
years, t he CP/M (Cont rol Program for Microcomput ers) was t he most popular
operat ing syst em for microcomput ers.[44] Lat er, IBM bought t he DOS (Disk Operat ing
Syst em) from Microsoft . Aft er modificat ions request ed by IBM, t he result ing syst em
was called MS-DOS (MicroSoft Disk Operat ing Syst em) and was widely used on IBM
microcomput ers. Lat er versions increased t heir sophist icat ion, in part by borrowing
feat ures from UNIX.[44]

Apple's Macint osh was t he first popular comput er t o use a graphical user int erface
(GUI). The GUI proved much more user friendly t han t he t ext -only command-line
int erface earlier operat ing syst ems had used. Following t he success of Macint osh,
MS-DOS was updat ed wit h a GUI overlay called Windows. Windows lat er was
rewrit t en as a st and-alone operat ing syst em, borrowing so many feat ures from
anot her (VAX VMS) t hat a large legal set t lement was paid.[45] In t he t went y-first
cent ury, Windows cont inues t o be popular on personal comput ers but has less market
share of servers. UNIX operat ing syst ems, especially Linux, are t he most popular on
ent erprise syst ems and servers but are also used on mobile devices and many ot her
comput er syst ems.[46]

On mobile devices, Symbian OS was dominant at first , being usurped by BlackBerry OS

(int roduced 2002) and iOS for iPhones (from 2007). Lat er on, t he open-source Android
operat ing syst em (int roduced 2008), wit h a Linux kernel and a C library (Bionic) part ially
based on BSD code, became most popular.[47]

Components
The component s of an operat ing syst em are designed t o ensure t hat various part s of
a comput er funct ion cohesively. Wit h t he de fact o obsolet ion of DOS, all user
soft ware must int eract wit h t he operat ing syst em t o access hardware.
Kernel

A kernel connects the application

software to the hardware of a
computer.

The kernel is t he part of t he operat ing syst em t hat provides prot ect ion bet ween
different applicat ions and users. This prot ect ion is key t o improving reliabilit y by
keeping errors isolat ed t o one program, as well as securit y by limit ing t he power of
malicious soft ware and prot ect ing privat e dat a, and ensuring t hat one program cannot
monopolize t he comput er's resources.[48] Most operat ing syst ems have t wo modes of
operat ion:[49] in user mode, t he hardware checks t hat t he soft ware is only execut ing
legal inst ruct ions, whereas t he kernel has unrest rict ed powers and is not subject t o
t hese checks.[50] The kernel also manages memory for ot her processes and cont rols
access t o input /out put devices.[51]

Program execution
The operat ing syst em provides an int erface bet ween an applicat ion program and t he
comput er hardware, so t hat an applicat ion program can int eract wit h t he hardware
only by obeying rules and procedures programmed int o t he operat ing syst em. The
operat ing syst em is also a set of services which simplify development and execut ion
of applicat ion programs. Execut ing an applicat ion program t ypically involves t he
creat ion of a process by t he operat ing syst em kernel, which assigns memory space
and ot her resources, est ablishes a priorit y for t he process in mult i-t asking syst ems,
loads program binary code int o memory, and init iat es execut ion of t he applicat ion
program, which t hen int eract s wit h t he user and wit h hardware devices. However, in
li i h h i h
applicat ion wit hin t he same process, eit her as a subrout ine or in a separat e t hread, e.g.,
t he LINK and ATTACH facilit ies of OS/360 and successors.

Interrupts
An int errupt (also known as an abort , except ion, fault, signal,[52] or trap)[53] provides an
efficient way for most operat ing syst ems t o react t o t he environment . Int errupt s
cause t he cent ral processing unit (CPU) t o have a cont rol flow change away from t he
current ly running program t o an int errupt handler, also known as an int errupt service
rout ine (ISR).[54][55] An int errupt service rout ine may cause t he cent ral processing unit
(CPU) t o have a cont ext swit ch.[56][a] The det ails of how a comput er processes an
int errupt vary from archit ect ure t o archit ect ure, and t he det ails of how int errupt
service rout ines behave vary from operat ing syst em t o operat ing syst em.[57] However,
several int errupt funct ions are common.[57] The archit ect ure and operat ing syst em
must :[57]

1. transfer control to an interrupt

service routine.
2. save the state of the currently
running process.
3. restore the state after the
interrupt is serviced.
Software interrupt
A soft ware int errupt is a message t o a process t hat an event has occurred.[52] This
cont rast s wit h a hardware interrupt — which is a message t o t he cent ral processing
it (CPU) t h t th d [58] S ft i t t i il t h d
int errupt s — t here is a change away from t he current ly running process.[59] Similarly,
bot h hardware and soft ware int errupt s execut e an int errupt service rout ine.

Soft ware int errupt s may be normally occurring event s. It is expect ed t hat a t ime slice
will occur, so t he kernel will have t o perform a cont ext swit ch.[60] A comput er program
may set a t imer t o go off aft er a few seconds in case t oo much dat a causes an
algorit hm t o t ake t oo long.[61]

Soft ware int errupt s may be error condit ions, such as a malformed machine
inst ruct ion.[61] However, t he most common error condit ions are division by zero and
accessing an invalid memory address.[61]

Users can send messages t o t he kernel t o modify t he behavior of a current ly running

process.[61] For example, in t he command-line environment , pressing t he interrupt
character (usually Cont rol-C) might t erminat e t he current ly running process.[61]

To generat e software interrupts for x86 CPUs, t he INT assembly language inst ruct ion
is available.[62] The synt ax is INT X , where X is t he offset number (in hexadecimal
format ) t o t he int errupt vect or t able.

Signal
To generat e software interrupts in Unix-like operat ing syst ems, t he
kill(pid,signum) syst em call will send a signal t o anot her process.[63] pid is
t he process ident ifier of t he receiving process. signum is t he signal number (in
mnemonic format )[b] t o be sent . (The abrasive name of kill was chosen because
early implement at ions only t erminat ed t he process.)[64]

In Unix-like operat ing syst ems, signals inform processes of t he occurrence of

asynchronous event s.[63] To communicat e asynchronously, int errupt s are required.[65]
One reason a process needs t o asynchronously communicat e t o anot her process
solves a variat ion of t he classic reader/writ er problem.[66] The writ er receives a pipe
from t he shell for it s out put t o be sent t o t he reader's input st ream.[67] The
command-line synt ax is alpha | bravo . alpha will writ e t o t he pipe when it s
comput at ion is ready and t hen sleep in t he wait queue.[68] bravo will t hen be moved
t o t he ready queue and soon will read from it s input st ream.[69] The kernel will
generat e software interrupts t o coordinat e t he piping.[69]
Signals may be classified int o 7 cat egories.[63] The cat egories are:

1. when a process finishes

normally.
2. when a process has an error
exception.
3. when a process runs out of a
system resource.
4. when a process executes an
illegal instruction.
5. when a process sets an alarm
event.
6. when a process is aborted from
the keyboard.
7. when a process has a tracing
alert for debugging.
Hardware interrupt
Input /out put (I/O) devices are slower t han t he CPU. Therefore, it would slow down
t he comput er if t he CPU had t o wait for each I/O t o finish. Inst ead, a comput er may
implement int errupt s for I/O complet ion, avoiding t he need for polling or busy
wait ing.[70]

Some comput ers require an int errupt for each charact er or word, cost ing a significant
amount of CPU t ime. Direct memory access (DMA) is an archit ect ure feat ure t o allow
devices t o bypass t he CPU and access main memory direct ly.[71] (Separat e from t he
archit ect ure, a device may perform direct memory access[c] t o and from main memory
eit her direct ly or via a bus.)[72][d]

Input/output

Interrupt-driven I/O
When a comput er user t ypes a key on t he keyboard, t ypically t he charact er appears
immediat ely on t he screen. Likewise, when a user moves a mouse, t he cursor
immediat ely moves across t he screen. Each keyst roke and mouse movement
generat es an interrupt called Interrupt-driven I/O. An int errupt -driven I/O occurs when a
process causes an int errupt for every charact er[72] or word[73] t ransmit t ed.

Direct memory access

Devices such as hard disk drives, solid-st at e drives, and magnet ic t ape drives can
t ransfer dat a at a rat e high enough t hat int errupt ing t he CPU for every byt e or word
t ransferred, and having t he CPU t ransfer t he byt e or word bet ween t he device and
memory, would require t oo much CPU t ime. Dat a is, inst ead, t ransferred bet ween t he
device and memory independent ly of t he CPU by hardware such as a channel or a
direct memory access cont roller; an int errupt is delivered only when all t he dat a is
t ransferred [74]
If a comput er program execut es a syst em call t o perform a block I/O write operat ion,
t hen t he syst em call might execut e t he following inst ruct ions:

Set the contents of the CPU's

registers (including the program
counter) into the process control
block.[75]
Create an entry in the device-status
table.[76] The operating system
maintains this table to keep track of
which processes are waiting for
which devices. One field in the table
is the memory address of the
process control block.
Place all the characters to be sent
to the device into a memory
buffer.[65]
 Set the memory address of the
memory buffer to a predetermined
device register.[77]
Set the buffer size (an integer) to
another predetermined register.[77]
Execute the machine instruction to
begin the writing.
Perform a context switch to the
next process in the ready queue.
While t he writ ing t akes place, t he operat ing syst em will cont ext swit ch t o ot her
processes as normal. When t he device finishes writ ing, t he device will interrupt t he
current ly running process by asserting an int errupt request . The device will also place
an int eger ont o t he dat a bus.[78] Upon accept ing t he int errupt request , t he operat ing
syst em will:

Push the contents of the program

counter (a register) followed by the
status register onto the call
stack.[57]
 Push the contents of the other
registers onto the call stack.
(Alternatively, the contents of the
registers may be placed in a
system table.)[78]
Read the integer from the data bus.
The integer is an offset to the
interrupt vector table. The vector
table's instructions will then:
Access the device-status table.
Extract the process control
block.
Perform a context switch back to
the writing process.
When t he writ ing process has it s t ime slice expired, t he operat ing syst em will:[79]
 Pop from the call stack the
registers other than the status
register and program counter.
Pop from the call stack the status
register.
Pop from the call stack the address
of the next instruction, and set it
back into the program counter.
Wit h t he program count er now reset , t he int errupt ed process will resume it s t ime
slice.[57]

Memory management
Among ot her t hings, a mult iprogramming operat ing syst em kernel must be responsible
for managing all syst em memory which is current ly in use by t he programs. This
ensures t hat a program does not int erfere wit h memory already in use by anot her
program. Since programs t ime share, each program must have independent access t o
memory.

Cooperat ive memory management , used by many early operat ing syst ems, assumes
t hat all programs make volunt ary use of t he kernel's memory manager, and do not
exceed t heir allocat ed memory. This syst em of memory management is almost never
seen any more, since programs oft en cont ain bugs which can cause t hem t o exceed
t heir allocat ed memory. If a program fails, it may cause memory used by one or more
ot her programs t o be affect ed or overwrit t en. Malicious programs or viruses may
purposefully alt er anot her program's memory, or may affect t he operat ion of t he
operat ing syst em it self. Wit h cooperat ive memory management , it t akes only one
misbehaved program t o crash t he syst em.

Memory prot ect ion enables t he kernel t o limit a process' access t o t he comput er's
memory. Various met hods of memory prot ect ion exist , including memory
segment at ion and paging. All met hods require some level of hardware support (such
as t he 80286 MMU), which does not exist in all comput ers.

In bot h segment at ion and paging, cert ain prot ect ed mode regist ers specify t o t he
CPU what memory address it should allow a running program t o access. At t empt s t o
access ot her addresses t rigger an int errupt , which causes t he CPU t o re-ent er
supervisor mode, placing t he kernel in charge. This is called a segment at ion violat ion
or Seg-V for short , and since it is bot h difficult t o assign a meaningful result t o such an
operat ion, and because it is usually a sign of a misbehaving program, t he kernel
generally resort s t o t erminat ing t he offending program, and report s t he error.

Windows versions 3.1 t hrough ME had some level of memory prot ect ion, but programs
could easily circumvent t he need t o use it . A general prot ect ion fault would be
produced, indicat ing a segment at ion violat ion had occurred; however, t he syst em
would oft en crash anyway.

Virtual memory
 Many operating systems can "trick"
programs into using memory scattered
around the hard disk and RAM as if it is one
continuous chunk of memory, called virtual
memory.

The use of virt ual memory addressing (such as paging or segment at ion) means t hat
t he kernel can choose what memory each program may use at any given t ime, allowing
t he operat ing syst em t o use t he same memory locat ions for mult iple t asks.

If a program t ries t o access memory t hat is not accessible [e] memory, but
nonet heless has been allocat ed t o it , t he kernel is int errupt ed . This kind of int errupt is
t ypically a page fault .

When t he kernel det ect s a page fault it generally adjust s t he virt ual memory range of
t he program which t riggered it , grant ing it access t o t he memory request ed. This
gives t he kernel discret ionary power over where a part icular applicat ion's memory is
st ored, or even whet her or not it has been allocat ed yet .

In modern operat ing syst ems, memory which is accessed less frequent ly can be
t emporarily st ored on a disk or ot her media t o make t hat space available for use by
ot her programs. This is called swapping, as an area of memory can be used by mult iple
programs, and what t hat memory area cont ains can be swapped or exchanged on
demand.
Virt ual memory provides t he programmer or t he user wit h t he percept ion t hat t here is
a much larger amount of RAM in t he comput er t han is really t here.[80]

Concurrency
Concurrency refers t o t he operat ing syst em's abilit y t o carry out mult iple t asks
simult aneously.[81] Virt ually all modern operat ing syst ems support concurrency.[82]

Threads enable split t ing a process' work int o mult iple part s t hat can run
simult aneously.[83] The number of t hreads is not limit ed by t he number of processors
available. If t here are more t hreads t han processors, t he operat ing syst em kernel
schedules, suspends, and resumes t hreads, cont rolling when each t hread runs and how
much CPU t ime it receives.[84] During a cont ext swit ch a running t hread is suspended,
it s st at e is saved int o t he t hread cont rol block and st ack, and t he st at e of t he new
t hread is loaded in.[85] Hist orically, on many syst ems a t hread could run unt il it
relinquished cont rol (cooperat ive mult it asking). Because t his model can allow a single
t hread t o monopolize t he processor, most operat ing syst ems now can int errupt a
t hread (preempt ive mult it asking).[86]

Threads have t heir own t hread ID, program count er (PC), a regist er set , and a st ack,
but share code, heap dat a, and ot her resources wit h ot her t hreads of t he same
process.[87][88] Thus, t here is less overhead t o creat e a t hread t han a new process.[89]
On single-CPU syst ems, concurrency is swit ching bet ween processes. Many
comput ers have mult iple CPUs.[90] Parallelism wit h mult iple t hreads running on
different CPUs can speed up a program, depending on how much of it can be
execut ed concurrent ly.[91]

File system
 File systems allow users and
programs to organize and sort files
on a computer, often through the use
of directories (or folders).

Permanent st orage devices used in t went y-first cent ury comput ers, unlike volat ile
dynamic random-access memory (DRAM), are st ill accessible aft er a crash or power
failure. Permanent (non-volat ile) st orage is much cheaper per byt e, but t akes several
orders of magnit ude longer t o access, read, and writ e.[92][93] The t wo main
t echnologies are a hard drive consist ing of magnet ic disks, and flash memory (a solid-
st at e drive t hat st ores dat a in elect rical circuit s). The lat t er is more expensive but
fast er and more durable.[94][95]

File syst ems are an abst ract ion used by t he operat ing syst em t o simplify access t o
permanent st orage. They provide human-readable filenames and ot her met adat a,
increase performance via amort izat ion of accesses, prevent mult iple t hreads from
accessing t he same sect ion of memory, and include checksums t o ident ify
corrupt ion.[96] File syst ems are composed of files (named collect ions of dat a, of an
arbit rary size) and direct ories (also called folders) t hat list human-readable filenames
and ot her direct ories.[97] An absolut e file pat h begins at t he root direct ory and list s
subdirect ories divided by punct uat ion, while a relat ive pat h defines t he locat ion of a
file from a direct ory.[98][99]

Syst em calls (which are somet imes wrapped by libraries) enable applicat ions t o
creat e, delet e, open, and close files, as well as link, read, and writ e t o t hem. All t hese
operat ions are carried out by t he operat ing syst em on behalf of t he applicat ion.[100]
The operat ing syst em's effort s t o reduce lat ency include st oring recent ly request ed
blocks of memory in a cache and prefet ching dat a t hat t he applicat ion has not asked
for, but might need next .[101] Device drivers are soft ware specific t o each
input /out put (I/O) device t hat enables t he operat ing syst em t o work wit hout
modificat ion over different hardware.[102][103]
Anot her component of file syst ems is a dict ionary t hat maps a file's name and
met adat a t o t he dat a block where it s cont ent s are st ored.[104] Most file syst ems use
direct ories t o convert file names t o file numbers. To find t he block number, t he
operat ing syst em uses an index (oft en implement ed as a t ree).[105] Separat ely, t here
is a free space map t o t rack free blocks, commonly implement ed as a bit map.[105]
Alt hough any free block can be used t o st ore a new file, many operat ing syst ems t ry
t o group t oget her files in t he same direct ory t o maximize performance, or periodically
reorganize files t o reduce fragment at ion.[106]

Maint aining dat a reliabilit y in t he face of a comput er crash or hardware failure is

anot her concern.[107] File writ ing prot ocols are designed wit h at omic operat ions so as
not t o leave permanent st orage in a part ially writ t en, inconsist ent st at e in t he event
of a crash at any point during writ ing.[108] Dat a corrupt ion is addressed by redundant
st orage (for example, RAID—redundant array of inexpensive disks)[109][110] and
checksums t o det ect when dat a has been corrupt ed. Wit h mult iple layers of
checksums and backups of a file, a syst em can recover from mult iple hardware
failures. Background processes are oft en used t o det ect and recover from dat a
corrupt ion.[110]

Security
Securit y means prot ect ing users from ot her users of t he same comput er, as well as
from t hose who seeking remot e access t o it over a net work.[111] Operat ing syst ems
securit y rest s on achieving t he CIA t riad: confident ialit y (unaut horized users cannot
access dat a), int egrit y (unaut horized users cannot modify dat a), and availabilit y
(ensuring t hat t he syst em remains available t o aut horized users, even in t he event of a
denial of service at t ack).[112] As wit h ot her comput er syst ems, isolat ing securit y
domains—in t he case of operat ing syst ems, t he kernel, processes, and virt ual
machines—is key t o achieving securit y.[113] Ot her ways t o increase securit y include
simplicit y t o minimize t he at t ack surface, locking access t o resources by default ,
checking all request s for aut horizat ion, principle of least aut horit y (grant ing t he
minimum privilege essent ial for performing a t ask), privilege separat ion, and reducing
shared dat a.[114]
Some operat ing syst em designs are more secure t han ot hers. Those wit h no isolat ion
bet ween t he kernel and applicat ions are least secure, while t hose wit h a monolit hic
kernel like most general-purpose operat ing syst ems are st ill vulnerable if any part of
t he kernel is compromised. A more secure design feat ures microkernels t hat separat e
t he kernel's privileges int o many separat e securit y domains and reduce t he
consequences of a single kernel breach.[115] Unikernels are anot her approach t hat
improves securit y by minimizing t he kernel and separat ing out ot her operat ing syst ems
funct ionalit y by applicat ion.[115]

Most operat ing syst ems are writ t en in C or C++, which creat e pot ent ial vulnerabilit ies
for exploit at ion. Despit e at t empt s t o prot ect against t hem, vulnerabilit ies are caused
by buffer overflow at t acks, which are enabled by t he lack of bounds checking.[116]
Hardware vulnerabilit ies, some of t hem caused by CPU opt imizat ions, can also be
used t o compromise t he operat ing syst em.[117] There are known inst ances of
operat ing syst em programmers deliberat ely implant ing vulnerabilit ies, such as back
doors.[118]

Operat ing syst ems securit y is hampered by t heir increasing complexit y and t he
result ing inevit abilit y of bugs.[119] Because formal verificat ion of operat ing syst ems
may not be feasible, developers use operat ing syst em hardening t o reduce
vulnerabilit ies,[120] e.g. address space layout randomizat ion, cont rol-flow int egrit y,[121]
access rest rict ions,[122] and ot her t echniques.[123] There are no rest rict ions on who
can cont ribut e code t o open source operat ing syst ems; such operat ing syst ems have
t ransparent change hist ories and dist ribut ed governance st ruct ures.[124] Open source
developers st rive t o work collaborat ively t o find and eliminat e securit y vulnerabilit ies,
using code review and t ype checking t o expunge malicious code.[125][126] Andrew S.
Tanenbaum advises releasing t he source code of all operat ing syst ems, arguing t hat it
prevent s developers from placing t rust in secrecy and t hus relying on t he unreliable
pract ice of securit y by obscurit y.[127]

User interface
A user int erface (UI) is essent ial t o support human int eract ion wit h a comput er. The
t wo most common user int erface t ypes for any comput er are
 command-line interface, where
computer commands are typed,
line-by-line,
graphical user interface (GUI) using
a visual environment, most
commonly a combination of the
window, icon, menu, and pointer
elements, also known as WIMP.
For personal comput ers, including smart phones and t ablet comput ers, and for
workst at ions, user input is t ypically from a combinat ion of keyboard, mouse, and
t rackpad or t ouchscreen, all of which are connect ed t o t he operat ing syst em wit h
specialized soft ware.[128] Personal comput er users who are not soft ware developers
or coders oft en prefer GUIs for bot h input and out put ; GUIs are support ed by most
personal comput ers.[129] The soft ware t o support GUIs is more complex t han a
command line for input and plain t ext out put . Plain t ext out put is oft en preferred by
programmers, and is easy t o support .[130]

Operating system
development as a hobby
A hobby operat ing syst em may be classified as one whose code has not been direct ly
derived from an exist ing operat ing syst em, and has few users and act ive
developers.[131]

In some cases, hobby development is in support of a "homebrew" comput ing device,

for example, a simple single-board comput er powered by a 6502 microprocessor. Or,
development may be for an archit ect ure already in widespread use. Operat ing syst em
development may come from ent irely new concept s, or may commence by modeling
an exist ing operat ing syst em. In eit her case, t he hobbyist is her/his own developer, or
may int eract wit h a small and somet imes unst ruct ured group of individuals who have
like int erest s.

Examples of hobby operat ing syst ems include Syllable and TempleOS.

Diversity of operating
systems and portability
If an applicat ion is writ t en for use on a specific operat ing syst em, and is port ed t o
anot her OS, t he funct ionalit y required by t hat applicat ion may be implement ed
different ly by t hat OS (t he names of funct ions, meaning of argument s, et c.) requiring
t he applicat ion t o be adapt ed, changed, or ot herwise maint ained.

This cost in support ing operat ing syst ems diversit y can be avoided by inst ead writ ing
applicat ions against soft ware plat forms such as Java or Qt . These abst ract ions have
already borne t he cost of adapt at ion t o specific operat ing syst ems and t heir syst em
libraries.

Anot her approach is for operat ing syst em vendors t o adopt st andards. For example,
POSIX and OS abst ract ion layers provide commonalit ies t hat reduce port ing cost s.

Popular operating
systems
As of Sept ember 2024, Android is t he most popular operat ing syst em wit h a 46%
market share, followed by Microsoft Windows at 26%, iOS and iPadOS at 18%, macOS
at 5%, and Linux at 1%. Android, iOS, and iPadOS are mobile operat ing syst ems, while
Windows, macOS, and Linux are deskt op operat ing syst ems.[132]

Linux

Layers of a Linux system

Linux is a free soft ware dist ribut ed under t he GNU General Public License (GPL), which
means t hat all of it s derivat ives are legally required t o release t heir source code.[133]
Linux was designed by programmers for t heir own use, t hus emphasizing simplicit y and
consist ency, wit h a small number of basic element s t hat can be combined in nearly
unlimit ed ways, and avoiding redundancy.[134]

It s design is similar t o ot her UNIX syst ems not using a microkernel.[135] It is writ t en in
C[136] and uses UNIX Syst em V synt ax, but also support s BSD synt ax. Linux support s
st andard UNIX net working feat ures, as well as t he full suit e of UNIX t ools, while
support ing mult iple users and employing preempt ive mult it asking. Init ially of a
minimalist design, Linux is a flexible syst em t hat can work in under 16 MB of RAM, but
st ill is used on large mult iprocessor syst ems.[135] Similar t o ot her UNIX syst ems, Linux
dist ribut ions are composed of a kernel, syst em libraries, and syst em ut ilit ies.[137] Linux
has a graphical user int erface (GUI) wit h a deskt op, folder and file icons, as well as t he
opt ion t o access t he operat ing syst em via a command line.[138]

Android is a part ially open-source operat ing syst em closely based on Linux and has
smart phones and, t o a lesser ext ent , embedded syst ems needing a GUI, such as
"smart wat ches, aut omot ive dashboards, airplane seat backs, medical devices, and
home appliances".[139] Unlike Linux, much of Android is writ t en in Java and uses object -
orient ed design.[140]

Microsoft Windows

Security descriptor for a file that is read-only by

default, specified no access for Elvis, read/write
access for Cathy, and full access for Ida, the
owner of the file[141]

Windows is a propriet ary operat ing syst em t hat is widely used on deskt op comput ers,
lapt ops, t ablet s, phones, workst at ions, ent erprise servers, and Xbox consoles.[142] The
operat ing syst em was designed for "securit y, reliabilit y, compat ibilit y, high
performance, ext ensibilit y, port abilit y, and int ernat ional support "—lat er on, energy
efficiency and support for dynamic devices also became priorit ies.[143]

Windows Execut ive works via kernel-mode object s for import ant dat a st ruct ures like
processes, t hreads, and sect ions (memory object s, for example files).[144] The
operat ing syst em support s demand paging of virt ual memory, which speeds up I/O for
many applicat ions. I/O device drivers use t he Windows Driver Model.[144] The NTFS
file syst em has a mast er t able and each file is represent ed as a record wit h
met adat a.[145] The scheduling includes preempt ive mult it asking.[146] Windows has
many securit y feat ures;[147] especially import ant are t he use of access-cont rol list s
given a securit y descript or. Lat er releases have added even more securit y
feat ures.[145]

See also

Comparison of operating systems

DBOS
Interruptible operating system
List of operating systems
List of pioneers in computer
science
Glossary of operating systems
terms
Microcontroller
Network operating system
Object-oriented operating system
 Operating System Projects
System Commander
System image
Timeline of operating systems

Notes

a. Modern CPUs provide

instructions (e.g. SYSENTER) to
invoke selected kernel services
without an interrupts. Visit
https://wiki.osdev.org/SYSENTE
R for more information.
b. Examples include SIGINT,
SIGSEGV, and SIGBUS.
c. often in the form of a DMA chip
for smaller systems and I/O
channels for larger systems
d. Modern motherboards have a
DMA controller. Additionally, a
device may also have one. Visit
SCSI RDMA Protocol.
e. There are several reasons that
the memory might be
inaccessible
The address might be out of
range
The address might refer to a
page or segment that has
been moved to a backing
store
 The address might refer to
memory that has restricted
access due to, e.g., key, ring.

References

1. Stallings (2005). Operating

Systems, Internals and Design
Principles. Pearson: Prentice Hall.
p. 6.
2. Dhotre, I.A. (2009). Operating
Systems. Technical Publications.
p. 1.
3. "Operating System Market Share
Worldwide" (https://gs.statcounte
r.com/os-market-share) .
StatCounter Global Stats.
Retrieved 20 December 2024.
4. "VII. Special-Purpose Systems -
Operating System Concepts,
Seventh Edition [Book]" (https://w
ww.oreilly.com/library/view/opera
ting-system-concepts/97804716
94663/pt07.html) .
www.oreilly.com. Archived (http
s://web.archive.org/web/202106
13190049/https://www.oreilly.co
m/library/view/operating-system-
concepts/9780471694663/pt07.
html) from the original on 13
June 2021. Retrieved 8 February
2021.
5. "Special-Purpose Operating
Systems - RWTH AACHEN
UNIVERSITY Institute for
Automation of Complex Power
Systems - English" (https://www.a
cs.eonerc.rwth-aachen.de/cms/E-
ON-ERC-ACS/Studium/Lehrveran
staltungen/~lrhs/Spezial-Betriebs
systeme/?lidx=1) .
www.acs.eonerc.rwth-aachen.de.
Archived (https://web.archive.or
g/web/20210614034001/https://
www.acs.eonerc.rwth-aachen.de/
cms/E-ON-ERC-ACS/Studium/Leh
rveranstaltungen/~lrhs/Spezial-B
etriebssysteme/?lidx=1) from
 the original on 14 June 2021.
Retrieved 8 February 2021.
6. Tanenbaum & Bos 2023, p. 4.
7. Anderson & Dahlin 2014, p. 6.
8. Silberschatz et al. 2018, p. 6.
9. Anderson & Dahlin 2014, p. 7.
10. Anderson & Dahlin 2014, pp. 9–
10.
11. Tanenbaum & Bos 2023, pp. 6–7.
12. Anderson & Dahlin 2014, p. 10.
13. Tanenbaum & Bos 2023, p. 5.
14. Anderson & Dahlin 2014, p. 11.
15. Anderson & Dahlin 2014, pp. 7, 9,
13.
16. Anderson & Dahlin 2014, pp. 12–
13.
17. Tanenbaum & Bos 2023, p. 557.
18. Tanenbaum & Bos 2023, p. 558.
19. Tanenbaum & Bos 2023, p. 565.
20. Tanenbaum & Bos 2023, p. 562.
21. Tanenbaum & Bos 2023, p. 563.
22. Tanenbaum & Bos 2023, p. 569.
23. Tanenbaum & Bos 2023, p. 571.
24. Tanenbaum & Bos 2023, p. 579.
25. Tanenbaum & Bos 2023, p. 581.
26. Tanenbaum & Bos 2023, pp. 37–
38.
27. Tanenbaum & Bos 2023, p. 39.
28. Tanenbaum & Bos 2023, p. 38.
29. Silberschatz et al. 2018, pp. 701.
30. Silberschatz et al. 2018, pp. 705.
31. Anderson & Dahlin 2014, p. 12.
32. Madhavapeddy, Anil; Scott, David
J (November 2013). "Unikernels:
Rise of the Virtual Library
Operating System: What if all the
software layers in a virtual
appliance were compiled within
the same safe, high-level
language framework?" (https://do
i.org/10.1145/2557963.256662
8) . Queue. Vol. 11, no. 11. New
York, NY, USA: ACM. pp. 30–44.
doi:10.1145/2557963.2566628
(https://doi.org/10.1145%2F2557
963.2566628) . ISSN 1542-7730
(https://search.worldcat.org/issn/
 1542-7730) . Retrieved 7 August
2024.
33. "Build Process - Unikraft" (https://
unikraft.org/docs/concepts/build-
process) . Archived (https://web.
archive.org/web/2024042218373
4/https://unikraft.org/docs/conce
pts/build-process) from the
original on 22 April 2024.
Retrieved 8 August 2024.
34. "Leave your OS at home: the rise
of library operating systems" (http
s://www.sigarch.org/leave-your-o
s-at-home-the-rise-of-library-oper
ating-systems/) . ACM SIGARCH.
14 September 2017. Archived (htt
ps://web.archive.org/web/20240
301072916/https://www.sigarch.
org/leave-your-os-at-home-the-ris
e-of-library-operating-systems/)
from the original on 1 March
2024. Retrieved 7 August 2024.
35. Soares, Livio Baldini; Stumm,
Michael (4 October 2010).
FlexSC: Flexible System Call
Scheduling with Exception-Less
System Calls (https://www.useni
x.org/conference/osdi10/flexsc-fl
exible-system-call-scheduling-exc
eption-less-system-calls) . OSDI
'10, 9th USENIX Symposium on
Operating System Design and
Implementation (https://www.use
nix.org/legacy/events/osdi10/) .
USENIX. Retrieved 9 August
2024. p. 2: "Synchronous
implementation of system calls
negatively impacts the
performance of system intensive
workloads, both in terms of the
direct costs of mode switching
and, more interestingly, in terms
of the indirect pollution of
important processor structures
which affects both user-mode
and kernel-mode performance. A
motivating example that
quantifies the impact of system
call pollution on application
performance can be seen in
Figure 1. It depicts the user-mode
instructions per cycles (kernel
cycles and instructions are
ignored) of one of the SPEC CPU
 2006 benchmarks (Xalan)
immediately before and after a
pwrite system call. There is a
significant drop in instructions per
cycle (IPC) due to the system call,
and it takes up to 14,000 cycles
of execution before the IPC of
this application returns to its
previous level. As we will show,
this performance degradation is
mainly due to interference caused
by the kernel on key processor
structures."
36. Tanenbaum & Bos 2023, p. 8.
37. Arpaci-Dusseau, Remzi; Arpaci-
Dusseau, Andrea (2015).
Operating Systems: Three Easy
Pieces (http://pages.cs.wisc.edu/
~remzi/OSTEP/) . Archived (http
s://web.archive.org/web/201607
25012948/http://pages.cs.wisc.e
du/~remzi/OSTEP/) from the
original on 25 July 2016.
Retrieved 25 July 2016.
38. Tanenbaum & Bos 2023, p. 10.
39. Tanenbaum & Bos 2023, pp. 11–
12.
40. Tanenbaum & Bos 2023, pp. 13–
14.
41. Tanenbaum & Bos 2023, pp. 14–
15.
42. Tanenbaum & Bos 2023, p. 15.
43. Tanenbaum & Bos 2023, pp. 15–
16.
44. Tanenbaum & Bos 2023, p. 16.
45. Tanenbaum & Bos 2023, p. 17.
46. Tanenbaum & Bos 2023, p. 18.
47. Tanenbaum & Bos 2023, pp. 19–
20.
48. Anderson & Dahlin 2014, pp. 39–
40.
49. Tanenbaum & Bos 2023, p. 2.
50. Anderson & Dahlin 2014, pp. 41,
45.
51. Anderson & Dahlin 2014, pp. 52–
53.
52. Kerrisk, Michael (2010). The Linux
Programming Interface. No
Starch Press. p. 388. ISBN 978-1-
59327-220-3. "A signal is a
notification to a process that an
event has occurred. Signals are
sometimes described as
software interrupts."
53. Hyde, Randall (1996). "Chapter
Seventeen: Interrupts, Traps and
Exceptions (Part 1)" (https://www.
plantation-productions.com/Web
ster/www.artofasm.com/DOS/ch
17/CH17-1.html#HEADING1-0) .
The Art Of Assembly Language
Programming. No Starch Press.
Archived (https://web.archive.or
g/web/20211222205623/https://
www.plantation-productions.com/
Webster/www.artofasm.com/DO
S/ch17/CH17-1.html#HEADING1-
0) from the original on 22
December 2021. Retrieved
22 December 2021. "The concept
of an interrupt is something that
has expanded in scope over the
years. The 80x86 family has only
added to the confusion
surrounding interrupts by
introducing the int (software
interrupt) instruction. Indeed,
different manufacturers have
used terms like exceptions, faults,
aborts, traps and interrupts to
describe the phenomena this
chapter discusses. Unfortunately
there is no clear consensus as to
the exact meaning of these
terms. Different authors adopt
different terms to their own use."
54. Tanenbaum, Andrew S. (1990).
Structured Computer
Organization, Third Edition (http
s://archive.org/details/structured
comput00tane/page/308) .
Prentice Hall. p. 308 (https://archi
ve.org/details/structuredcomput0
0tane/page/308) . ISBN 978-0-
13-854662-5. "Like the trap, the
interrupt stops the running
program and transfers control to
an interrupt handler, which
performs some appropriate
action. When finished, the
interrupt handler returns control
to the interrupted program."
55. Silberschatz, Abraham (1994).
Operating System Concepts,
Fourth Edition. Addison-Wesley.
p. 32. ISBN 978-0-201-50480-4.
"When an interrupt (or trap)
occurs, the hardware transfers
control to the operating system.
First, the operating system
preserves the state of the CPU by
storing registers and the program
counter. Then, it determines
which type of interrupt has
occurred. For each type of
interrupt, separate segments of
code in the operating system
 determine what action should be
taken."
56. Silberschatz, Abraham (1994).
Operating System Concepts,
Fourth Edition. Addison-Wesley.
p. 105. ISBN 978-0-201-50480-4.
"Switching the CPU to another
process requires saving the state
of the old process and loading
the saved state for the new
process. This task is known as a
context switch."
57. Silberschatz, Abraham (1994).
Operating System Concepts,
Fourth Edition. Addison-Wesley.
p. 31. ISBN 978-0-201-50480-4.
58. Silberschatz, Abraham (1994).
Operating System Concepts,
Fourth Edition. Addison-Wesley.
p. 30. ISBN 978-0-201-50480-4.
"Hardware may trigger an
interrupt at any time by sending a
signal to the CPU, usually by way
of the system bus."
59. Kerrisk, Michael (2010). The Linux
Programming Interface. No
Starch Press. p. 388. ISBN 978-1-
59327-220-3. "Signals are
analogous to hardware interrupts
in that they interrupt the normal
flow of execution of a program; in
most cases, it is not possible to
predict exactly when a signal will
arrive."
60. Kerrisk, Michael (2010). The Linux
Programming Interface. No
Starch Press. p. 388. ISBN 978-1-
59327-220-3. "Among the types
of events that cause the kernel to
generate a signal for a process
are the following: A software
event occurred. For example, ...
the process's CPU time limit was
exceeded[.]"
61. Kerrisk, Michael (2010). The Linux
Programming Interface. No
Starch Press. p. 388. ISBN 978-1-
59327-220-3.
62. "Intel® 64 and IA-32
Architectures Software
Developer's Manual" (https://ww
w.intel.com/content/dam/www/p
ublic/us/en/documents/manuals/
64-ia-32-architectures-software-d
eveloper-instruction-set-reference
-manual-325383.pdf) (PDF). Intel
Corporation. September 2016.
p. 610. Archived (https://web.arch
ive.org/web/20220323231921/ht
tps://www.intel.com/content/da
m/www/public/us/en/document
s/manuals/64-ia-32-architectures
-software-developer-instruction-s
et-reference-manual-325383.pd
 f) (PDF) from the original on 23
March 2022. Retrieved 5 May
2022.
63. Bach, Maurice J. (1986). The
Design of the UNIX Operating
System. Prentice-Hall. p. 200.
ISBN 0-13-201799-7.
64. Kerrisk, Michael (2010). The Linux
Programming Interface. No
Starch Press. p. 400. ISBN 978-1-
59327-220-3.
65. Tanenbaum, Andrew S. (1990).
Structured Computer
Organization, Third Edition (http
s://archive.org/details/structured
comput00tane/page/308) .
Prentice Hall. p. 308 (https://archi
ve.org/details/structuredcomput0
0tane/page/308) . ISBN 978-0-
13-854662-5.
66. Silberschatz, Abraham (1994).
Operating System Concepts,
Fourth Edition. Addison-Wesley.
p. 182. ISBN 978-0-201-50480-4.
67. Haviland, Keith; Salama, Ben
(1987). UNIX System
Programming. Addison-Wesley
Publishing Company. p. 153.
ISBN 0-201-12919-1.
68. Haviland, Keith; Salama, Ben
(1987). UNIX System
Programming. Addison-Wesley
Publishing Company. p. 148.
ISBN 0-201-12919-1.
69. Haviland, Keith; Salama, Ben
(1987). UNIX System
Programming. Addison-Wesley
Publishing Company. p. 149.
ISBN 0-201-12919-1.
70. Tanenbaum, Andrew S. (1990).
Structured Computer
Organization, Third Edition (http
s://archive.org/details/structured
comput00tane/page/292) .
Prentice Hall. p. 292 (https://archi
ve.org/details/structuredcomput0
0tane/page/292) . ISBN 978-0-
13-854662-5.
71. IBM (September 1968), "Main
Storage" (http://bitsavers.org/pd
f/ibm/360/princOps/A22-6821-7_
360PrincOpsDec67.pdf#page=8)
(PDF), IBM System/360 Principles
of Operation (http://bitsavers.org/
pdf/ibm/360/princOps/A22-6821
-7_360PrincOpsDec67.pdf)
(PDF), Eighth Edition, p. 7,
archived (https://web.archive.org/
web/20220319083255/http://bits
avers.org/pdf/ibm/360/princOps/
A22-6821-7_360PrincOpsDec67.
pdf) (PDF) from the original on
19 March 2022, retrieved 13 April
2022
72. Tanenbaum, Andrew S. (1990).
Structured Computer
Organization, Third Edition (http
s://archive.org/details/structured
comput00tane/page/294) .
Prentice Hall. p. 294 (https://archi
ve.org/details/structuredcomput0
0tane/page/294) . ISBN 978-0-
13-854662-5.
73. "Program Interrupt Controller
(PIC)" (http://bitsavers.org/pdf/de
c/pdp7/F-75_PDP-7userHbk_Jun
65.pdf#page=62) (PDF). Users
Handbook - PDP-7 (http://bitsaver
s.org/pdf/dec/pdp7/F-75_PDP-7u
serHbk_Jun65.pdf) (PDF). Digital
Equipment Corporation. 1965.
pp. 48 (http://bitsavers.org/pdf/d
ec/pdp7/F-75_PDP-7userHbk_Ju
n65.pdf#page=63) . F-75.
Archived (https://web.archive.or
g/web/20220510164742/http://b
itsavers.org/pdf/dec/pdp7/F-75_
PDP-7userHbk_Jun65.pdf) (PDF)
 from the original on 10 May 2022.
Retrieved 20 April 2022.
74. PDP-1 Input-Output Systems
Manual (http://bitsavers.org/pdf/
dec/pdp1/F25_PDP1_IO.pdf)
(PDF). Digital Equipment
Corporation. pp. 19–20. Archived
(https://web.archive.org/web/201
90125050839/http://bitsavers.or
g/pdf/dec/pdp1/F25_PDP1_IO.p
df) (PDF) from the original on 25
January 2019. Retrieved
16 August 2022.
75. Silberschatz, Abraham (1994).
Operating System Concepts,
Fourth Edition. Addison-Wesley.
p. 32. ISBN 978-0-201-50480-4.
76. Silberschatz, Abraham (1994).
Operating System Concepts,
Fourth Edition. Addison-Wesley.
p. 34. ISBN 978-0-201-50480-4.
77. Tanenbaum, Andrew S. (1990).
Structured Computer
Organization, Third Edition (http
s://archive.org/details/structured
comput00tane/page/295) .
Prentice Hall. p. 295 (https://archi
ve.org/details/structuredcomput0
0tane/page/295) . ISBN 978-0-
13-854662-5.
78. Tanenbaum, Andrew S. (1990).
Structured Computer
Organization, Third Edition (http
s://archive.org/details/structured
comput00tane/page/309) .
Prentice Hall. p. 309 (https://archi
ve.org/details/structuredcomput0
0tane/page/309) . ISBN 978-0-
13-854662-5.
79. Tanenbaum, Andrew S. (1990).
Structured Computer
Organization, Third Edition (http
s://archive.org/details/structured
comput00tane/page/310) .
Prentice Hall. p. 310 (https://archi
ve.org/details/structuredcomput0
0tane/page/310) . ISBN 978-0-
13-854662-5.
80. Stallings, William (2008).
Computer Organization &
Architecture. New Delhi: Prentice-
Hall of India Private Limited.
p. 267. ISBN 978-81-203-2962-1.
81. Anderson & Dahlin 2014, p. 129.
82. Silberschatz et al. 2018, p. 159.
83. Anderson & Dahlin 2014, p. 130.
84. Anderson & Dahlin 2014, p. 131.
85. Anderson & Dahlin 2014, pp. 157,
159.
86. Anderson & Dahlin 2014, p. 139.
87. Silberschatz et al. 2018, p. 160.
88. Anderson & Dahlin 2014, p. 183.
89. Silberschatz et al. 2018, p. 162.
90. Silberschatz et al. 2018, pp. 162–
163.
91. Silberschatz et al. 2018, p. 164.
92. Anderson & Dahlin 2014, pp. 492,
517.
 93. Tanenbaum & Bos 2023,
pp. 259–260.
94. Anderson & Dahlin 2014, pp. 517,
530.
95. Tanenbaum & Bos 2023, p. 260.
96. Anderson & Dahlin 2014,
pp. 492–493.
97. Anderson & Dahlin 2014, p. 496.
98. Anderson & Dahlin 2014,
pp. 496–497.
99. Tanenbaum & Bos 2023,
pp. 274–275.
100. Anderson & Dahlin 2014,
pp. 502–504.
101. Anderson & Dahlin 2014, p. 507.
102. Anderson & Dahlin 2014, p. 508.
103. Tanenbaum & Bos 2023, p. 359.
104. Anderson & Dahlin 2014, p. 545.
105. Anderson & Dahlin 2014, p. 546.
106. Anderson & Dahlin 2014, p. 547.
107. Anderson & Dahlin 2014, pp. 589,
591.
108. Anderson & Dahlin 2014,
pp. 591–592.
109. Tanenbaum & Bos 2023,
pp. 385–386.
110. Anderson & Dahlin 2014, p. 592.
111. Tanenbaum & Bos 2023,
pp. 605–606.
112. Tanenbaum & Bos 2023, p. 608.
113. Tanenbaum & Bos 2023, p. 609.
114. Tanenbaum & Bos 2023,
pp. 609–610.
115. Tanenbaum & Bos 2023, p. 612.
116. Tanenbaum & Bos 2023, pp. 648,
657.
117. Tanenbaum & Bos 2023,
pp. 668–669, 674.
118. Tanenbaum & Bos 2023,
pp. 679–680.
119. Tanenbaum & Bos 2023, pp. 605,
617–618.
120. Tanenbaum & Bos 2023,
pp. 681–682.
121. Tanenbaum & Bos 2023, p. 683.
122. Tanenbaum & Bos 2023, p. 685.
123. Tanenbaum & Bos 2023, p. 689.
124. Richet & Bouaynaya 2023, p. 92.
125. Richet & Bouaynaya 2023,
pp. 92–93.
126. Berntsso, Strandén & Warg 2017,
pp. 130–131.
127. Tanenbaum & Bos 2023, p. 611.
128. Tanenbaum & Bos 2023, pp. 396,
402.
129. Tanenbaum & Bos 2023, pp. 395,
408.
130. Tanenbaum & Bos 2023, p. 402.
131. Holwerda, Thom (20 December
2009). "My OS Is Less Hobby
than Yours" (https://www.osnews.
com/story/22638/my-os-is-less-h
obby-than-yours/) . OS News.
Retrieved 4 June 2024.
132. "Operating System Market Share
Worldwide" (https://gs.statcounte
r.com/os-market-share) .
StatCounter Global Stats.
Retrieved 20 December 2024.
133. Silberschatz et al. 2018, pp. 779–
780.
134. Tanenbaum & Bos 2023,
pp. 713–714.
135. Silberschatz et al. 2018, p. 780.
136. Vaughan-Nichols, Steven (2022).
"Linus Torvalds prepares to move
the Linux kernel to modern C" (htt
ps://www.zdnet.com/article/linus-
torvalds-prepares-to-move-the-lin
ux-kernel-to-modern-c/) . ZDNET.
Retrieved 7 February 2024.
137. Silberschatz et al. 2018, p. 781.
138. Tanenbaum & Bos 2023,
pp. 715–716.
139. Tanenbaum & Bos 2023,
pp. 793–794.
140. Tanenbaum & Bos 2023, p. 793.
141. Tanenbaum & Bos 2023,
pp. 1021–1022.
142. Tanenbaum & Bos 2023, p. 871.
143. Silberschatz et al. 2018, p. 826.
144. Tanenbaum & Bos 2023, p. 1035.
145. Tanenbaum & Bos 2023, p. 1036.
146. Silberschatz et al. 2018, p. 821.
147. Silberschatz et al. 2018, p. 827.

Further reading

Anderson, Thomas; Dahlin, Michael

(2014). Operating Systems:
Principles and Practice. Recursive
Books. ISBN 978-0-9856735-2-9.
Auslander, M. A.; Larkin, D. C.;
Scherr, A. L. (September 1981).
"The Evolution of the MVS
Operating System". IBM Journal of
Research and Development. 25 (5):
471–482. doi:10.1147/rd.255.0471
(https://doi.org/10.1147%2Frd.255.
0471) . ISSN 0018-8646 (https://se
arch.worldcat.org/issn/0018-864
6) .
Berntsson, Petter Sainio; Strandén,
Lars; Warg, Fredrik (2017).
Evaluation of Open Source Operating
Systems for Safety-Critical
Applications. Springer International
Publishing. pp. 117–132. ISBN 978-
3-319-65948-0.
Deitel, Harvey M.; Deitel, Paul;
Choffnes, David (25 December
2015). Operating Systems (https://a
rchive.org/details/modernoperating
s00tane) . Pearson/Prentice Hall.
ISBN 978-0-13-092641-8.
Bic, Lubomur F.; Shaw, Alan C.
(2003). Operating Systems.
Pearson: Prentice Hall.
Silberschatz, Avi; Galvin, Peter;
Gagne, Greg (2008). Operating
Systems Concepts. John Wiley &
Sons. ISBN 978-0-470-12872-5.
O'Brien, J. A., & Marakas, G. M.
(2011). Management Information
Systems. 10e. McGraw-Hill Irwin.
Leva, Alberto; Maggio, Martina;
Papadopoulos, Alessandro Vittorio;
Terraneo, Federico (2013). Control-
based Operating System Design.
IET. ISBN 978-1-84919-609-3.
Richet, Jean-Loup; Bouaynaya,
Wafa (2023). "Understanding and
Managing Complex Software
Vulnerabilities: An Empirical
Analysis of Open-Source Operating
Systems" (https://www.cairn.info/re
vue-systemes-d-information-et-man
agement-2023-1-page-87.htm.) .
Systèmes d'information &
management. 28 (1): 87–114.
doi:10.54695/sim.28.1.0087 (http
s://doi.org/10.54695%2Fsim.28.1.
0087) (inactive 1 November 2024).
Silberschatz, Abraham; Galvin,
Peter B.; Gagne, Greg (2018).
Operating System Concepts (https://
archive.org/details/operating-syste
m-concepts-10th) (10 ed.). Wiley.
ISBN 978-1-119-32091-3.
Tanenbaum, Andrew S.; Bos,
Herbert (2023). Modern Operating
Systems, Global Edition. Pearson
Higher Ed. ISBN 978-1-292-72789-
9.
External links

Multics History (http://www.cbi.um

n.edu/iterations/haigh.html) and
the history of operating systems

Retrieved from
"https://en.wikipedia.org/w/index.php?
title=Operating_system&oldid=1266422975"

This page was last edited on 31 December

2024, at 14:48 (UTC). •
Content is available under CC BY-SA 4.0
unless otherwise noted.