Editing Operating system (section)

==Components==
The components of an operating system are designed to ensure that various parts of a computer function cohesively. With the de facto obsoletion of [[Disk Operating System|DOS]], all user [[software]] must interact with the operating system to access hardware.

===Kernel===
{{Main|Kernel (operating system)}}
[[File:Kernel Layout.svg|thumb|A kernel connects the application software to the hardware of a computer.]]

The kernel is the part of the operating system that provides [[protection ring|protection]] between different applications and users. This protection is key to improving reliability by keeping errors isolated to one program, as well as security by limiting the power of [[malicious software]] and protecting private data, and ensuring that one program cannot monopolize the computer's resources.{{sfn|Anderson|Dahlin|2014|pp=39–40}} Most operating systems have two modes of operation:{{sfn|Tanenbaum|Bos|2023|p=2}}  in [[user mode]], the hardware checks that the software is only executing legal instructions, whereas the kernel has [[Privilege (computing)|unrestricted powers]] and is not subject to these checks.{{sfn|Anderson|Dahlin|2014|pp=41, 45}} The kernel also manages [[Random-access memory|memory]] for other processes and controls access to [[input/output]] devices.{{sfn|Anderson|Dahlin|2014|pp=52-53}}

====Program execution====
The operating system provides an interface between an application program and the computer hardware, so that an application program can interact with the hardware only by obeying rules and procedures programmed into the operating system. The operating system is also a set of services which simplify development and execution of application programs. Executing an application program typically involves the creation of a [[Process (computing)|process]] by the operating system [[kernel (operating system)|kernel]], which assigns memory space and other resources, establishes a priority for the process in multi-tasking systems, loads program binary code into memory, and initiates execution of the application program, which then interacts with the user and with hardware devices. However, in some systems an application can request that the operating system execute another application within the same process, either as a subroutine or in a separate thread, e.g., the '''LINK''' and '''ATTACH''' facilities of [[OS/360 and successors]].

====Interrupts====
{{Main|Interrupt}}

An [[interrupt]] (also known as an [[Abort (computing)|abort]], [[Exception handling|exception]], ''fault'', [[Signal (IPC)|signal]],<ref name="lpi-ch20-p388_quote1">{{cite book
  | last = Kerrisk
  | first = Michael
  | title = The Linux Programming Interface
  | publisher = No Starch Press
  | year = 2010
  | page = 388
  | isbn = 978-1-59327-220-3
  | quote = A signal is a notification to a process that an event has occurred. Signals are sometimes described as software interrupts.
}}</ref> or ''trap'')<ref name="Hyde_1996">{{cite book
 |last1        = Hyde
 |first1       = Randall
 |chapter-url  = https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/ch17/CH17-1.html#HEADING1-0
 |access-date  = 22 December 2021
 |date         = 1996
 |title        = The Art Of Assembly Language Programming
 |chapter      = Chapter Seventeen: Interrupts, Traps and Exceptions (Part 1)
 |publisher    = No Starch Press
 |quote        = 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.
 |archive-date = 22 December 2021
 |archive-url  = https://web.archive.org/web/20211222205623/https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/ch17/CH17-1.html#HEADING1-0
 |url-status   = live
}}</ref> provides an efficient way for most operating systems to react to the environment. Interrupts cause the [[central processing unit]] (CPU) to have a [[control flow]] change away from the currently running program to an [[interrupt handler]], also known as an interrupt service routine (ISR).<ref name="sco-ch5-p308_a">{{cite book
  | last = Tanenbaum
  | first = Andrew S.
  | title = Structured Computer Organization, Third Edition
  | publisher = Prentice Hall
  | year = 1990
  | page = [https://archive.org/details/structuredcomput00tane/page/308 308]
  | isbn = 978-0-13-854662-5
  | url = https://archive.org/details/structuredcomput00tane/page/308
  | quote = 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.
  }}</ref><ref name="osc-ch2-p32_a">{{cite book
  | last = Silberschatz
  | first = Abraham
  | title = Operating System Concepts, Fourth Edition
  | publisher = Addison-Wesley
  | year = 1994
  | page = 32
  | isbn = 978-0-201-50480-4
  | quote = 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.}}</ref> An interrupt service routine may cause the [[central processing unit]] (CPU) to have a [[context switch]].<ref name="osc-ch4-p105">{{cite book
  | last = Silberschatz
  | first = Abraham
  | title = Operating System Concepts, Fourth Edition
  | publisher = Addison-Wesley
  | year = 1994
  | page = 105
  | isbn = 978-0-201-50480-4
  | quote = 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.}}</ref>{{efn|Modern CPUs provide instructions (e.g. SYSENTER) to invoke selected kernel services without an interrupts. Visit https://wiki.osdev.org/SYSENTER for more information.}} The details of how a computer processes an interrupt vary from architecture to architecture, and the details of how interrupt service routines behave vary from operating system to operating system.<ref name="osc-ch2-p31">{{cite book
  | last = Silberschatz
  | first = Abraham
  | title = Operating System Concepts, Fourth Edition
  | publisher = Addison-Wesley
  | year = 1994
  | page = 31
  | isbn = 978-0-201-50480-4
}}</ref> However, several interrupt functions are common.<ref name="osc-ch2-p31"/> The architecture and operating system must:<ref name="osc-ch2-p31"/>
# transfer control to an interrupt service routine.
# save the state of the currently running process.
# restore the state after the interrupt is serviced.

=====Software interrupt=====
A software interrupt is a message to a [[Process (computing)|process]] that an event has occurred.<ref name="lpi-ch20-p388_quote1"/> This contrasts with a ''hardware interrupt'' — which is a message to the [[central processing unit]] (CPU) that an event has occurred.<ref name="osc-ch2-p30">{{cite book
  | last = Silberschatz
  | first = Abraham
  | title = Operating System Concepts, Fourth Edition
  | publisher = Addison-Wesley
  | year = 1994
  | page = 30
  | isbn = 978-0-201-50480-4
  | quote = Hardware may trigger an interrupt at any time by sending a signal to the CPU, usually by way of the system bus.
}}</ref> Software interrupts are similar to hardware interrupts — there is a change away from the currently running process.<ref name="lpi-ch20-p388_quote2">{{cite book
  | last = Kerrisk
  | first = Michael
  | title = The Linux Programming Interface
  | publisher = No Starch Press
  | year = 2010
  | page = 388
  | isbn = 978-1-59327-220-3
  | quote = 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.
}}</ref> Similarly, both hardware and software interrupts execute an [[Interrupt handler|interrupt service routine]].

Software interrupts may be normally occurring events. It is expected that a [[Preemption (computing)#Time slice|time slice]] will occur, so the kernel will have to perform a [[context switch]].<ref name="lpi-ch20-p388_quote3">{{cite book
  | last = Kerrisk
  | first = Michael
  | title = The Linux Programming Interface
  | publisher = No Starch Press
  | year = 2010
  | page = 388
  | isbn = 978-1-59327-220-3
  | quote = 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[.]
}}</ref> A [[computer program]] may set a timer to go off after a few seconds in case too much data causes an algorithm to take too long.<ref name="lpi-ch20-p388">{{cite book
  | last = Kerrisk
  | first = Michael
  | title = The Linux Programming Interface
  | publisher = No Starch Press
  | year = 2010
  | page = 388
  | isbn = 978-1-59327-220-3
}}</ref>

Software interrupts may be error conditions, such as a malformed [[machine code|machine instruction]].<ref name="lpi-ch20-p388"/> However, the most common error conditions are [[division by zero]] and [[segmentation fault|accessing an invalid memory address]].<ref name="lpi-ch20-p388"/>

[[User (computing)|Users]] can send messages to the kernel to modify the behavior of a currently running process.<ref name="lpi-ch20-p388"/> For example, in the [[Command-line interface|command-line environment]], pressing the ''interrupt character'' (usually [[Control-C]]) might terminate the currently running process.<ref name="lpi-ch20-p388"/>

To generate ''software interrupts'' for [[x86]] CPUs, the [[INT (x86 instruction)|INT]] [[assembly language]] instruction is available.<ref name="intel-developer">{{cite web
 |url=https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf
 |access-date=2022-05-05
 |title=Intel® 64 and IA-32 Architectures Software Developer's Manual
 |volume=2
 |date=September 2016
 |publisher=[[Intel Corporation]]
 |page=610
 |archive-date=23 March 2022
 |archive-url=https://web.archive.org/web/20220323231921/https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf
 |url-status=live
 }}</ref> The syntax is <code>INT X</code>, where <code>X</code> is the offset number (in [[hexadecimal]] format) to the [[interrupt vector table]].

=====Signal=====
To generate ''software interrupts'' in [[Unix-like]] operating systems, the <code>kill(pid,signum)</code> [[system call]] will send a [[Signal (IPC)|signal]] to another process.<ref name="duos-p200">{{cite book
  | last = Bach
  | first = Maurice J.
  | title = The Design of the UNIX Operating System
  | publisher = Prentice-Hall
  | year = 1986
  | page = 200
  | isbn = 0-13-201799-7
}}</ref> <code>pid</code> is the [[process identifier]] of the receiving process. <code>signum</code> is the signal number (in [[mnemonic]] format){{efn|Examples include [[Signal (IPC)#SIGINT|SIGINT]], [[SIGSEGV]], and [[SIGBUS]].}} to be sent. (The abrasive name of <code>kill</code> was chosen because early implementations only terminated the process.)<ref name="lpi-ch20-p400">{{cite book
  | last = Kerrisk
  | first = Michael
  | title = The Linux Programming Interface
  | publisher = No Starch Press
  | year = 2010
  | page = 400
  | isbn = 978-1-59327-220-3
}}</ref>

In Unix-like operating systems, ''signals'' inform processes of the occurrence of asynchronous events.<ref name="duos-p200"/> To communicate asynchronously, interrupts are required.<ref name="sco-ch5-p308_b">{{cite book
  | last = Tanenbaum
  | first = Andrew S.
  | title = Structured Computer Organization, Third Edition
  | publisher = Prentice Hall
  | year = 1990
  | page = [https://archive.org/details/structuredcomput00tane/page/308 308]
  | isbn = 978-0-13-854662-5
  | url = https://archive.org/details/structuredcomput00tane/page/308
  }}</ref> One reason a process needs to asynchronously communicate to another process solves a variation of the classic [[Readers–writers problem|reader/writer problem]].<ref name="osc-p182">{{cite book
  | last = Silberschatz
  | first = Abraham
  | title = Operating System Concepts, Fourth Edition
  | publisher = Addison-Wesley
  | year = 1994
  | page = 182
  | isbn = 978-0-201-50480-4
}}</ref> The writer receives a pipe from the [[Shell (computing)|shell]] for its output to be sent to the reader's input stream.<ref name="usp-ch6-p153">{{cite book
  | last1 = Haviland
  | first1 = Keith
  | last2 = Salama
  | first2 = Ben
  | title = UNIX System Programming
  | publisher = Addison-Wesley Publishing Company
  | year = 1987
  | page = 153
  | isbn = 0-201-12919-1
}}</ref> The [[Command-line interface|command-line]] syntax is <code>alpha | bravo</code>. <code>alpha</code> will write to the pipe when its computation is ready and then sleep in the wait queue.<ref name="usp-ch6-p148">{{cite book
  | last1 = Haviland
  | first1 = Keith
  | last2 = Salama
  | first2 = Ben
  | title = UNIX System Programming
  | publisher = Addison-Wesley Publishing Company
  | year = 1987
  | page = 148
  | isbn = 0-201-12919-1
}}</ref> <code>bravo</code> will then be moved to the [[Multilevel feedback queue|ready queue]] and soon will read from its input stream.<ref name="usp-ch6-p149">{{cite book
  | last1 = Haviland
  | first1 = Keith
  | last2 = Salama
  | first2 = Ben
  | title = UNIX System Programming
  | publisher = Addison-Wesley Publishing Company
  | year = 1987
  | page = 149
  | isbn = 0-201-12919-1
}}</ref> The kernel will generate ''software interrupts'' to coordinate the piping.<ref name="usp-ch6-p149"/>

''Signals'' may be classified into 7 categories.<ref name="duos-p200"/> The categories are:
# when a process finishes normally.
# when a process has an error exception.
# when a process runs out of a system resource.
# when a process executes an illegal instruction.
# when a process sets an alarm event.
# when a process is aborted from the keyboard.
# when a process has a tracing alert for debugging.

=====Hardware interrupt=====
[[Input/output]] (I/O) [[Peripheral|devices]] are slower than the CPU. Therefore, it would slow down the computer if the CPU had to [[Busy waiting|wait]] for each I/O to finish. Instead, a computer may implement interrupts for I/O completion, avoiding the need for [[Polling (computer science)|polling]] or busy waiting.<ref name="sco-ch5-p292">{{cite book
  | last = Tanenbaum
  | first = Andrew S.
  | title = Structured Computer Organization, Third Edition
  | publisher = Prentice Hall
  | year = 1990
  | page = [https://archive.org/details/structuredcomput00tane/page/292 292]
  | isbn = 978-0-13-854662-5
  | url = https://archive.org/details/structuredcomput00tane/page/292
  }}</ref>

Some computers require an interrupt for each character or word, costing a significant amount of CPU time. [[Direct memory access]] (DMA) is an architecture feature to allow devices to bypass the CPU and access [[random-access memory|main memory]] directly.<ref name=A22-6821-7-storage>{{cite book
 |author       = IBM
 |title        = IBM System/360 Principles of Operation
 |date         = September 1968
 |version      = Eighth Edition
 |url          = http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf
 |section      = Main Storage
 |section-url  = http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf#page=8
 |mode         = cs2
 |page         = 7
 |access-date  = 13 April 2022
 |archive-date = 19 March 2022
 |archive-url  = https://web.archive.org/web/20220319083255/http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf
 |url-status   = live
}}</ref> (Separate from the architecture, a device may perform direct memory access{{efn|often in the form of a DMA chip for smaller systems and I/O channels for larger systems}} to and from main memory either directly or via a bus.)<ref name="sco-ch5-p294">
{{cite book
  | last = Tanenbaum
  | first = Andrew S.
  | title = Structured Computer Organization, Third Edition
  | publisher = Prentice Hall
  | year = 1990
  | page = [https://archive.org/details/structuredcomput00tane/page/294 294]
  | isbn = 978-0-13-854662-5
  | url = https://archive.org/details/structuredcomput00tane/page/294
  }}</ref>{{efn|Modern [[motherboard]]s have a DMA controller. Additionally, a device may also have one. Visit [[SCSI RDMA Protocol]].}}

====Input/output====

=====Interrupt-driven I/O=====
{{Expand section|date=April 2022}}
When a [[user (computing)|computer user]] types a key on the keyboard, typically the character appears immediately on the screen. Likewise, when a user moves a [[computer mouse|mouse]], the [[Cursor (user interface)|cursor]] immediately moves across the screen. Each keystroke and mouse movement generates an ''interrupt'' called ''Interrupt-driven I/O''. An interrupt-driven I/O occurs when a process causes an interrupt for every character<ref name="sco-ch5-p294"/> or word<ref>{{cite book
 |title        = Users Handbook - PDP-7
 |id           = F-75
 |year         = 1965
 |url          = http://bitsavers.org/pdf/dec/pdp7/F-75_PDP-7userHbk_Jun65.pdf
 |section      = Program Interrupt Controller (PIC)
 |section-url  = http://bitsavers.org/pdf/dec/pdp7/F-75_PDP-7userHbk_Jun65.pdf#page=62
 |pages        = [http://bitsavers.org/pdf/dec/pdp7/F-75_PDP-7userHbk_Jun65.pdf#page=63 48]
 |publisher    = [[Digital Equipment Corporation]]
 |access-date  = April 20, 2022
 |archive-date = 10 May 2022
 |archive-url  = https://web.archive.org/web/20220510164742/http://bitsavers.org/pdf/dec/pdp7/F-75_PDP-7userHbk_Jun65.pdf
 |url-status   = live
}}</ref> transmitted.

=====Direct memory access=====
Devices such as [[hard disk drive]]s, [[solid-state drive]]s, and [[magnetic tape]] drives can transfer data at a rate high enough that interrupting the CPU for every byte or word transferred, and having the CPU transfer the byte or word between the device and memory, would require too much CPU time. Data is, instead, transferred between the device and memory independently of the CPU by hardware such as a [[channel I/O|channel]] or a [[direct memory access]] controller; an interrupt is delivered only when all the data is transferred.<ref>{{cite book|url=http://bitsavers.org/pdf/dec/pdp1/F25_PDP1_IO.pdf|title=PDP-1 Input-Output Systems Manual|publisher=[[Digital Equipment Corporation]]|pages=19–20|access-date=16 August 2022|archive-date=25 January 2019|archive-url=https://web.archive.org/web/20190125050839/http://bitsavers.org/pdf/dec/pdp1/F25_PDP1_IO.pdf|url-status=live}}</ref>

If a [[computer program]] executes a [[system call]] to perform a block I/O ''write'' operation, then the system call might execute the following instructions:
* Set the contents of the CPU's [[Processor register|registers]] (including the [[program counter]]) into the [[process control block]].<ref name="osc-ch2-p32_b">{{cite book
  | last = Silberschatz
  | first = Abraham
  | title = Operating System Concepts, Fourth Edition
  | publisher = Addison-Wesley
  | year = 1994
  | page = 32
  | isbn = 978-0-201-50480-4
}}</ref>
* Create an entry in the device-status table.<ref name="osc-ch2-p34">{{cite book
  | last = Silberschatz
  | first = Abraham
  | title = Operating System Concepts, Fourth Edition
  | publisher = Addison-Wesley
  | year = 1994
  | page = 34
  | isbn = 978-0-201-50480-4
}}</ref> 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 [[random-access memory|memory buffer]].<ref name="sco-ch5-p308_b"/>
* Set the memory address of the memory buffer to a predetermined device register.<ref name="sco-ch5-p295">{{cite book
  | last = Tanenbaum
  | first = Andrew S.
  | title = Structured Computer Organization, Third Edition
  | publisher = Prentice Hall
  | year = 1990
  | page = [https://archive.org/details/structuredcomput00tane/page/295 295]
  | isbn = 978-0-13-854662-5
  | url = https://archive.org/details/structuredcomput00tane/page/295
  }}</ref>
* Set the buffer size (an integer) to another predetermined register.<ref name="sco-ch5-p295"/>
* Execute the [[machine code|machine instruction]] to begin the writing.
* Perform a [[context switch]] to the next process in the [[multilevel feedback queue|ready queue]].

While the writing takes place, the operating system will context switch to other processes as normal. When the device finishes writing, the device will ''interrupt'' the currently running process by ''asserting'' an [[Interrupt request (PC architecture)|interrupt request]]. The device will also place an integer onto the data bus.<ref name="sco-ch5-p309">{{cite book
  | last = Tanenbaum
  | first = Andrew S.
  | title = Structured Computer Organization, Third Edition
  | publisher = Prentice Hall
  | year = 1990
  | page = [https://archive.org/details/structuredcomput00tane/page/309 309]
  | isbn = 978-0-13-854662-5
  | url = https://archive.org/details/structuredcomput00tane/page/309
  }}</ref> Upon accepting the interrupt request, the operating system will:
* Push the contents of the [[program counter]] (a register) followed by the [[status register]] onto the [[call stack]].<ref name="osc-ch2-p31"/>
* Push the contents of the other registers onto the call stack. (Alternatively, the contents of the registers may be placed in a system table.)<ref name="sco-ch5-p309"/>
* 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 the writing process has its [[Preemption (computing)#time slice|time slice]] expired, the operating system will:<ref name="sco-ch5-p310">{{cite book
  | last = Tanenbaum
  | first = Andrew S.
  | title = Structured Computer Organization, Third Edition
  | publisher = Prentice Hall
  | year = 1990
  | page = [https://archive.org/details/structuredcomput00tane/page/310 310]
  | isbn = 978-0-13-854662-5
  | url = https://archive.org/details/structuredcomput00tane/page/310
  }}</ref>
* 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.

With the program counter now reset, the interrupted process will resume its time slice.<ref name="osc-ch2-p31"/>

====Memory management====
{{Main|Memory management}}

Among other things, a multiprogramming operating system [[kernel (operating system)|kernel]] must be responsible for managing all system memory which is currently in use by the programs. This ensures that a program does not interfere with memory already in use by another program. Since programs time share, each program must have independent access to memory.

Cooperative memory management, used by many early operating systems, assumes that all programs make voluntary use of the [[kernel (operating system)|kernel]]'s memory manager, and do not exceed their allocated memory. This system of memory management is almost never seen anymore, since programs often contain bugs which can cause them to exceed their allocated memory. If a program fails, it may cause memory used by one or more other programs to be affected or overwritten. Malicious programs or viruses may purposefully alter another program's memory, or may affect the operation of the operating system itself. With cooperative memory management, it takes only one misbehaved program to [[Crash (computing)|crash]] the system.

[[Memory protection]] enables the [[kernel (operating system)|kernel]] to limit a process' access to the computer's memory. Various methods of memory protection exist, including [[memory segmentation]] and [[paging]]. All methods require some level of hardware support (such as the [[80286]] MMU), which does not exist in all computers.

In both segmentation and paging, certain [[protected mode]] registers specify to the CPU what memory address it should allow a running program to access. Attempts to access other addresses trigger an interrupt, which causes the CPU to re-enter [[supervisor mode]], placing the [[kernel (operating system)|kernel]] in charge. This is called a [[segmentation violation]] or Seg-V for short, and since it is both difficult to assign a meaningful result to such an operation, and because it is usually a sign of a misbehaving program, the [[kernel (operating system)|kernel]] generally resorts to terminating the offending program, and reports the error.

Windows versions 3.1 through ME had some level of memory protection, but programs could easily circumvent the need to use it. A [[general protection fault]] would be produced, indicating a segmentation violation had occurred; however, the system would often crash anyway.

====Virtual memory====
{{Main|Virtual memory}}
{{Further|Page fault}}
[[File:Virtual memory.svg|thumb|250px|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 virtual memory addressing (such as paging or segmentation) means that the kernel can choose what memory each program may use at any given time, allowing the operating system to use the same memory locations for multiple tasks.

If a program tries to access memory that is not accessible{{efn|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., [[Memory protection#Protection keys|key]], [[Memory protection#Protection rings|ring]].}} memory, but nonetheless has been allocated to it, the kernel is interrupted {{See above|{{Section link||Memory management}}}}. This kind of interrupt is typically a [[page fault]].

When the kernel detects a page fault it generally adjusts the virtual memory range of the program which triggered it, granting it access to the memory requested. This gives the kernel discretionary power over where a particular application's memory is stored, or even whether or not it has been allocated yet.

In modern operating systems, memory which is accessed less frequently can be temporarily stored on a disk or other media to make that space available for use by other programs. This is called [[paging|swapping]], as an area of memory can be used by multiple programs, and what that memory area contains can be swapped or exchanged on demand.

Virtual memory provides the programmer or the user with the perception that there is a much larger amount of RAM in the computer than is really there.<ref name="Operating System">{{cite book|last=Stallings|first=William|title=Computer Organization & Architecture|year=2008|publisher=Prentice-Hall of India Private Limited|location=New Delhi|isbn=978-81-203-2962-1|page=267}}</ref>

===Concurrency===
{{see also|Computer multitasking|Process management (computing)}}

[[Concurrency (computer science)|Concurrency]] refers to the operating system's ability to carry out multiple tasks simultaneously.{{sfn|Anderson|Dahlin|2014|p=129}} Virtually all modern operating systems support concurrency.{{sfn|Silberschatz et al.|2018|p=159}}

[[Thread (computing)|Thread]]s enable splitting a process' work into multiple parts that can run simultaneously.{{sfn|Anderson|Dahlin|2014|p=130}} The number of threads is not limited by the number of processors available. If there are more threads than processors, the operating system [[kernel (operating system)|kernel]] schedules, suspends, and resumes threads, controlling when each thread runs and how much CPU time it receives.{{sfn|Anderson|Dahlin|2014|p=131}}  During a [[context switch]] a running thread is suspended, its state is saved into the [[thread control block]] and stack, and the state of the new thread is loaded in.{{sfn|Anderson|Dahlin|2014|pp=157, 159}} Historically, on many systems a thread could run until it relinquished control ([[cooperative multitasking]]). Because this model can allow a single thread to monopolize the processor, most operating systems now can [[interrupt]] a thread ([[preemptive multitasking]]).{{sfn|Anderson|Dahlin|2014|p=139}}

Threads have their own thread ID, [[program counter]] (PC), a [[Processor register|register]] set, and a [[Stack-based memory allocation|stack]], but share code, [[heap memory|heap]] data, and other resources with other threads of the same process.{{sfn|Silberschatz et al.|2018|p=160}}{{sfn|Anderson|Dahlin|2014|p=183}} Thus, there is less overhead to create a thread than a new process.{{sfn|Silberschatz et al.|2018|p=162}} On single-CPU systems, concurrency is switching between processes. Many computers have multiple CPUs.{{sfn|Silberschatz et al.|2018|pp=162–163}} [[Parallel computing|Parallelism]] with multiple threads running on different CPUs can speed up a program, depending on how much of it can be executed concurrently.{{sfn|Silberschatz et al.|2018|p=164}}

===File system===
{{Main|File system}}
{{see also|Virtual file system}}
[[File:Dolphin FileManager.png|thumb|[[File system]]s allow users and programs to organize and sort files on a computer, often through the use of [[Directory (computing)|directories]] (or folders).]]

Permanent storage devices used in twenty-first century computers, unlike [[volatile memory|volatile]] [[dynamic random-access memory]] (DRAM), are still accessible after a [[Crash (computing)|crash]] or [[power failure]]. Permanent ([[non-volatile memory|non-volatile]]) storage is much cheaper per byte, but takes several orders of magnitude longer to access, read, and write.{{sfn|Anderson|Dahlin|2014|pp=492, 517}}{{sfn|Tanenbaum|Bos|2023|pp=259–260}} The two main technologies are a [[hard drive]] consisting of [[magnetic disk]]s, and [[flash memory]] (a [[solid-state drive]] that stores data in electrical circuits). The latter is more expensive but faster and more durable.{{sfn|Anderson|Dahlin|2014|pp=517, 530}}{{sfn|Tanenbaum|Bos|2023|p=260}}

[[File system]]s are an [[abstraction]] used by the operating system to simplify access to permanent storage. They provide human-readable [[filenames]] and other [[metadata]], increase performance via [[Amortization (computer science)|amortization]] of accesses, prevent multiple threads from accessing the same section of memory, and include [[checksums]] to identify [[Data corruption|corruption]].{{sfn|Anderson|Dahlin|2014|pp=492–493}} File systems are composed of files (named collections of data, of an arbitrary size) and [[Directory (computing)|directories]] (also called folders) that list human-readable filenames and other directories.{{sfn|Anderson|Dahlin|2014|p=496}} An absolute [[file path]] begins at the [[root directory]] and lists [[subdirectories]] divided by punctuation, while a relative path defines the location of a file from a directory.{{sfn|Anderson|Dahlin|2014|pp=496–497}}{{sfn|Tanenbaum|Bos|2023|pp=274–275}}

[[System call]]s (which are sometimes [[Wrapper function|wrapped]] by libraries) enable applications to create, delete, open, and close files, as well as link, read, and write to them. All these operations are carried out by the operating system on behalf of the application.{{sfn|Anderson|Dahlin|2014|pp=502–504}} The operating system's efforts to reduce latency include storing recently requested blocks of memory in a [[Cache (computing)|cache]] and [[prefetching]] data that the application has not asked for, but might need next.{{sfn|Anderson|Dahlin|2014|p=507}} [[Device driver]]s are software specific to each [[input/output]] (I/O) device that enables the operating system to work without modification over different hardware.{{sfn|Anderson|Dahlin|2014|p=508}}{{sfn|Tanenbaum|Bos|2023|p=359}}

Another component of file systems is a [[Associative array|dictionary]] that maps a file's name and metadata to the [[data block]] where its contents are stored.{{sfn|Anderson|Dahlin|2014|p=545}} Most file systems use directories to convert file names to file numbers. To find the block number, the operating system uses an [[Database index|index]] (often implemented as a [[tree (data structure)|tree]]).{{sfn|Anderson|Dahlin|2014|p=546}} Separately, there is a free space [[map (data structure)|map]] to track free blocks, commonly implemented as a [[bitmap]].{{sfn|Anderson|Dahlin|2014|p=546}} Although any free block can be used to store a new file, many operating systems try to group together files in the same directory to maximize performance, or periodically reorganize files to reduce [[file system fragmentation|fragmentation]].{{sfn|Anderson|Dahlin|2014|p=547}}

Maintaining data reliability in the face of a computer crash or hardware failure is another concern.{{sfn|Anderson|Dahlin|2014|pp=589, 591}} File writing protocols are designed with atomic operations so as not to leave permanent storage in a partially written, inconsistent state in the event of a crash at any point during writing.{{sfn|Anderson|Dahlin|2014|pp=591–592}} Data corruption is addressed by redundant storage (for example, RAID—[[redundant array of inexpensive disks]]){{sfn|Tanenbaum|Bos|2023|pp=385–386}}{{sfn|Anderson|Dahlin|2014|p=592}} and [[checksums]] to detect when data has been corrupted. With multiple layers of checksums and backups of a file, a system can recover from multiple hardware failures. Background processes are often used to detect and recover from data corruption.{{sfn|Anderson|Dahlin|2014|p=592}}

===Security===
{{Main|Computer security}}

Security means protecting users from other users of the same computer, as well as from those who seeking remote access to it over a network.{{sfn|Tanenbaum|Bos|2023|pp=605-606}} <!-- A [[Vulnerability (computing)|vulnerability]] is when a bug can be exploited to compromise the system or its data; an [[Exploit (computer security)|exploit]] is the signal needed to trigger the bug causing the vulnerability.{{sfn|Tanenbaum|Bos|2023|p=606}} Often the goal of the attacker is to install [[malware]], whether in the form of a [[computer virus|virus]], [[computer worm|worm]], or [[Trojan (malware)|Trojan]].{{sfn|Tanenbaum|Bos|2023|p=607}} --> Operating systems security rests on achieving the [[CIA triad]]: confidentiality (unauthorized users cannot access data), integrity (unauthorized users cannot modify data), and availability (ensuring that the system remains available to authorized users, even in the event of a [[denial of service attack]]).{{sfn|Tanenbaum|Bos|2023|p=608}} As with other computer systems, isolating [[security domain]]s—in the case of operating systems, the kernel, processes, and [[virtual machine]]s—is key to achieving security.{{sfn|Tanenbaum|Bos|2023|p=609}} Other ways to increase security include simplicity to minimize the [[attack surface]], locking access to resources by default, checking all requests for authorization, [[principle of least authority]] (granting the minimum privilege essential for performing a task), [[privilege separation]], and reducing shared data.{{sfn|Tanenbaum|Bos|2023|pp=609–610}}

Some operating system designs are more secure than others. Those with no isolation between the kernel and applications are least secure, while those with a [[monolithic kernel]] like most general-purpose operating systems are still vulnerable if any part of the kernel is compromised. A more secure design features [[microkernel]]s that separate the kernel's privileges into many separate security domains and reduce the consequences of a single kernel breach.{{sfn|Tanenbaum|Bos|2023|p=612}} [[Unikernel]]s are another approach that improves security by minimizing the kernel and separating out other operating systems functionality by application.{{sfn|Tanenbaum|Bos|2023|p=612}}

Most operating systems are written in [[C (programming language)|C]] or [[C++]], which create potential vulnerabilities for exploitation. Despite attempts to protect against them, vulnerabilities are caused by [[buffer overflow]] attacks, which are enabled by the lack of [[bounds checking]].{{sfn|Tanenbaum|Bos|2023|pp=648, 657}} <!-- Other types of vulnerability in operating systems written in C and C++ include [[format string attack]]s, which exploit lack of [[type checking]] to [[code injection|inject malicious code]],{{sfn|Tanenbaum|Bos|2023|pp=658, 661}} [[use-after-free attack]]s that rely on [[C dynamic memory allocation|dynamically allocated memory]],{{sfn|Tanenbaum|Bos|2023|p=661}} and [[null pointer dereference attack]]s that an attacker can exploit to crash a computer.{{sfn|Tanenbaum|Bos|2023|p=664}} --> Hardware vulnerabilities, some of them [[Speculative execution CPU vulnerabilities|caused by CPU optimizations]], can also be used to compromise the operating system.{{sfn|Tanenbaum|Bos|2023|pp=668–669, 674}} There are known instances of operating system programmers deliberately implanting vulnerabilities, such as [[Backdoor (computing)|back door]]s.{{sfn|Tanenbaum|Bos|2023|pp=679–680}}

Operating systems security is hampered by their increasing complexity and the resulting inevitability of bugs.{{sfn|Tanenbaum|Bos|2023|pp=605, 617–618}} Because [[formal verification]] of operating systems may not be feasible, developers use operating system [[Hardening (computing)|hardening]] to reduce vulnerabilities,{{sfn|Tanenbaum|Bos|2023|pp=681–682}} e.g. [[address space layout randomization]], [[control-flow integrity]],{{sfn|Tanenbaum|Bos|2023|p=683}} [[Access-control list|access restriction]]s,{{sfn|Tanenbaum|Bos|2023|p=685}} and other techniques.{{sfn|Tanenbaum|Bos|2023|p=689}} There are no restrictions on who can contribute code to open source operating systems; such operating systems have transparent change histories and distributed governance structures.{{sfn|Richet|Bouaynaya|2023|p=92}} Open source developers strive to work collaboratively to find and eliminate security vulnerabilities, using [[code review]] and [[type checking]] to expunge malicious code.{{sfn|Richet|Bouaynaya|2023|pp=92–93}}{{sfn|Berntsso|Strandén|Warg|2017|pp=130–131}} [[Andrew S. Tanenbaum]] advises releasing the [[source code]] of all operating systems, arguing that it prevents developers from placing trust in secrecy and thus relying on the unreliable practice of [[security by obscurity]].{{sfn|Tanenbaum|Bos|2023|p=611}}

===User interface===
{{Main|Shell (computing){{!}}Operating system user interface}}

A [[user interface]] (UI) is essential to support human interaction with a computer. The two most common user interface types for any computer 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 (computing)|WIMP]].

For personal computers, including [[smartphone]]s and [[tablet computer]]s, and for [[workstation]]s, user input is typically from a combination of [[Keyboard technology|keyboard]], [[mouse (computing)|mouse]], and [[trackpad]] or [[touchscreen]], all of which are connected to the operating system with specialized software.{{sfn|Tanenbaum|Bos|2023|pp=396, 402}} Personal computer users who are not software developers or coders often prefer GUIs for both input and output; GUIs are supported by most personal computers.{{sfn|Tanenbaum|Bos|2023|pp=395, 408}} The software to support GUIs is more complex than a command line for input and plain text output. Plain text output is often preferred by programmers, and is easy to support.{{sfn|Tanenbaum|Bos|2023|p=402}}