Run-time system

In computer science, the runtime system is software that provides services for a running program but is itself not considered to be part of the operating system.Fact|date=April 2008

Examples include:

* the code that is generated by the compiler to manage the runtime stack.

* library code for handling memory management (for example, malloc).

* code that handles dynamic loading and linking.

* debugger code that is generated at compile time or run time.

* application-level thread management code.

Byte-code interpreters and virtual machines can also be considered runtime systems. Services that run in concurrent processes are more likely to be considered middleware.

.NET Framework

The .NET Framework provides a run-time that is used to interpret intermediate code, code that is compiled from a development environment such as Microsoft’s Visual Studio when the language is C# or Visual Basic.NET. The code requires the run-time in order to execute. The code is referred to as “intermediate” because the result of the compilation is not a result that could be run at the machine level, or in other words to run without the aid of the run-time. The run-time is a service process that provides the framework for the execution of the intermediate code. The run-time acts as an interpreter of the intermediate code and then provides the structure for it to run on the operating system. Lower level capabilities it provides includes memory management, process management, and I/O management. In many cases the run-time is simply providing an abstraction level to the Windows API opening up nearly all of its capabilities to the programmer

The purpose of a run-time is to support the use rapid application development languages, such as C# and Visual Basic.NET. Highly capable run-times, such as the .NET Framework offer significant capabilities and access to the operating system and I/O. This allows a developer to create a powerful application very quickly.

Run-times are not necessarily striving for cross platform compatibility, while run-times such as Sun’s Java might.

Scripting (meta) language interpreters act similar to a run-time, although the code for many scripting languages is not pre-compiled as they are in .NET languages. Pre-compiling speeds up the act of loading the application into memory and also ensures a more compact executable file.

RSTS/E

In the specific context of the RSTS operating system, the run-time system (RTS) was a piece of resident code which was mapped into the high end of the address space of a process, which could be called on to provide services to a running program, or used as the command line interpreter (CLI) user interface. The term in RSTS for a command line interpreter was keyboard-monitor (KBM). This term should not be confused with the similar term keystroke logging.

RSTS did not itself define any standard filename extension for an executable program file; instead, each installed RTS defined its own extension, and the appropriate RTS was loaded depending on the actual name of the program file. If the user issued a command to run a program without specifying the extension, then the system went through all installed RTSs, trying each corresponding extension in turn until it found the name of an existing program file.

The actual responsibility for loading and executing the program was left to the run-time system; thus, users could run interpreted programs just as easily as ones that were compiled into actual machine code, provided that the interpreter was appropriately implemented as a run-time system. The standard BASIC-PLUS RTS provided a compiler, interpreter and KBM all packed into just 32kiB of code. And indeed many of the standard system utility programs (including privileged ones like LOGIN and LOGOUT!) were written in BASIC-PLUS.

Other RTSs provided partial emulation facilities, allowing some simple programs written for the RT-11 and RSX-11 operating systems to run under RSTS. An intereting note is that not all RTS's were designed as KBM's, however most all KBM's were implemented as RTS's.

Under RSTS, the TECO editor was implemented as an RTS, though its KBM function was a stub which loaded a program with a predefined name which had to be provided by the user. This allowed the user to implement their own KBM.

Even a version of the Space Invaders video arcade game was eventually implemented as a multi-user RTS (driving VT52 video terminals).

See also

* Runtime