Computeroperators
Devicedrivers and library functions
Onesolution to this problem was to have programmers prepare their work off-line onsome input medium (often on punched cards, paper tape, or magnetic tape) andthen hand the work to a computer operator. The computer operator would load upjobs in the order received (with priority overrides based on politics and otherfactors). Each job still ran one at a time with complete control of thecomputer, but as soon as a job finished, the operator would transfer theresults to some output medium (punched tape, paper tape, magnetic tape, orprinted paper) and deliver the results to the appropriate programmer. If theprogram ran to completion, the result would be some end data. If the programcrashed, memory would be transferred to some output medium for the programmerto study (because some of the early business computing systems used magnetic corememory, these became known as “core dumps”).
Theconcept of computer operators dominated the mainframe era and continues todayin large scale operations with large numbers of servers.
Devicedrivers and library functions
Soon afterthe first successes with digital computer experiments, computers moved out ofthe lab and into practical use. The first practical application of theseexperimental digital computers was the generation of artillery tables for theBritish and American armies. Much of the early research in computers was paidfor by the British and American militaries. Business and scientificapplications followed.
Ascomputer use increased, programmers noticed that they were duplicating the sameefforts.
Everyprogrammer was writing his or her own routines for I/O, such as reading inputfrom a magnetic tape or writing output to a line printer. It made sense towrite a common device driver for each input or putput device and then haveevery programmer share the same device drivers rather than each programmerwriting his or her own. Some programmers resisted the use of common devicedrivers in the belief that they could write “more efficient” or faster or"“better” device drivers of their own.
Additionallyeach programmer was writing his or her own routines for fairly common andrepeated functionality, such as mathematics or string functions. Again, it madesense to share the work instead of everyone repeatedly “reinventing the wheel”.These shared functions would be organized into libraries and could be insertedinto programs as needed. In the spirit of cooperation among early researchers,these library functions were published and distributed for free, an earlyexample of the power of the open source approach to software development.
Computermanufacturers started to ship a standard library of device drivers and utilityroutines with their computers. These libraries were often called a runtimelibrary because programs connected up to the routines in the library at runtime (while the program was running) rather than being compiled as part of theprogram. The commercialization of code libraries ended the widespread freesharing of software.
Manufacturerswere pressured to add security to their I/O libraries in order to preventtampering or loss of data.