Operating System

Development
Lecture-2

Preface

Introduction

Before moving on with the course,

we should cover our chosen languages, and
what is required.
along with an overview of important concepts
in the languages, and how to work with them.

This course uses C and x86 Assembly

Language.
It is very important to have a good
understanding of both of these languages
before moving on

Overview of C

It is assumed that you already know

how to program in C.
This is a quick overview of some of
the more important parts of the
language, and also how they will
work for us.

How to use C in kernel land

16 bit and 32 bit C
In the beginning of programming your system you will
find out that there is nothing at all to help you.
At power on, the system is also operating in 16 bit real
mode which 32 bit compilers do not support.
This is the first important thing:
If you want to create a 16 bit real mode OS, you must use a 16
bit C compiler.
If, however, you decide that you would like to create a 32 bit
OS, you must use a 32 bit C compiler.

16 bit C code is not compatible with 32 bit C code.

In the course, we will be creating a 32 bit operating
system. Because of this, we will be using a 32 bit C
compiler.

Real mode vs Protected

mode
If your computer is in real mode, software
communicates directly with the
computer's ports and devices.
For example, when you print a document, the
software sends the data stream directly to the
port that holds the printer.
However, this paradigm doesn't work in a multitasking
OS.
Imagine what would happen if multiple programs sent
data streams to the ports simultaneously. Ports are
dumb, and they have no ability to filter or arrange
data streams to match the sending programs.

 If your computer is in protected mode, the

system's ports and devices are protected
from the applications that use them.
The software thinks it's sending data to a port,
but it's a virtual port.
The OS is grabbing the data stream and
managing it, to ensure that all applications
have equal access and to ensure that data
from each application is appropriately
preserved.

C and executable formats

A problem with C is that it does not
support the ability to output flat
binary programs.
A flat binary program can basically
be defined as a program where the
entry point routine (such as main()
) is always at the first byte of the
program file.
Why would we want this?

 This goes back to the good old days of DOS COM

programming.
DOS COM programs were flat binary - they had no
well-defined entry point nor symbolic names at
all.
To execute the program, all that needed to be done
was to "jump" to the first byte of the program.
Flat binary programs have no special internal
format, so there was no standard. Its just a bunch
of 1's and 0's. When the PC is powered on, the
system BIOS ROM takes control.

 When it is ready to start an OS, it has no

idea how to do it
Because of this, it runs another program the Boot Loader to load an OS.
The BIOS does not at all know what internal
format this program file is or what it does.
Because of this, it treats the Boot Loader as
a flat binary program. It loads whatever is
on the Boot Sector of the Boot Disk and
"jumps" to the first byte of that program file.

 Because of this, the first part of the

boot loader, also called the Boot Code
or Stage 1 cannot be in C.
This is because all C compilers output a
program file that has a special internal
format - they can be library files, object
files, or executable files.
There is only one language that natively
supports this - assembly language.

Pointers

Introduction
In system software, they are used
everywhere. Because of this, it is
very important to master pointers.
A pointer is simply a variable that
holds the address of something. To
define a pointer, we use the *
operator:
char* pointer;

 Remember that a pointer stores an "address"?

We do not set the above pointer to anything, so what
"address" does it refer to?
The above code is an example of a wild pointer.
A wild pointer is a pointer that can point to anything.
Remember that C does not initialize anything for
you.
Because of this, the above pointer can point to anything.
Another variable,
address 0,
some other piece of data,
your own code,
a hardware address.

The Physical Address Space (PAS)

The Physical Address Space (PAS) defines all

of the "Addresses" that you can use.
These addresses can refer to anything that
is inside of the PAS.
This includes physical memory (RAM),
hardware devices, or even nothingness.
This is very different then in applications
programming in a protected mode OS, like
Windows, where all "addresses" are
memory.

 Here is an example. In applications programming, the

following would cause a segmentation fault error and
crash your program:
char* pointer = 0;
*pointer = 0;

This creates a pointer and points it to memory

address 0, which you do not "own".
Because of this, the system does not allow you to
write to it.
Now, lets try that same exact code again in our future
C kernel ... no crash! Instead of crashing, it overwrites
the first byte of the Interrupt Vector Table (IVT).

 From this, we can make a few important differences:

1. The system will not crash if you use null pointers
2. Pointers can point to any "address" in the PAS, which
may or may not be memory

If you attempt to read from a memory address that

does not exist, you will get garbage (whatever was
on the system data bus at that time.)
An attempt to write to a memory address that does
not exist does nothing.
Writing to a non existent memory address and
immediately reading it back may or may not give
you the same result just "written"...It depends if the
data "written" is still on the data bus or not.

 Things get more interesting here.

ROM devices are mapped into the same PAS.
This means that it is possible for you to read or write
certain parts of ROM devices using pointers.
A good example of a ROM device is the system BIOS.
Because ROM devices are read only, writing to a
ROM device is the same effect as writing to a non
existent memory location. You can read from ROM
devices, however.
Other devices may also be mapped into the PAS. This
depends on your system configuration. This means
reading or writing different parts of the PAS may yeild
different types of results.

 As you can tell, pointers play a much

bigger role in systems
programming then they did in the
applications programming world.
It may be easier to think of pointers
not as a "variable that points to a
memory location" but rather a
"variable that points to an
address in the PAS" as it may or
may not be RAM.

Dynamic Memory Allocation

In the application programming world, you would normally
call malloc() and free() or new and delete to allocate a
block of memory from the heap.
This is different in the system programming world. To
allocate memory, we do this:
char* pointer = (char*)0x5000;

Because we have control over everything, we can just

point a pointer to some address in the PAS (would have to
be RAM)
The important thing here is that there is no dynamic
memory allocation.
Dynamic memory allocation in C and C++ are system
services and require an OS to be running.

Inline Assembly

There are some things that C cannot

natively do.
We will be needing to use assembly
language for system services and
talking to hardware devices.

Standard Library and the Run Time Library (RTL)

The RTL is the set of services and

routines that your application
program uses at run time.
These, by their nature, require an OS
to already be running and to support
them.
Because of this, you will need to
develop your own RTL.