A simple note on Programming.

Date : 17/06/2018
Version: 0.0
Status: Just starting.
By: Albert van der Sel
Remarks: It's a very simple note on development environments: A Helicopter View (sort of).

Original location, and where this doc will be maintained: www.albertvandersel.nl

Please refresh the page to see any updates.

The subject is as wide as "Planet Earth" itself, so to speak. For example, you can go "in depth"
in some very specific Dev environment like Java, or DOT NET, or something like that. Then, it might take a few years
to reach senior level. Or, one is totally involved in Interfacing, or Artificial Intelligence etc.. etc..
Knowledge is always a combination of literature, lots of articles, and ofcourse experience (having done projects).

Or, a scientic approach could be taken too, like "formal Information Sciences". But that does
not always seamingly connect to Business environments (that's not always true ofcourse,
and don't take it too literally).

It does not add much, to write a general note on some specific Dev environment, unless you tackle
very specialistic subjects. You see, there are already so many great tutorials, textbooks etc...

However, an approach as a large series of "quickstarts", might not be a bad idea.
And, if I relate modern Dev environments with subjects from infra, databases, middleware and the like,
might not be bad too.

In short: what about a rather "holistic" document, touching a lot of stuff?
Ofcourse, then such an approach can never display enough substance on a certain subject.
But a sort of helicoper tour is possible, surely.

If someone reads it at all, he/she might think that the author is crazy. The collection of subjects
is namely so large, that the "target" here is quite impossible.

I don't think so. Anyway..., I like the idea. I am simply going to do it.

So, it will cover a lot of terrain, but in a non-detailed way.

It would be great if "newcomers" would take a look at it. At least, in Europe, there is
an enormous demand for developers in all sorts of businesses and branches.
If I could contribute something usefull to a "newcomer", that would be more than outstanding.

But, I am just started....

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)