Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-10-30
2001-10-02
Powell, Mark R. (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C717S152000
Reexamination Certificate
active
06298481
ABSTRACT:
COPYRIGHT NOTICE
A portion of the disclosure recited in the specification contains material which is subject to copyright protetion. Specifically, a Microfiche Appendix in accordance with 37 CFR Section 1.96 is included that lists source code instructions for a process by which the present invention is practiced in a computer system. The Microfiche Appendix comprises 1 sheet of microfiche containing 63 frames, or pages, of source code appendix. The copyright owner has no objection to the facsimile reproduction of the specification as filed in the Patent and Trademark Office. Otherwise all copyright rights are reserved.
BACKGROUND OF THE INVENTION
This invention relates in general to the execution of computer programs and more specifically to a system which allows the run-time functionality of a compiled computer program to be modified.
Computer programs, or code, can be executed in a number of different ways. Two broad, and fundamentally different, ways are by executing interpreted code or by executing compiled code.
Interpreted code generally requires the processor to operate on a line-by-line basis on human-readable code. That is, the representation of the computer program is in a text-based form, or not far removed from a text-based form such as where the code is “tokenized,” so that the difference between the code as written by a human programmer, and as executed by the processor are quite similar. Interpreted code unlike compiled code, has the advantage of not requiring long “build” times. Essentially a programmer can write interpreted code and execute the code immediately for the purposes of testing the code. In this respect, interpreted code is useful for rapid prototyping. Interpreted code is generally well-suited to small applications where speed is not a major issue. This is because a big drawback of interpreted code is that it is notoriously slow compared to compiled code.
Compiled code produces very fast executable programs. However, the creation and maintenance of compiled code is much more involved than with interpreted code. Also, the programs produced with the compiled program approach are more complex to develop and modify. Typically, many program modules are required which must be compiled, linked and loaded before a change can be tested or before a deliverable executable is produced. There can be hundreds of different modules, or files, in large compiled computer programs, sometimes referred to as “projects.” The build process for these projects is complicated in itself, requiring precise coordination of symbols, processes, resources and other aspects of developing the program. A complete build of a computer program can take hours of time, depending on the size of the program. Moreover, compiled code development requires precise archiving, bookeeping and tracking of modules, utilities, tools and other developer support software. As a computer program ages it may be difficult, or impossible, to re-build a specific version of a program even though the executable version of the program is still in use. This is because the operating system, development environment, tools, utilities or other software (or hardware) used to build the program may have changed.
Since a programmer must have detailed knowledge of the compiled program and the development environment it is difficult for programmers who are not the original programmers of a compiled program project to “come up to speed” and make modifications to software written by another programmer. The compiled, linked and loaded executable code is not readable by a human programmer in any practical sense, forcing the programmer to learn not only the human-readable “source” code version of the program, but to also have a detailed working knowledge of the build process for the program. Thus, the maintenance and modification of compiled code poses problems.
Another property of both interpreted and compiled code is that it is difficult to change the run-time functionality, or behavior, of the code. In the interpreted code approach, an entire new set of interpreted code instructions must be loaded onto a user's computer. Compiled code is typically so much larger than interpreted code that approaches, discussed below, have been developed to circumvent the loading of a completely new version of the compiled executable. Although interpreted code is relatively small, thus permitting new versions to be loaded easily, it is not suitable for the majority of application programs which require fast execution of very large programs. Examples of interpreted code are BASIC, Lisp and script languages such as Perl and Java. Examples of laguages used in compiled code approaches are Fortran, “C,” assembly language, etc. However, these categories are somewhat loosely defined since any computer language can be implemented as a compiled code or interpreted code approach assuming an appropriate “interpreter” or “compiler” is written for the target machine intended to execute the code.
The prior art is discussed below with reference to
FIGS. 1A-F
.
FIG. 1A
shows a simplified diagram illustrating the process for executing interpreted code.
In
FIG. 1A
, program
10
is created by a programmer. Typically this is done in a word-processing program which results in human-readable text. The program is loaded into a user computer
12
. The transfer, or loading, can be by diskette, compact disk read-only memory (CDROM), downloading from a network, or by other means. The loaded program
14
is usually an exact copy of the original text produced by the programmer. Loaded program
14
is interpreted by interpreter
16
which results in the execution of functions as specified by the program code, or script, to produce the desired run-time functionality in the user's computer. Thus, there is only a single program definition in an interpreted code approach. That of program
10
which serves as the human-readable definition of the program and as the executing image in the user's computer.
FIG. 1B
shows a simplified diagram illustrating the process for executing compiled code.
In
FIG. 1B
, items
20
-
30
are part of a software “build” process whereby an machine-readable executable object is created from human-readable source code modules. Items
34
-
38
illustrate items involved with executing a compiled software program on a user's computer
32
.
In
FIG. 1B
, source code
20
is created by a programmer and is the human-readable version of the program. Typically, programmers in compiled code development environments work with separate files of source code so, for example, source code
20
of
FIG. 1B
represents a single module of many modules used in the program project. A module can have from a few to several hundred or more lines of code. Source code
20
is compiled by compiler
22
to result in an object file
24
. Each module is capable of being compiled independently of any other modules in the program project. This allows sections of the program to be modified on a module-by-module basis without requiring compilation of all of the many modules in the program project. However, note that changing even a single line in a module requires that the entire module be re-compiled and the entire project re-built as discussed below.
Once compiled, the object file can be linked to other object files in the program project. The other object files can be from other compiled source code modules that the programmer, or another programmer, has written. Other sources for linkable object modules include pre-existing library objects
26
to provide commonly needed functions. All of the object files for the program project are linked via linker
28
to produce a single executable object
30
. Producing executable object
30
culminates the program build. Note that, generally (aside from dynamic linking discussed below) it is necessary to have all of the object files from all of the modules, libraries and other object file sources on hand to do a build. This is problematic on large projects because different objects may be changing at different
Kosaka Takashi
Plate Michael
Kulas Charles J.
Powell Mark R.
Segasoft, Inc.
Townsend and Townsend / and Crew LLP
Zhen Wei
LandOfFree
System for modifying the functionality of compiled computer... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System for modifying the functionality of compiled computer..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System for modifying the functionality of compiled computer... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2577761