IGCSE 0478 – Software: How Hardware, Firmware and an Operating System Enable Applications

Learning objective

Explain why hardware, firmware and an operating system (OS) must all be present before any application software can run, and describe the role of interrupts in this hierarchy.

Key terms (linked to assessment objectives)

Layered view of a computer system

Each layer depends on the one below it. The diagram (see placeholder at the end) shows the flow of control from power‑on to an application.

Operating‑system functions required by the syllabus

• File‑system management – create, open, read, write, rename and delete files; organise them in directories.
• Memory management
  • Allocate and free RAM for each process.
  • Virtual memory (paging or swapping) to extend usable memory.
• Process management & multitasking
  • Create, schedule, pause, resume and terminate processes.
  • Time‑slicing and priority‑based scheduling.
• Security & user‑account management
  • Authentication (login passwords, PINs).
  • Permissions and access control (read, write, execute).
• Device‑driver management – provide a uniform software interface to keyboards, mice, displays, storage, printers, network cards, etc.
• Interrupt handling
  • Detect hardware and software interrupts.
  • Save the current CPU state, run the appropriate Interrupt Service Routine (ISR), then restore the saved state.

Interrupts – detailed cycle

1. Interrupt request (IRQ) is generated by a device or by a software instruction.
2. The CPU finishes the current instruction, then switches from user mode to kernel (privileged) mode.
3. The OS saves the current context (registers, program counter) on a stack.
4. The appropriate Interrupt Service Routine (ISR) is executed:
   • For a hardware interrupt – e.g., keyboard controller reads the scancode.
   • For a software interrupt – e.g., a system call to open a file.
5. After the ISR finishes, the OS restores the saved context and returns to the interrupted task.

Example: Pressing a key generates a hardware interrupt. The OS ISR reads the scancode, translates it to a character, places it in the keyboard buffer, and the active application later reads the character from that buffer.

Boot process – step‑by‑step (including firmware actions)

1. Power‑on – the power supply activates the motherboard and the CPU starts executing from a fixed address.
2. Firmware POST – BIOS/UEFI performs a Power‑On Self‑Test, checking CPU, RAM, video, and essential peripherals.
3. Firmware diagnostics – any errors are reported via beep codes or on‑screen messages.
4. Boot device selection – the firmware scans the list of bootable devices (HDD, SSD, USB, network) according to its boot order.
5. Bootloader loading – the firmware reads the first sector (MBR or EFI System Partition) of the selected device and loads a bootloader (e.g., GRUB, Windows Boot Manager) into RAM.
6. Kernel start‑up – the bootloader hands control to the OS kernel, which initialises core services, sets up memory management, and loads essential device drivers.
7. OS services become available – system processes are created, file systems are mounted, and a user interface (GUI or command line) is presented.
8. Application launch – the user (or the OS) starts an application; the OS allocates memory, opens required files, and schedules the program’s processes.

Why each layer is essential

• Hardware – the only part that can actually perform calculations, store data and move signals to/from the external world.
• Firmware – prepares the hardware, performs diagnostics (POST) and provides a reliable entry point for the OS by loading a bootloader.
• Operating system – abstracts hardware details, manages resources, handles interrupts, and supplies the services (file I/O, memory allocation, process scheduling, security, device drivers) that applications need.
• Application software – relies on OS services to interact with files, memory, devices and the user; without the OS it could not run on different hardware.

Illustrative scenario: Running a word processor

1. User double‑clicks the word‑processor icon.
2. OS creates a new process, allocates RAM, and loads the executable from the SSD using the file‑system service.
3. Device drivers (managed by the OS) initialise the keyboard, mouse and display so the user can type and see text.
4. The application calls the OS API open("mydoc.txt"); the OS checks user permissions, locates the file on the file system, and returns a file handle.
5. When the user presses a key, the keyboard controller raises a hardware interrupt. The OS ISR reads the scancode, translates it to a character, places it in the keyboard buffer, and the word processor reads the character from that buffer.
6. If the user saves the document, the application issues a write() system call. The OS translates this into a series of disk‑write commands, uses virtual memory if needed, and updates the file system.
7. All actions ultimately depend on the CPU executing instructions and the RAM holding temporary data – the hardware layer.

OS as a runtime environment for development tools

The OS also provides the environment required by IDEs, compilers and interpreters:

• File‑system for storing source files and compiled binaries.
• Memory management for loading large development programs.
• Process scheduling so multiple tools (editor, compiler, debugger) can run simultaneously.
• Device‑driver support for keyboards, displays and external storage used during development.

Suggested diagram (placeholder)

Key points to remember

• Software cannot function without hardware; hardware is useless without software.
• Firmware is permanent low‑level software that prepares the hardware and loads the OS.
• The OS provides a common platform for all applications, handling resource allocation, device communication and interrupt processing.
• Specific OS functions required by the syllabus: file‑system handling, memory (including virtual memory) management, process creation & multitasking, security/user‑account control, device‑driver management, and interrupt handling.
• Understanding the hierarchy helps diagnose problems – a crash may stem from faulty hardware, a firmware error, an OS issue, or a bug in the application.