System Software
Between the raw hardware you met in Chapters 3 and 4 and the applications a user actually opens sits a whole layer of software whose entire job is to make everything else possible: the operating system managing memory, processes and files behind the scenes, and the language translators and development tools that turn the code you write into something a processor can run. This chapter covers Cambridge 9618 syllabus sections 5.1 and 5.2.
A processor with nothing but hardware cannot run more than one program, share itself between users, or even load a file, it needs software managing it from underneath. This chapter covers Cambridge 9618 syllabus section 5.1, the operating system's core management tasks, the utility software bundled with it, and program libraries; and section 5.2, the assemblers, compilers and interpreters that translate the code you write, and the Integrated Development Environments built around them.
Why a Computer System Needs an OS
An operating system (OS) is system software that manages a computer's hardware and software resources, and provides common services that every application program relies on. Without one, a user could not interact with the hardware at all, and every application would need to include its own low-level code for handling memory, storage and devices, duplicated across every single program.
- Hides the messy, device-specific details of the underlying hardware from both programmers and users
- An application asks the OS to "save this file" or "print this page" without needing to know the exact electronics of the disk or printer involved
- Fairly allocates CPU time, memory and devices between every running program
- Prevents one greedy or faulty program from starving every other program of the resources it needs
- Provides a Command Line Interface (CLI) or Graphical User Interface (GUI) so a human can actually interact with the machine
- Controls which users and programs are allowed to access which data and hardware
Memory Management
Every running program needs somewhere in RAM to live, but RAM is a shared, finite resource with several programs wanting a slice of it at once. Memory management is the OS task of allocating RAM to processes, keeping them safely separated from each other, and stretching that limited physical memory further using virtual memory.
- Allocates a chunk of RAM to each process that needs to run
- Keeps every process's memory strictly separated, so one program cannot read or overwrite another's data
- Reclaims memory the moment a process terminates, making it available again
- Splits a program into fixed-size pages, and physical RAM into matching frames
- Pages do not need to sit in consecutive frames, the OS keeps a table tracking where each page actually landed
- When RAM is full, rarely-used pages can be temporarily swapped out to disk, letting the system run programs whose combined size exceeds physical RAM
Process Management
A single-core processor can only ever execute one instruction at a time, yet a computer can appear to run a browser, a music player and a word processor all at once. Process management is the OS task that creates this illusion, alongside creating and terminating processes as programs are opened and closed.
File, Security and Hardware Management
The remaining three OS management tasks round out the full picture the syllabus expects, organising stored data, controlling who can access it, and mediating every physical device.
| Task | What it does |
|---|---|
| File management | Organises files into a directory (folder) structure, tracks exactly where each file's data physically lives on the storage device, and manages read/write permissions on individual files. |
| Security management | Authenticates users at login, enforces access control over who can open or edit which files, and keeps audit logs recording who did what and when. Chapter 6 covers security threats and defences in full depth. |
| Hardware management | Manages every input/output device through device drivers, small pieces of software that translate between the OS's generic instructions and a specific device's actual electronics, and handles interrupts (met in Chapter 4) raised by that hardware. |
Utility Software
Utility software performs maintenance and management tasks on the computer system itself, rather than doing productive work for the user the way an application like a word processor does. Every OS ships with a standard set of these.
Program Libraries
A program library is a collection of pre-written, reusable code modules that a programmer can call from their own program instead of writing that functionality from scratch. Software under development is very often built substantially out of existing library code, saving time, reducing bugs, and letting developers focus on what is actually new about their program.
- The library's code is copied directly into the executable at compile time
- The resulting program is self-contained, with no dependency on the library existing at runtime
- Produces a larger executable file, since a full copy of the library code is baked into every program that uses it
- The library is loaded at runtime, not copied in at compile time
- Multiple running programs can share a single copy of the library sitting in memory
- Produces smaller executables, and the shared library can be updated independently without recompiling every program that depends on it
Assemblers, Compilers and Interpreters
A processor can only ever execute machine code, raw binary instructions, yet almost nobody writes machine code by hand. A language translator is software that converts human-readable source code into a form the processor can actually run, and which translator is needed depends entirely on what language the source code is written in.
| Translator | Input | Output | How it works |
|---|---|---|---|
| Assembler | Assembly language | Machine code | One-to-one translation of each mnemonic instruction into its binary opcode, using the two-pass process covered in Chapter 4 |
| Compiler | High-level language | A standalone machine code executable | Translates the entire program in one go, before any of it runs, producing a complete .exe file |
| Interpreter | High-level language | Executed directly, no file produced | Translates and executes one statement at a time, with no separate executable ever created |
Compiler vs Interpreter
Both a compiler and an interpreter turn high-level source code into something that runs, but they take fundamentally different approaches, and that difference has real consequences for speed, debugging and how software gets distributed.
- Compiled code runs faster, since it is already fully translated to machine code before execution begins
- Source code can be kept private, only the compiled executable needs to be distributed
- Every error in the program is found during compilation, before any of it ever runs
- Distributed as a standalone
.exe, the end user needs no translator installed - Generally preferred for production or release software
- Easier to debug, execution stops at the very first error, exactly where it occurred
- Source code is portable across any platform with a matching interpreter installed
- Can execute code interactively, one line at a time (a REPL)
- A changed line can be tested immediately, with no separate compile step
- Generally preferred during development
Partial Compilation: Java and the JVM
Compiler and interpreter are not always an either-or choice. Some languages, most notably Java, use both, compiling partially and interpreting partially, to get benefits from each approach at once.
Java source code is first compiled, just once, into an intermediate form called bytecode, stored in .class files. That bytecode is not the final machine code for any specific processor, instead, a program called the Java Virtual Machine (JVM) interprets the bytecode, translating and executing it on whatever platform it happens to be running on.
Integrated Development Environments
An Integrated Development Environment (IDE) combines a code editor, a compiler or interpreter, a debugger and other developer tools into one single application, so a programmer never has to switch between separate standalone programs while writing software.
The syllabus groups IDE features into two purposes: helping you write code correctly in the first place, and helping you present it clearly.
IDE Debugging Features
Even syntactically correct code can behave wrongly, a debugger's job is to let a programmer watch a program's execution closely enough to find out exactly where and why. Click each feature below to see what it actually does inside a running program.
Practice Questions
Any three of: allocates RAM to processes that need to run; keeps each process's memory separated so programs cannot interfere with each other; reclaims memory once a process terminates; manages virtual memory and paging so a program's pages can be scattered across free frames, or swapped to disk when physical RAM is full.
A magnetic hard disk has a physical read/write head that must move to a file's location, so a fragmented file scattered across the disk costs extra time as the head moves between its pieces. A solid state drive has no moving parts and roughly equal access time to any location, so fragmentation has little to no effect on its speed.
A DLL is loaded at runtime rather than copied into the executable at compile time, so multiple programs can share a single copy of it in memory, producing smaller executable files. It can also be updated independently, a bug fix in the DLL benefits every program that uses it without needing to recompile them.
An interpreter suits the student better. It executes and translates the program line by line, stopping immediately at the first error, so the student sees exactly where a mistake is the moment it occurs, rather than waiting for an entire program to be compiled first. Changes can also be tested immediately without a separate compile step, letting the student iterate quickly while they are still learning.
The Java source code is first compiled, once, into an intermediate bytecode format stored in .class files. The Java Virtual Machine (JVM) then interprets that bytecode on whichever platform it is run on. This approach is used because it achieves cross-platform portability, the same bytecode runs unchanged wherever a JVM is installed, while still performing better than interpreting the original source code directly every time.
Any two of: single stepping, executing the program one line at a time to trace its flow; variable watch, monitoring a chosen variable's value continuously as the program runs; a report window, displaying error messages, warnings and runtime output in one place.
