Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-10-24
2003-02-25
Lao, Sue (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C709S241000
Reexamination Certificate
active
06526457
ABSTRACT:
TECHNICAL FIELD OF THE INVENTION
The present invention relates to computer programming, and more particularly to methods of improving portability of applications programming between computers having different operating systems.
BACKGROUND OF THE INVENTION
A computer “operating system” is software that controls the execution of applications programming, and typically includes “utility” programs that provide commonly needed services that facilitate the use of the computer by applications software. These services include such services as scheduling, input/output control, storage assignment, and data management.
Today's general purpose computers are available with a number of different operating systems. Although utilities are common to some extent, each operating system may have utilities that operate differently or that are unique to that system.
A problem in developing applications software is that of portability between operating systems. Much of the porting effort is directed to making use of operating system utilities. An applications program must either have a different version for each system or it must contain a means to invoke and use the utilities of a number of different systems.
One approach to portability is to provide conditional compile statements in the applications program. These statements operate in conjunction with the C preprocessor. For example, a program written in the C++ programming language might have statements such as:
#ifdef [name of operating system]
#include <[name of utility file
1
for that system]>
#include <[name of utility file
2
for that system]>
. . .
#endif
A similar set of statements is required for each operating system. Although conditional compiles isolate system-specific code, the above approach requires the applications programmer to invoke each utility with its system-specific name.
Another approach to portability treats utilities as objects and uses object inheritance. Consistent with well known object-oriented programming concepts, the “objects” are software entities comprising data structures and operations on the structure's data. Objects can model concrete things or abstract ideas, in terms of characteristics as represented by data elements, or in terms of behavior as represented by data manipulation functions. Objects are defined by creating “classes”, which act as templates that instruct a compiler how to construct an actual object. For example, a class may specify that number and type of data variables and the steps involved in functions that manipulate the object. An object created from a certain class is called an “instance” of that class. In the case of utilities, each utility is represented by an object whose behavior is defined by a base class. Operating system specific classes inherit from the base class. An applications programmer can invoke the utility with the base class name, and in this manner, the applications software is isolated from the operating system. However, this approach to porting does not eliminate the need for conditional compiles to specify which operating system class to create.
“Cross-platform” development tools have also been developed. However, these tools provide programming environments, supplying high level applications programming interfaces. Although the system utilities can be-presented generically, the applications programmer must learn how to use the environment and is entirely enveloped by that environment during the program development process.
SUMMARY OF THE INVENTION
One aspect of the invention is a method of providing operating system utilities for use by an applications program for a number of different operating systems. For each utility, a base class is created. The base class is defined in a header file and declares a static member function for creating the utility as an object. For each operating systems, a derived class is also created for each utility. This derived class includes the base class and either contains or includes a definition of the static member function. The derived classes are contained in a utility object library, which is linked to the system utilities. After the program is compiled and the derived classes are linked, it may invoke the static member function and include said header file. When the program is executed, a system-specific instance of the derived class is created and the utility is executed.
An advantage of the invention is that minimal programming effort is required of an applications programmer who wishes to invoke operating system utilities. The programmer can write the program to a generic operating system. The utilities themselves are also generic. As a result, once the programmer learns the generic operation of the service as defined by the base class, the programmer needs no further knowledge of the operation of the utility within a particular operating system. For example, once a programmer learns how and when a semaphore (a utility that coordinates two or more concurrently running programs) should be used, the programmer need not learn the call and behavior specific to an operating system. To use a given utility, the programmer need only include a base class header file for that utility, create a utility object with the static member function, and invoke the utility object methods.
Building code once it is written is also simple. No conditional compiles are required. To execute the program on a given operating system, the programmer merely links the program with the utility object library for that operating system. There is no need for special compiling or linking to the system utilities.
Finally, the programmer is not constrained to develop code with a new programming environment. He or she may use or not use the utility object library as desired.
REFERENCES:
patent: 5315703 (1994-05-01), Matheny et al.
patent: 5371884 (1994-12-01), Ross
patent: 5379431 (1995-01-01), Lemon et al.
patent: 5379432 (1995-01-01), Orton et al.
patent: 5404529 (1995-04-01), Chernikoff et al.
patent: 5450583 (1995-09-01), Inada
patent: 5455951 (1995-10-01), Bolton et al.
patent: 5475845 (1995-12-01), Orton et al.
patent: 5493680 (1996-02-01), Danforth
patent: 5504892 (1996-04-01), Atsatt et al.
patent: 5519867 (1996-05-01), Moeller et al.
patent: 5546595 (1996-08-01), Norman et al.
patent: 5548779 (1996-08-01), Andert et al.
patent: 5566346 (1996-10-01), Andert et al.
patent: 5574915 (1996-11-01), Lemon et al.
patent: 5583983 (1996-12-01), Schmitter
patent: 5832264 (1998-11-01), Hart et al.
patent: 5940616 (1999-08-01), Wang
K. Saito, et al, “Applying Object Oriented Programming to Developing Programs on CTRON Interfaces”, IEEE, pp. 103-117, Nov. 1991.*
S. Lippman, C++ Primer, 2nd ed. Addison-Wesley, pp. 244-249, 256-257, 1991.
Computer Associates Think Inc.
Lao Sue
LandOfFree
Systems utility object interface for facilitating software... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Systems utility object interface for facilitating software..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Systems utility object interface for facilitating software... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3144673