1.2.1 - Operating systems, BIOS and drivers

1.2.1 - Operating systems, BIOS and drivers

Opening, editing and printing a document involves more than the application alone. You will follow the operating system's resource and file services, the firmware that starts the machine, and the driver that communicates with a device. These layers let applications use hardware through organised, controlled requests.

A platform for applications and resources

An operating system (OS) is system software that manages hardware resources and provides services through which applications and users use a computer. It supplies a common platform so that every application does not have to implement its own complete hardware-control system.

When a document editor needs to open a file or print a page, it requests OS services. The OS coordinates access to storage and output devices. A computer also has limited processor time and RAM. The OS allocates memory to running programs, tracks its use and makes it available again when appropriate. It schedules processor time between ready tasks and deals with events requiring attention. The detailed scheduling and interrupt mechanisms are taught separately, but their purpose here is resource coordination.

Without that coordination, two applications could overwrite each other's memory or attempt incompatible operations on a shared device. The OS can protect a process's address space and arbitrate access to resources. Applications still contain their own task logic: the editor decides how to format a paragraph; the OS provides the platform and controlled services needed to perform the work.

Consider an editor and a media player running together. The OS gives each working memory and schedules time to execute its instructions. If the editor closes, allocated resources can be released for other work. This explains why “the OS runs programs” is more useful when expanded into what the OS actually allocates and controls.

Managing files and access rights

File management gives stored data a usable organisation through names, directories and operations such as creating, opening, copying, moving, renaming and deleting. The OS and its file system maintain metadata and the relationship between a file's logical identity and the locations holding its data on storage.

A user normally asks to open report.txt, rather than naming each physical storage block. The file service resolves the file and reads the required data. On save it arranges writing and updates relevant file-system information. Storage devices keep the bits; file management gives applications a controlled way to find and manipulate them.

Security services include identifying users, authenticating access and enforcing permissions. Authentication checks who is attempting access; authorisation determines what that identity is allowed to do. A teaching assistant may be permitted to read a class list while only an administrator may change it. The OS can reject a write request even though the application is technically capable of issuing it.

Permissions also protect other resources and processes. They are not a guarantee against every attack: weak credentials, mistakes in permissions or vulnerable software can still create risks. In the class-list example, granting read access to all users would fail the confidentiality requirement even if login itself worked perfectly.

User interfaces and maintenance services

A user interface lets a person request operations and receive information from the system. A graphical user interface presents items such as windows, icons and menus; a command-line interface accepts written commands. Both can invoke file and process services, though the way the user expresses the request differs.

A graphical file manager helps a new user discover files visually and move them with familiar actions. A command line can efficiently express repeated operations and scripted administration, but users must know the command syntax. Neither interface inherently grants more permission: an unauthorised request should be rejected whichever interface issued it.

An OS also supplies or supports utilities for managing and maintaining the system. Examples include backup tools, storage management, monitoring processes and security tools. A backup utility copies selected data to another location so it can be restored after loss. A process monitor shows resource use, helping identify which application is consuming memory or processor time. These utilities use the OS's services; they are different from the user's main application, such as a word processor.

Suppose a laptop is short of storage space. A storage utility can report use and help remove unwanted files; a backup utility provides a recovery copy before valuable data is lost. A graphical interface may make these actions easier to find, but it is the utility and underlying file services that perform the relevant operation.

BIOS and the startup sequence

The BIOS, Basic Input/Output System, is firmware that provides startup instructions before the operating system is running. In the BIOS-style boot model, those instructions are available in nonvolatile memory immediately after power-on. The OS cannot be responsible for loading itself from nothing: an earlier starting mechanism is required.

The BIOS obtains configuration settings and initialises/checks relevant hardware. A power-on self-test (POST) can detect faults and report them, such as an error that prevents usable startup. It then identifies a suitable boot device according to the configured order and begins the bootstrap process. Bootloader instructions load the operating system's kernel into RAM and transfer control so the OS can start its services.

This is a sequence of roles, not a claim that all software is already in ROM. The firmware is persistent; the main OS is commonly loaded from secondary storage into working memory. A missing or unusable boot device can therefore leave firmware able to report a problem even though the OS never starts.

For example, the configured boot order checks a removable drive before the internal drive. If the removable drive has no valid boot software, the firmware can try the next eligible device. If a valid internal bootloader is found, it begins loading the kernel. If no valid source is found, a boot error is consistent with the BIOS still working.

Device drivers between the OS and hardware

A device driver is software that lets the OS communicate with a particular device or supported device family. It translates standard OS requests into the commands and data formats expected by that hardware and returns device information in a form the OS can use.

An application may request printing without knowing the printer's detailed control protocol. The OS routes that request through a suitable printer driver. The driver prepares device-specific instructions and handles information such as readiness or errors. Sharing a common OS interface reduces the amount of device-specific work each application must contain.

A newly connected device may use a compatible driver already present, or may need an appropriate driver installed. If the driver is missing or incompatible, the OS might detect that something is connected but be unable to use its full functions correctly. Physical connection alone does not ensure software compatibility. A driver is also not the same as firmware: firmware runs in or starts the device, while the driver provides the OS's communication software for it.

If a scanner works in one application through standard OS scanning services, another application can use those services without separately implementing the scanner's low-level protocol. The driver connects the shared service to that hardware; the application still decides what to do with the returned image.