In the previous section we explored hardware, but it was nearly impossible to avoid mentioning software: the programs that run on the hardware.
Software and hardware are co-dependant and rely on each other to make computers "work".
There are essentially two types of software:
Application programs (or applications or more affectionately, apps) are designed to interact with users.
System programs are designed to work in the background to operate the computer.
The vast majority of an application program is made up of instructions. A popular method to visualize how a program's instructions "flow" is to use a flowchart.
Flowcharts have had a remarkable resurgence due to humorous internet memes.
The CPU instructions in a program are not as colourful as the instructions you have probably seen in flowcharts. The instructions are the really basic operations that CPUs understand (addition, subtraction, greater than, etc.) known as "low level" operations.
When programmers write and design programs, they rarely ever write programs at such a low level. They use powerful "high level" programming languages that are easier for humans to understand. Later in this course, we will be introduced to a high level web programming language known as JavaScript.
For perspective, a very high level program for a human might be:
eat a sandwich
A lower level program might look like:
repeat until sandwich is gone: open mouth put portion of sandwich in mouth close mouth repeat until food is fully masticated: chew swallow
For the brain, even the instruction open mouth is very high level.
At the low level of the brain, open mouth might be a sequence of very detailed instructions such as:
send a nerve impulse to contract the lateral pterygoid mouth muscle
The high level instruction eat sandwich might be translated into thousands of low level nerve impulses or "brain instructions".
To build a program, programmers typically use a "machine translator" to convert their high level instructions into thousands of low level machine language instructions.
While most programs are built this way, there are alternative approaches. In a few modules we will be using the application program Microsoft Excel. It is debatable whether or not an excel spreadsheet is itself a "program", but for the sake of argument, we will say that it is. In Excel, you can write a spreadsheet ("program") using a high level language that looks something like this:
=SUM(B1,C1)
At the United Nations there are people who are real-time translators (e.g., English to German) and there are even now real-time smartphone apps that can translate spoken languages.
Excel is effectively a "real-time translator" that converts your high level language to machine language.
Using our brain analogy, Excel converts eat a sandwich to thousands of nerve impulses in real time.
Later, when we use JavaScript, the web browser will perform the real-time translation.
The advantage of using a real-time translator is that a program is no longer machine-specific and can run on any machine where a translator exists. This approach is used to build Android apps, which is why Android can be run on so many different kinds of devices.
This real-time translation can also support legacy hardware. For example, there are real-time translators known as hardware emulators that will allow you to play video games developed for old hardware. It is very difficult to obtain the hardware capable of playing the original Donkey Kong, but now you can run an emulator on your computer (and even in your web browser) to play the original game.
Earlier we stated that the vast majority of an application program is made up of instructions, but there are three different components:
The data included in an application include text and multimedia. For example, a video game application would have to store all the graphics (pictures) and sound files needed to play the game. Even very boring, straightforward programs need to store the text (words) for the menus and the messages to display to the user.
In addition to CPU instructions, an application can also make operating system requests. If you recall, the CPU can only access primary memory and cannot directly access secondary storage or peripherals. If an application wants to interact with secondary storage or a peripheral (and pretty much every application does), it must do so via the operating system.
We discuss operating systems below, but it is important to consider that applications are typically built for both a specific machine and a specific operating system. If you have a Windows application built for an Intel machine, it cannot run directly on a Mac Intel machine. Just like there are hardware emulators there are also operating system emulators that attempt to do real-time translations of operating system requests.
While application programs are designed to work in the foreground and interact with users, system programs are designed to work in the background.
Some system programs designed to work without any user intervention are known as services. A familiar example might be a social media application that also installs a service to check for notifications. The service may start automatically when the computer turns on, and when a notification is detected, it can send a message to the operating system to alert the user. The user might receive the alert and then launch the full application to read the notification and interact with the social media.
Another type of system program we described earlier is a device driver, which is designed to facilitate communication between a peripheral and the operating system.
But the most important system program is the operating system itself.