(noun) Short for "runtime library", a term from the world of computer programming for a collection of routines that will be used by a program. So called because this library is not part of the program but is called on when the program runs, i.e. "at runtime".

Runtime is defined as the period of time during which a program is executing. The are a number of potential problems that could arise during runtime that do not show up during compile time. However, some of the mechanisms that cause these problems have their own benefits, so they are tolerated. Let's take a closer look at what runtime is and you get some background for your programming endeavours.

Runtime? Walktime? Uptime, downtime, red fish, blue fish...
I'm sure there are many people out there that are unaware of any differences between their computers' programs at rest and at work. Thankfully, It's hard to go back to reality after 10 hours of coding I just came out of a four day code dive], so I can help out.

Where a program is not being run, it lies on your disk as latent bits, swirling 'round. When the binary executable is run, the operating system begins a loading process that brings the program code into memory--the program is now known as a process. We have achieved runtime!

Running all the way
A lot of stuff happens when a process is created. A linker is called by the operating system to match gaps in the binary executable which correspond to libraries. Unless you write your entire program in assembler, chances are you have used a library written by someone else to provide some function to your program. For example:

#include <stdio.h>
int main(int argc, char **argv){
printf("Cool Man Eddie says Hey, Junkill just cooled The Lord's Prayer: l337, baby!");
return EXIT_SUCCESS;
}
The function printf is contained in the stdio library. You don't have know anything about stdio ("standard I/O") to use what's inside--just make the proper calls. The linker will grab the stdio library and plug it into the unresolved addresses in the program's code.

Like, why bother?
There are several good reasons to allow for runtime library inclusion. Microsoft actually did something right with the way it named libraries in that they are appropriately descriptive. Those .dll files are the libraries, specifically "dynamic link libraries." This means that the linker connects the dots between the executable code and library code at runtime. Thanks to dynamic linking, a computer can be loaded with a number of libraries that are shared by all programs. This helps keep down the overall size of the various programs since they no longer need to include common libraries. Similarly, new development can be focused on a single library which provide increased or more efficient functionality to every program that uses the library.

There are some advantages of static linked libraries, depending on what decade you're living in. Some of you out there may not appreciate the idea of keeping down program size--you were obviously never up at 2 a.m. trying to download MSVBVM50.DLL. On 14.4. Welcome to DLL Hell.

For those of us that do remember, we also recall clock speed, a number that means less and less as the years go by. The benefit of using a static link library is that the code can be transplanted from the library into the executable file during compile time. So if you built your own input/output library and included that into your current project, you could not have to recompile the I/O library unless you changed something in the library itself. As the size of your code increases or your clock speed decreases, compile time because more and more tedious. Work backwards with Moore's Law to find out how much processing power was available in 1990 and you'll understand why it was a good idea to compile as little as possible.

Another benefit exists for software developers. A company may be able to produce a library that they market to other companies. Because the library is already compiled, the client companies cannot just copy the source code and steal the developer's work. However, the library still provides full functionality as long as the clients are provided with full documentation or the header files.

Without users, this wouldn't be a problem
Users are stupid. Sometime programmers are forgetful. Either of these leads to a world of hurt and together they are the end of times. Users input stupid shit like "SEPTEMBER 15th 09" into a textbox clearly marked "mm/dd/yy." Absent minded programmers don't check that. So the program crashes from an improperly formatted string. That's a runtime error. The compiler never noticed a probably because the data types matched up in the source code. The problem of error checking is a huge task, but it boils down to runtime errors that the programmer didn't handle. Or, you never bothered to install MSVBVM50.dll and without the library, the linker bombs out and your program can't run. Either way, by the time you read the on-screen message, your process is already dead.

Conclusion
There it is--runtime in a nutshell. Before you message to complain about interpreted language versus compiled language runtime, or *nix versus Windows, just know that I'm not listening. Scratch out your own writeup about it.

Log in or register to write something here or to contact authors.