1. A perspective from the Operating System.

1.1 User space and Kernel space.

Most developers "work" or are occupied in "user space", which is where on a machine (or computer),,
ordinary (or regular) programs live. These programs are often Business applications, personal software, but
ofcourse can be from any domain (like scientific applications).
These are applications created by for example Java, Visual Basic, C++, dot NET (like C#) and
countless other dev environments.

Typical for such application is, that fundamental system services (like the call to open a certain file),
is handled by calling a service or function from the Operating system.
Therefore, equally typical, those applications use various Application Program Interfaces or API's
which form a layer between the application and the Operating System.

On many machines, the most fundamental API is synonym to the "System Call Interface".
System calls then, are calls to functions of the OS which perform fundamental services,
like IO, memory management and the like.

Fig 1: Just an illustration of a perspective from a generic OS.


Source: my own Jip and Janneke figure.

The figure above, is quite generic. It can model most general purpose Operating Systems.

On the other hand, kernel space programs or modules, can be "privileged". That is,
they either perform privileged instructions themselves, or call them directly from other modules.
Indeed, since kernel space programs, services "user mode" programs with providing direct access
to IO, memory and other devices, they are called "privileged".

For security reasons, and stability of the system, it is never allowed to have a user program
to access those fundamental devices themselves: they must use the services of the Operating System.

I hope that this theory, shows a bit from figure 1.

To make the various API's a bit more concrete, we can take a look at a modern Windows Operating System.
Please take a look at this file (only the first image is important).
Here you can see various API's, forming indeed an "interface" for various user mode programs.

For example, the traditional Visual Basic, C++ programs etc.., use the Win32 API, formed by various dll's
which together provide a wealth of callable functions and procedures (dll's like user32.dll, GDI32.dll etc..).

As another example, something called "a Native application" (not much used), calls functions of
the true System Call Interface directly (ntdll.dll).

Still, as another example, "App store" applications, use the services provided by something
which is called "WinRT".

For this section, the details are not very important. The purpose was the shed some light
on a specific view on Applications (or modules), namely "user mode" and "kernel mode".

1.2 How programs run.

Ofcourse, this also depends on which OS you want to run your program.
Many developers work on Windows- or Linux platforms. These will be my main example
platforms in this note. Needless to say that there exists many other platforms as well.

Anyway, on Linux, the "ELF" format is often used as the internal format of a binary executable.
On Windows, the "PE" format is the common format of a binary executable.

These are however not only formats in use.

⇒ Umanaged code, not using a Domain or VM container (jvm, CLR, DomainApp)

Let's first take a look at traditional code (unmanaged), like created with older
compilers, before .NET became popular.

Both formats (ELF, PE), when considered in detail, are fairly complex. However, when using a birds-eye view,
we can say the following:

Such files have several headers and several sections, as they are structured in the file.

Section might be labeled as ".text", and these ones actually contains code.

Other sections are called ".data" and are reserved for variables, which the code will use.

Some headers will contain the metadata, how to load and reserve memory of such sections.

Let's take a look at the Windows PE format. Actually, we have the PE32 and PE32+ formats,
for the 32- and 64 bits platforms, resepctively.

If we take a very rude look at the Win32 PE header, then it actually starts with a DOS section,
with simple code which prints a message "This program cannot be run in DOS mode",
if you would indeed to try to run it from 16 bit DOS. Then, the loading would terminate.

From running from Windows, the DOS stub is followed by a pointer to the PE header.

Then following are headers with lots of metadata. We are not going to list such headers,
but for the loader it contains information on which subsystem this executable should run. Thats just an example.
Then following, is metadata on the .text sections, which tells which section, for example,
has the property "The section is not pageable". Many of such properties are listed.

The main points is: All PE files have a set of headers, followed by a set of sections.

After all code and data sections are loaded, then finally the eip/rip register
is loaded with the address as listed in the "AddressOfEntryPoint" field in the PE header.
Such register will alway contain the address of the next instruction, and thus,
your program gets control.

⇒ Managed code using a Domain or VM container (jvm, CLR, DomainApp)