What Is an Operating System?
An operating system is the software that controls the overall operation of a computer. It provides the means by which a user can store and retrieve files, offers the interface through which programs can be requested and launched, and creates the environment that makes program execution possible.
You interact with an operating system every time you use a computer — when you open a file, switch between applications, connect to a network, or plug in a device. Most of that interaction is invisible precisely because the OS is doing its job well.
But operating systems did not start out sophisticated. They grew — slowly, in response to real problems that people encountered when trying to get useful work done on expensive machines. Understanding that growth is the best way to understand why modern operating systems work the way they do.
The Beginning: No Operating System at All
The computers of the 1940s and early 1950s had no operating systems. Each program was a completely isolated event. Running a program meant physically preparing the machine: mounting magnetic tapes, loading punched cards into card readers, setting switches on the front panel, and then waiting. When the program finished, everything had to be cleared and reset for the next one.
Each program execution was called a job. When several users needed time on a machine, they signed up for blocks of time. During your reserved slot, the machine was entirely yours. The session usually began with setup, followed by a brief period of actual computation, while the next user was already waiting impatiently to take over.
The bottleneck in the process was the human task of computer preparation rather than the actual computation. This was enormously wasteful for hardware that cost more than most buildings.
The First Operating Systems: Batch Processing
The first operating systems were built to solve exactly this problem: reduce the time the machine spent waiting for humans to set things up. The key innovation was separating users from the machine entirely.
Instead of each user operating the machine directly, users submitted their jobs to a human computer operator — a trained technician whose job was to run the machine on behalf of everyone. Users dropped off their programs (on cards or tapes) along with instructions for how to run them, and came back later to pick up their results. The human operator loaded these materials into the machine's storage where the computer's very basic OS would read and execute each one at a time.
This approach is called batch processing: collecting jobs into a group (a batch) and executing them sequentially without interruption or user interaction.
Jobs waiting to run were held in a job queue. A queue is a storage organization where items are ordered in first-in, first-out (FIFO) fashion — the first job submitted is the first job executed. In practice, most job queues allowed some priority exceptions (an urgent payroll run could bump a lower-priority research job), but FIFO was the default principle.
Analogy: Think of batch processing like a dry cleaner. You drop off your clothes with instructions, go away, and come back later for the results. You have no interaction with the process while it is running. The cleaner handles everything in the order received. This works perfectly for shirts and slacks — but not so well if you need something urgently and want to watch it happen.
Batch processing was a genuine improvement over the chaos of individually scheduled machine time. But it had a fundamental limitation: the user had no interaction with their job once it was submitted. This was acceptable for tasks like payroll processing — where all the data and decisions were established in advance — but completely unacceptable for anything that required back-and-forth with a human.
Interactive Processing and Real-Time Demands
As computers began to be used for more than payroll and scientific calculation, new demands appeared. Reservation systems needed to respond immediately as bookings came in. Word processors needed to display characters as they were typed. Games required instant responses to player input.
These needs required interactive processing: a mode in which a program being executed could carry on a dialogue with the user through a terminal. Early terminals were little more than electronic typewriters — the user typed input and the computer printed its response on paper. But they enabled something batch processing could not: a conversation.
Interactive processing also introduced a new constraint: real-time processing. A computer performs a task in real time when it responds within the deadlines imposed by its environment. If a word processor takes three seconds to display a character after you type it, the system has failed its real-time requirement — regardless of whether the character eventually appears correctly.
Time-Sharing and Multiprogramming
Interactive processing created a new problem. Computers in the 1960s were expensive — a single machine might serve an entire university or corporation. If interactive processing required dedicating the machine to one user at a time, the economics were terrible: most of the time, the machine would be waiting for the user to type the next character.
The solution was time-sharing: designing operating systems to serve multiple users simultaneously by rapidly switching attention among them. When one user paused to think or type, the machine could be doing useful work for someone else.
The technical mechanism that makes time-sharing work is multiprogramming: dividing time into short intervals and restricting each job to one interval at a time. At the end of each interval, the current job is temporarily set aside and another is allowed to run. By shuffling jobs back and forth quickly enough, the system creates the illusion that several programs are running at the same time — even though only one is actually using the CPU at any given moment.
When multiprogramming is applied to a single user running multiple applications simultaneously (rather than multiple users sharing a machine), it is called multitasking. Today, multitasking is what allows you to have a browser, a word processor, a music player, and a video call running at the same time on your laptop — the CPU is switching among them so fast that all of them feel responsive.
Time-sharing vs. multitasking: The terms are related but distinct. Time-sharing refers to multiple users sharing a single machine. Multitasking refers to one user running multiple tasks simultaneously. Both use multiprogramming as the underlying technique.
Everything Old Is New Again
Here is where the history gets interesting — and surprisingly relevant to the computers you and your students use today.
The time-sharing era produced a particular hardware model: a large, powerful central computer connected to many terminals. The terminals were simple input/output devices with no real computing power of their own. All the actual computation happened on the central machine. Users interacted with it remotely.
Then, in the late 1970s and 1980s, something changed. The personal computer arrived. Suddenly, affordable machines were powerful enough to run a full operating system independently. The central computer became unnecessary for most tasks. Every desk got its own complete computer. The thin terminal was replaced by the personal computer, and the computing world moved from centralized to distributed.
But look at what has happened since. Over the last two decades, the pendulum has begun to swing back. Your phone is powerful, but when you use Google Docs, your document lives on Google's servers — not on your device. When a company runs its software on Amazon Web Services (AWS), the computation is happening on remote servers, not local machines. When your students use a school Chromebook, the device is deliberately lightweight — much of what it does depends on the network and remote servers.
We have, in important ways, returned to models from the 1960s and 70s. The "central computer" is now a data center somewhere, accessible over the Internet rather than a dedicated network. The "terminal" is now a sleek laptop or smartphone. But the fundamental architecture — lightweight client, powerful remote server — is strikingly familiar.
The history of computing is not a straight line from simple to complex. It is a series of pendulum swings between centralized and distributed, between shared resources and personal ownership, between the server and the device.
Understanding this history matters for CS teachers because it gives students a frame for understanding why things are the way they are — and for anticipating where things might go next. The architectural decisions embedded in today's cloud services are not new inventions. They are rediscoveries of solutions that were worked out, discarded, and worked out again over seventy years of computing history.
What Comes Next
Reading 2 moves inside the operating system itself — looking at the components that make up a modern OS and what each one is responsible for. The history you just read will make those components easier to understand: each one exists because someone, at some point in the history above, encountered a problem that needed a solution.