Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
2000-09-28
2004-07-27
Dam, Tuan (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C717S121000
Reexamination Certificate
active
06769115
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention concerns software development environments generally and more specifically concerns software development environments for writing code that will be ported to a number of different platforms.
2. Description of Related Art
From the moment the second stored program computer became operational, the people who write software have dreamed of being able to write a program once and have it run correctly on all available computers, rather than having to make a different version of the program for each of the computers. The process of taking a program that runs on one computer A and modifying it so that it runs on a different computer B is called porting the program to computer B. Porting has gotten easier over the years. Originally, the program had to be rewritten in the machine language or assembly language used by computer B. Then high-level languages such as Fortran or C made it possible to write the program in a high-level language and compile it into the machine language required by computers A and B. However, each version of the program had to take into account the fact that computers A and B generally ran under different proprietary operating systems. The number of operating systems and the number of different hardware architectures has been reduced over time, but the porting problem remains. Even today, a program which is written for one platform (the combination of a particular operating system running on a processor having a particular hardware architecture) cannot simply be run on another platform as it was written for the first platform, but must instead be ported to the other platform.
More is involved in porting than simply changing code to get it working on the new platform in all but the smallest software development organizations. First a development team gets the original software working on a single development platform. Then the software is handed over to a porting team who have the task of making the original software work on other platforms, termed delivery platforms. This often requires help from the development team, because the porting team may not understand some aspects of the code or the original developers may have coded something that just can't be done on some of the delivery platforms and a major change is required.
Once the porting is complete, the modified source code is integrated back into the original source code, which is often simultaneously undergoing modification for a new version of the software. In addition to the direct labor and equipment costs of porting there are indirect costs:
The development team must communicate with the porting team to help them resolve issues.
The porting team has opportunity to introduce bugs into the code.
Changes made by the porting team must be integrated back into the source base.
Time differences in the availability of software on different platforms adds to support costs and customer frustration.
Programmers have made many attempts to reduce the costs associated with porting. A major aim of the design of the Unix® operating system and the C high-level language was to provide a standard programming environment for writing programs that would run on different UNIX platforms. Many programs have in fact successfully run on multiple UNIX platforms, but there have always been ragged edges and the UNIX/C programming environment provides little or no feedback to indicate to a programmer whether the code he or she is writing in fact adheres to the standard or is accidentally using non-standard features that are peculiar to the development platform the programmer is writing the code on and that will not work on other platforms.
To make porting simpler in the UNIX environment, the UNIX community attempted to unify around the concept of an application binary interface (ABI), which was a formal description of the calling conventions, data representation, and available services that an operating system that conformed to the UNIX standard would provide to application programs on specific hardware architectures. There were two problems with the effort:
The ABI's were not broad enough to be really useful to programmers, and
most vendors of UNIX platforms were unwilling to change their platforms to conform to the ABI.
Some vendors of UNIX platforms, meanwhile, produced utilities which accommodated a program written to run on one platform so that it would run on another platform with the same underlying computer architecture. Examples are DG/UX®'s Application Capture Option, IBM's Linux Application Execution Environment, and an Open Source package called Lxrun. Where these utilities work with a given application program, they solve the portability problem for the application program that they work with and the platforms that they are designed for. There is, however, no guarantee that the utility will work with the given application program, or that if it works, that the next version of the application will work. If the utility doesn't work, it gives the programmer no help in getting the application program itself to work.
The UNIX world has long used the lint utility to help identify portability problems. lint is run on the source code for a program before the source code is compiled and identifies patterns in the source code that may cause problems during compilation or later. Unfortunately, there are many cases where lint can't decide if a code sequence is acceptable or not. It gives up in these cases and produces false-negative messages that engineers have to read past to find any real problems. This is very tedious.
Finally, many software development organizations insulate their application programs from OS differences by writing an abstract operating system, that is, a layer of software that provides a standard interface to the application program and contains the code needed to make the standard interface work with the operating system interfaces for the operating systems the application is to be ported to. Thus, all that is required when an application is to be ported to a new operating system is to port the abstract operating system to the new operating system. This does in fact reduce porting costs, but the abstract operating system is in essence an internal standard. As such, it must be designed, must be agreed to by all parties, must be implemented, and must be maintained.
While the best solution to the porting problem would be its elimination by the adoption of a single standard platform, it has become increasingly apparent that for historical, technical, and commercial reasons, there will be multiple platforms for the foreseeable future. What is needed are tools that help the programmer do the porting that must be done. What is particularly needed are tools that make the programmer aware of potential porting problems as soon as possible and that are easily adaptable to deal with all present and future platforms. It is an object of the present invention to provide such tools.
SUMMARY OF THE INVENTION
The object of the invention is attained through an improved program development environment in which a program which is to execute on a plurality of platforms can be developed. The program development environment includes a compiler for producing object code for a given one of the different platforms from source code for the program. The program development environment is improved by adding a database that describes the platforms and differences between the platforms. The database is accessible to and interpretable by the compiler and the compiler responds to the source code and the database by indicating whether any of the source code is incompatible with any of the differences described in the database. In addition to the database, the program development environment may include a run-time test library that is bound to an application binary produced from the object code and responds to an execution of the application binary by testing whether the application binary is incompatible with any of the differences described in
Dam Tuan
EMC Corporation
Kiss Eric B.
Nelson Gordon E.
LandOfFree
Adaptive interface for a software development environment does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Adaptive interface for a software development environment, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Adaptive interface for a software development environment will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3226815