Information Technology Reference
In-Depth Information
then the user's program had to include instructions about how that
reading was to take place. If the program needed to store or retrieve
data on a disk, then the program needed to include instructions
about where to find the disk's directory, how to read the directory's
entry for the desired file, where to locate the specific file (e.g., track
and sector numbers), and so on. If the program was to print output,
then the program had to include all of the detailed instructions for
interacting with the printer. In order to handle a range of I/O de
vices, a user might have to supply hundreds of detailed instructions
for even a very simple program. For example, a program to convert
a temperature in Fahrenheit to the corresponding temperature in
Celsius might require 200-300 instructions. In all of this work, the
mathematical formula [Celsius (
5
9
)*(Fahrenheit 32)] would re
quire under 20 instructions; the remainder of the instructions would
dictate how the computer should handle input and output.
In reviewing programs like converting Fahrenheit to Celsius, it
did not take long for early computer scientists to realize that much
of the I/O handling was standard across programs—many programs
were doing the same basic tasks. To improve the efficiency of writ
ing program instructions early computer scientists decided to dupli
cate the common instructions and include this package in each pro
gram. With this approach, each program might be large, with all
instructions for I/O as well as instructions for the specific applica
tion, but a user only had to develop the special instructions for her
or his application.
Another common set of instructions within a typical program
had the task of transitioning from the running of one program to
the running of the next. If each program had to be completely self
sufficient, then initial work would be required to prepare the com
puter for running each successive program. For example, the com
puter would have to be told how to read the instructions for the
forthcoming program before it could transition to it. This initial
work was required for each program.
Computer scientists soon realized that the transition process
could be streamlined if the end of one task could include the
preparatory work for the next. Then, when one program was com
plete, the next user would not have to tell the computer how to read
the next program. This preparatory work was not strictly part of in
dividual applications; automating the programtoprogram transi
tions helped all users. For example, when I wrote my first programs
