Data processing: software development – installation – and managem – Software program development tool – Modeling
Reexamination Certificate
1999-09-24
2002-11-26
Morse, Gregory (Department: 2122)
Data processing: software development, installation, and managem
Software program development tool
Modeling
Reexamination Certificate
active
06487713
ABSTRACT:
CROSS REFERENCE TO RELATED APPLICATION
Not applicable.
STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT
Not applicable.
BACKGROUND OF THE INVENTION
1. Field of the Invention/Overview
The present invention relates generally to methods and systems for developing and integrating a software product by customizing and combining core components and integrating them to form the software product. More particularly and illustratively, the present invention relates to a software system for maintaining and re-using the core components of a Basic Input/Output System (BIOS) for a personal computer (PC) that simplifies BIOS deployment and that provides the architecture for an extensible yet maintainable core which enables rapid product development, enhancement, and modification.
2. Background and State of the Art
A BIOS product is a piece of software code that executes when a PC is started up or “booted” and that is later called upon to provide various services while the PC is running. A development system for BIOS products must support all the peripherals that may be installed on any type of PC from a low-end basic PC up to a state-of-the-art, highly customized, high-end server or portable product. The various aspects of building a BIOS are described below to illustrate the capabilities that a software system for maintaining and using a library of core BIOS software components should provide.
A customer wishing to build a BIOS for a particular machine selects core BIOS software components to support the peripherals installed on that machine from a library of such components. Each software component may include one or more features and may be configured by adding or removing code for features from the set of available features and by specifying the values of optional parameters (“options”) for this code. The customer may wish to add special BIOS code for peripherals custom manufactured by the customer and not available from the BIOS vendor.
Configurable features are implemented as separate code in the core BIOS component library that have external references and definitions in the code addressing other code components by name and by directory/subdirectory or by library name so the code for each feature can be linked into the final product only when it is properly configured and addressed. The present state of the art is to replace the code for a called, named, and addressed optional feature that is not selected with a stub routine that merely returns to its caller. Another possibility is to reference the optional feature indirectly through a pointer that can be set to null if the feature is removed; however, this requires each caller to verify that the pointer is valid. Ideally, the code to call an optional feature should be removed from the code when the component is built to realize a savings in both execution time and memory size occupied by the program.
The present state of the art defines the optional parameters of a software component (hereinafter called “options”) as manifest constants, e.g., “BUFFER_SIZE EQU 256.” The name of a manifest constant (BUFFER_SIZE) and the value it represents (256) are associated when the manifest constant is defined. Each reference to the name of a manifest constant, such as the length of an array or the value of a variable, for example, is replaced with the associated constant value when the source code is compiled. This allows each option to be given a descriptive name and makes it possible to change the option value in all the places it is referenced by changing the one definition. Options such as these are typically set or adjusted by defining or modifying an “include” file by hand. The “include” file is then incorporated by reference into the other source code files. It is easy to miss a file containing a reference to an option name, or to confuse options having the same names in different system components.
The producers and marketers of the core BIOS component library need to respond rapidly to new devices that become available in the marketplace. One tried and true method is to make a copy of the code for a similar existing device and to modify it only where necessary to support the new device. The original code may have supported several configurable features that are now also available for the new device. Copying the code from another core component gives rise to two components in the same library with not only the same features, but also identical external names to reference them. This ambiguity can cause further confusion at compile and link time.
The customer may sell machines that incorporate either an old device or a new device. The customer may therefore create a BIOS that incorporates both an old software component supporting the old device and a new component, generated by modifying the old component and having identical external names, supporting the new device. The BIOS would contain additional code to intercept the calls to each procedure in the old and new components. The customer then would add decision code for each intercepted procedure that decides whether the procedure in the new component or the old component should be called. This gives rise to a BIOS containing two components having identical external names and decision code for each intercepted call that must call one of the two procedures with identical names without being intercepted. Both software components would have to be compiled and linked separately so that the identical external names in each component would not conflict. They would also have to be linked together with the decision code that calls them.
Suppose that both the old component and the new component, generated by modifying the old component and having identical external names, had an initialization feature named INIT. The additional decision code mentioned above must be called in place of the INIT procedure so it can determine whether the INIT procedure in the old or new component should be called. Present art would require that each call to INIT go indirectly through a pointer table so that the pointer could be changed to intercept, or hook, each such call. All calls to INIT throughout the BIOS would be intercepted, or hooked, in this manner. The ability to intercept such calls is also important for debugging purposes.
The producers of the core BIOS component library respond to new devices that become available in the marketplace by rapidly releasing new versions of the library. In the process of maintaining and enhancing the library, they may modify some interfaces to add functionality or to fix bugs. The customer with an existing BIOS will wish to incorporate the new functionality and bug fixes as well as the newly supported devices. The customer must verify that calls to existing interfaces which have changed are still compatible and quickly identify those interfaces that are now incompatible and that must be changed. Present art validates interfaces by matching the number of parameters, the type of each parameter, and the range of values.
The BIOS code for a particular device typically consists of initialization code that executes when the PC is started up and support code that provides services when called upon. There may be no references in the support code to the initialization code, or vice versa, that would cause both pieces of code to be included in the BIOS build; yet the support code clearly depends upon the initialization code. Present art requires manual intervention to insure that both pieces of code are included in the build.
The conventional way of finally testing source code modules for consistency is to compile and/or assemble the separate source code files, identifying and correcting all errors and repeating this process; link the object code files, identifying and correcting all errors and repeating both of these processes; and finally, combine the separately linked system elements into an inter-linked image, identifying and correcting all errors and repeating all three of these processes repeatedly and recursively until no more errors are found. Even then, improper
Bombet Marc Abraham
Cohen Frances
Lewis Timothy Andrew
Lusinsky Robert Dennis
Sandusky Marc Shane
Morse Gregory
Phoenix Technologies Ltd.
Zhen Wei
LandOfFree
Software development system that presents a logical view of... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Software development system that presents a logical view of..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Software development system that presents a logical view of... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2929635