What really is the "runtime environment"?

Question

This is a very basic question but is something I've never completely understood and recently, when studying .NET Core and ASP.NET 5 I felt the need of a more complete understanding of the topic.

Reading the article Introduction to the Common Language Runtime (CLR) there we find the following piece of text:

Every program has a surprising number of dependencies on its runtime environment. Most obviously, the program is written in a particular programming language, but that is only the first of many assumptions a programmer weaves into the program. All interesting programs need some runtime library that allows them to interact with the other resources of the machine (such as user input, disk files, network communications, etc). The program also needs to be converted in some way (either by interpretation or compilation) to a form that the native hardware can execute directly.

Now, this idea of runtime environment seems to be very basic, but still very important, not just when working with .NET but when dealing with programming in general. It seems to be a general concept which is quite important to understand.

Until today I always had one intuitive and simple understanding about it: runtime environment is the environment on which the code will run. But this is a quite loose way to understand it. There is probably much more to it as can be infered from the above text.

In that setting: what really is the runtime environment in general? Not just for .NET, but in programming in general, what is the runtime environment? Is it just something conceptual or is it some piece of software, like the CLR for .NET? In summary, how should we properly understand the idea of runtime environment?

Answer 1

There are a few components that make up the runtime environment. Not all components are applicable to all environments (e.g. assembler, C++, and C# all have different runtime facilities), but they generally comprise the following:

• The CPU and hardware platform on which the program runs.
• The operating system that runs the program, including device drivers that interface with the hardware.
• Standard libraries available to the language and platform. Certain environments (e.g. embedded) may pare down the relevant standard library due to space concerns.
• Frameworks and other libraries linked into the program either statically or dynamically.
• Any interpreter that sits between the program and the operating system, such as the CLR, JVM, shell (for e.g. a Bash script), Perl/Python interpreter, et al.

Remember, computers are all about layers and abstractions. As you can gather from the list above, a runtime is pretty much a collection of abstractions that sit between the bare metal and the running program.

Answer 2

TL;DR answer:

The Runtime Envionment is a somewhat nebulous term which collectively refers to the virtual machine in which your code runs, and the standard libraries and services that your code may expect to find available to it. It can also be thought of as a layer of isolation between your code and the underlying operating system, so that your code can be agnostic of it, and therefore portable.

The long answer:

In the (not so good) old days when FORTRAN and COBOL ruled, the language was also the Runtime Environment. Most applications were built using whatever features the language provided, and that was enough. As a result, the syntax of the languages was very complex, and still the stuff that you could do with them were limited to whatever the authors of the language could imagine at the time that they were creating the language: accessing files and databases, reading and writing characters to and from terminals, and that was pretty much it.

When C came out, it made a clear distinction between the language and the Runtime Libraries. The C language itself is extremely minimalistic, offering only the bare essentials necessary for expressing program logic, and delegating everything else to be done by libraries. The standard libraries provide commonly used stuff, and you can add external libraries for anything else.

For example, the C language has no built-in concept of memory allocation; in order to allocate memory you have to invoke malloc(), a standard library routine. And if malloc() is not good enough for you, then you can use some other library that offers something that better suits your needs. The standard runtime libraries were the precursor of runtime environments, but things were not really there yet, because back in the days of C the Unix operating system was mostly playing the role of the runtime environment, so there was no concept of portability: according to the Unix world, the Unix world was the only world.

When the portable, virtual-machine-based languages like Java and C# came out, there was a need to provide an additional layer of isolation between applications and the underlying operating system, so that applications could run either on Unix, or on Windows, or on anything else. That was provided by the virtual machine and the rich set of libraries that it came with.

Answer 3

what really is the runtime environment in general?

Yes, your broad understanding "runtime environment is the environment on which the code will run" is about as specific as that term will be defined.

Not just for .NET, but in programming in general, what is the runtime environment?

Effectively, the hardware your code is running on. The OS your code is running on. The libraries made available to your code when running. The environment variables that your code has access to. The locale your program is running in. (If applicable) the JIT compiler/byte-code interpreter/garbage collector/sandbox/app server your code is running on.

In summary, how should we properly understand the idea of runtime environment?

It varies from job to job. Many programs don't care very much at all, because it doesn't really matter. Some programs need to care a great deal, because the platform their running on doesn't do a great job at abstracting away hardware differences, or because the code will vary its behavior depending on the environment it's running in.

But as a term, knowing "runtime environment" generally refers to the intermediary "stuff" needed to run managed languages like C# and Java is sufficient.