Computer
operators
Device
drivers and library functions
One
solution to this problem was to have programmers prepare their work off-line on
some input medium (often on punched cards, paper tape, or magnetic tape) and
then hand the work to a computer operator. The computer operator would load up
jobs in the order received (with priority overrides based on politics and other
factors). Each job still ran one at a time with complete control of the
computer, but as soon as a job finished, the operator would transfer the
results to some output medium (punched tape, paper tape, magnetic tape, or
printed paper) and deliver the results to the appropriate programmer. If the
program ran to completion, the result would be some end data. If the program
crashed, memory would be transferred to some output medium for the programmer
to study (because some of the early business computing systems used magnetic core
memory, these became known as “core dumps”).
The
concept of computer operators dominated the mainframe era and continues today
in large scale operations with large numbers of servers.
Device
drivers and library functions
Soon after
the first successes with digital computer experiments, computers moved out of
the lab and into practical use. The first practical application of these
experimental digital computers was the generation of artillery tables for the
British and American armies. Much of the early research in computers was paid
for by the British and American militaries. Business and scientific
applications followed.
As
computer use increased, programmers noticed that they were duplicating the same
efforts.
Every
programmer was writing his or her own routines for I/O, such as reading input
from a magnetic tape or writing output to a line printer. It made sense to
write a common device driver for each input or putput device and then have
every programmer share the same device drivers rather than each programmer
writing his or her own. Some programmers resisted the use of common device
drivers in the belief that they could write “more efficient” or faster or
"“better” device drivers of their own.
Additionally
each programmer was writing his or her own routines for fairly common and
repeated functionality, such as mathematics or string functions. Again, it made
sense to share the work instead of everyone repeatedly “reinventing the wheel”.
These shared functions would be organized into libraries and could be inserted
into programs as needed. In the spirit of cooperation among early researchers,
these library functions were published and distributed for free, an early
example of the power of the open source approach to software development.
Computer
manufacturers started to ship a standard library of device drivers and utility
routines with their computers. These libraries were often called a runtime
library because programs connected up to the routines in the library at run
time (while the program was running) rather than being compiled as part of the
program. The commercialization of code libraries ended the widespread free
sharing of software.
Manufacturers
were pressured to add security to their I/O libraries in order to prevent
tampering or loss of data.