Unix

Unix is the first operating system built upon a high-level language (obviously a
high-level language at that time), C. If the developers at Bell Labs had thought
to use something else to create Unix, then C might not have come into existence.
While C wasn’t exclusively created for Unix, its development was significantly
intertwined with the creation and success of the Unix operating system.

Multics OS
Before Unix, there was another operating system that focused on the same
objectives of being fully functional and secure. Multics OS, even Bell Labs con-
tributed to this project. MIT and General Electric were two other contributors
to this project.
Almost every organization and university was using Multics at that time. Even
now, its ideas are inherited indirectly by every operating system from UNIX.
Bell Labs eventually moved away from the Multics project due to its complex
design and other factors. This decision ultimately paved the way for the devel-
opment of Unix, which has had a profound impact on the computing world.

0.0.1 Multics Downfall

Multics was quite heavy on resource consumption. It also had a complex design.
Despite these differences, Unix still uses the onion architecture as its internal
structure and other utility programs.

Programming Language C
0.0.2 Inspiration for C
Bell Labs initially wrote Unix in assembly. However, as part of the Multics
project, they were introduced to BCPL as a compiler design language. They

1
saw that Multics was not built upon assembly but was using Pl-1. While BCPL
was not a central language used in the Multics project, it did influence the
developers at Bell Labs, including Dennis Ritchie, who went on to create the C
programming language. C, in turn, played a significant role in the development
of the Unix operating system.
BCPL needed a few modifications to work with minicomputers. This simplified
version of BCPL is called ’B’. It improved and was able to write programs for
minicomputers as well. Eventually, C was introduced as a perfect language with
versatility and portability.

0.0.3 The Path to C

As mentioned earlier, B was typeless. It operated on ’pages,’ which made it
restricted to individual architecture. Every architecture had its own alternative
code for the same operation. Even though later it was enhanced and termed as
’New B,’ it still lacked the functionality of being independent of architecture.
C addressed these problems and became portable and versatile. When we talk
about portability for a programming language, we mean a single source can be
used on multiple architectures. When we use the term versatile, we mean that
this language can be used to design many distinct components of computer sci-
ence, like compilers, operating systems, user applications, system applications,
kernels, and device drivers.

0.0.4 Limitations of B
ˆ B operated on words.
ˆ B wasn’t aware of different types.
ˆ B could not work on multiple byte-oriented algorithms.
ˆ B was not able to perform floating-point operations.

0.0.5 A De Facto Programming Language

This section effectively highlights the key characteristics and advantages of the
C programming language:
1. Versatility and Compatibility: The language is lauded for its ability
to work with machine instructions regardless of the target architecture.
Its balance between being a high-level and low-level language makes it
suitable for various programming tasks.
2. Paradigm Adaptation: C can seamlessly adapt to different program-
ming paradigms while still providing insight into its machine interpre-
tation. This adaptability sets it apart from certain modern high-level
languages.

2
 3. Low-Level Accessibility: Unlike some modern languages that create an
additional layer of abstraction, C allows programmers to access low-level
implementation details without imposing barriers.

Unix Architecture
0.0.6 Philosophy
While Multics was ambitious in its goals, including a secure and fully func-
tional time-sharing operating system, hierarchical file system, virtual memory,
dynamic linking, and more, these goals made the Multics project complex. It
was being developed simultaneously by multiple organizations, making it even
more intricate.
On the other hand, Unix kept it simple. It primarily focused on providing a
minimal operating system with simplicity and practicality. It believed in making
programs for specific tasks, which, in programming terminology, is referred to as
modularity. Over time, Unix incorporated ideas and concepts from the Multics
project, adapting them to fit its simpler and more practical philosophy.
The following are the philosophies that C adapts:
1. Unix primarily focuses on programmers, not end-users.
2. Unix is composed of small, simpler programs.
3. Unix is text-oriented; even every single configuration is a text file.
4. Complex programs can be made using chains of small programs. These
programs are termed transformer programs.
5. One program should accept the output of another program and provide
output.
6. It does not provide perfect programs, but it does provide simple programs
to perform the same task more efficiently.
7. Unix programs can be used in other Unix-based OS.
The key concept of C philosophy is modularity, and all these modular programs
as part of C are written in C, which makes them closely related.
C was designed to support modular programming, which involves breaking down
a complex problem into smaller, manageable modules or functions. These mod-
ules can be developed, tested, and maintained independently, contributing to
code reusability and easier collaboration.
C’s modularity and the modular design of the Unix operating system contributed
to their success and their close relationship. Many of the core utilities and
system components of Unix were written in C, taking advantage of its modular
programming capabilities.

3
0.0.7 Unix Onion
The onion architecture refers to the layered structure of Unix. This architecture
separates the operating system into different layers, with each layer building
upon the functionalities provided by the lower layers. This modular design made
Unix more manageable, maintainable, and extensible. It’s fascinating how this
architectural choice has stood the test of time and remains a fundamental aspect
of Unix’s internal structure.
Each layer is a wrapper for the inner layer. Each layer provides an abstraction
for using hardware without being dependent on the architecture. The innermost
core of this model is hardware. The kernel provides a layer upon hardware and
an interface to work with system calls. The kernel layer is the closest among
all others. It has the highest privileges to use hardware. This is why we need
another layer; we don’t want to expose such critical privileges directly to user
space.
The layer implemented over the kernel is the shell. It provides several small
modular programs, each designed for a specific purpose, and these are also writ-
ten in C. It contains system libraries as well as their implementation functions.
The functions they contain are defined by the Simple Unix Specification (SUS),
making them Unix-compliant Operating Systems.
Lastly, there are user applications that are built using libraries provided by the
shell instead of making direct system calls to the kernel.

0.0.8 Shell Ring to User Application

Almost every user works with the GUI or CLI of an operating system; it contains
applications that are built upon these system libraries. This extra layer makes
these applications compatible with or without slight changes to other Unix-like
or Unix-compliant systems. The declaration of these libraries is the same for
all operating systems, but the implementation of these functions differs from
one another. The standards we talked about earlier do not define any specific
implementation that they had to follow. They just look for the declaration with
the same signature as their standards.
Every Unix-compliant OS should follow the standards of the Simple Unix Spec-
ification (SUS). It also declares a minimal version of this standard library, cat-
egorizing them as Unix-like operating systems. These Unix-like operating sys-
tems are also called POSIX-compliant operating systems. Linux is the most
famous example of these operating systems, while BSD is an example of a Unix-
compliant operating system.
APIs provided by the shell ring:
1. System Interfaces: It contains the implementation of various functions for
the Header Interfaces. There are 1191 functions.

4
 2. Header Interfaces: It contains declarations (APIs) for these functions.
There are 82 header files for the standard SUS.
3. Utility Interfaces: It consists of 160+ programs written in C for small
specific tasks. They implement the above two interfaces for their func-
tionality.
4. Scripting Language: It provides support to make shell scripts to automate
tasks using Utility programs.
5. Xcurses Interfaces: It provides a simple graphical interface in the command-
line interface without using any graphical engine.

Points to Be Noted:
ˆ System Interfaces and header interfaces together make up the C standard
library (libc).
ˆ Applications made for Unix-compliant operating systems can be ported
to another Unix-compliant OS, but it can’t be guaranteed to work on
Unix-like operating systems.
ˆ The user application’s request will be passed down to the kernel using
interfaces provided by the shell ring.

0.0.9 Shell Ring to Kernel Space

When we use the interface provided by the shell ring, usually referred to as the
C standard library, we are using these functions from libc to make system calls
on the kernel space. System calls are functionalities provided by the interface
of kernel space to work with its underlying components.
We can see these sys calls made by our executables by using truss in Unix-
compliant OS and strace in Unix-like OS.
What actually happens is we use syscalls exec() and fork() to start a process
by using components provided by the kernel referred as the memory manage-
ment unit (MMU). This unit provides our process virtual addresses and other
functionalities such as IPC and scheduling.

0.0.10 Kernel
Kernel space is an abstraction over hardware. It represents a layer between
hardware and processes, preventing direct hardware access. Kernel images are
loaded by the bootloader, initializing a kernel process in main memory. This
kernel process interacts with actual physical addresses, whereas user processes
work with virtual addresses corresponding to physical addresses.
Different abstracted components are created within the kernel process:

5
 Figure 1: User interacting with hardware

ˆ MMU/Scheduler: This component handles virtual memory allocation

for user processes onto real memory addresses.
ˆ Filesystem: It provides an abstraction for all block and character devices.
ˆ Devices: This component abstracts all connected hardware, including
peripherals.
ˆ Networks: It abstracts network-related devices, both physical and vir-
tual.
ˆ Device drivers: This component serves as an interface for peripheral
devices, filesystem devices, and network devices.
Key features offered by kernel space:
1. System Startup: Every system provides a user space later used by user
applications. This space is created by the ‘init‘ system call to the kernel.
2. Process Management: Each user application has its dedicated process
managed by kernel space. Processes use memory, interact with instruc-
tions, and dynamic linkages, all managed by kernel space.
3. Memory Management: The kernel manages real physical memory ad-
dresses, providing virtual addresses to processes along with abstraction.
These virtual addresses correspond to physical addresses and are real for
processes.
4. Scheduling: Scheduling balances CPU usage among multiple processes
during multitasking.

6
 5. Inter-Process Communications: Processes share data through sock-
ets, pipes, or shared memory.
6. Device Management: Apart from CPU and memory, the kernel man-
ages hardware using an abstraction layer. Real and virtual devices are
both handled.

0.0.11 Hardware
Linux provides abstracted interaction with hardware. Hardware attached to
the system can be categorized as mandatory and peripheral hardware. Linux
only needs mandatory hardware; peripherals don’t halt Linux from running.
Mandatory hardware, CPU, and memory are used by the scheduler and memory
management unit, respectively. Besides that, all peripheral hardware can be
found as devices in /dev.