A computer implemented system analyzes an application state by determining entities which provide predetermined functionalities for a user determining items that depend from the determined entities, grouping entities by pruning overlapping entities and combining similar entities, and packaging the group of entities using a predetermined format. The system provides automatic relationship resolution based on a current machine state to enumerate in a deterministic manner fundamental data, metadata and dependencies necessary for correct application function. In addition, state information is stored in a persistent format to be used in a variety of applications, including installation, synchonization, backup, recovery, analysis, and repair.
|
1. A process for determining a current machine state of software on a computer system, comprising:
determining entities which provide predetermined functionalities for a user, where an entity is a group of one or more items and an item relates to a fundamental unit of data or metadata that may be operated on with or without dependencies from other items; determining items that depend from the determined entities, comprising: examining at least one root item, the root item being an item of one of the determined entities, performing a binary analysis of the root item to generate one or more candidates, a candidate being a data packet containing information used to generate an item, and using the candidates in determining dependency of items from entities; grouping entities by pruning overlapping entities and combining similar entities; and packaging the group of entities in a package having a predetermined format. 16. A computer program product, tangibly recorded on a machine-readable medium, for determining a current machine state of software on a computer system, the product comprising instructions operable to cause a programmable processor to:
determine entities which provide predetermined functionalities for a user, where an entity is a group of one or more items and an item relates to a fundamental unit of data or metadata that may be operated on with or without dependencies from other items; determine items that depend from the determined entities, including instructions to: examine at least one root item, the root item being an item of one of the determined entities, perform a binary analysis of the root item to generate one or more candidates, a candidate being a data packet containing information used to generate an item, and use the candidates in determining dependency of items from entities; group entities by pruning overlapping entities and combining similar entities; and package the group of entities in a package having a predetermined format. 2. The process of
after generating the candidates, pruning candidates that do not reference valid items on the computer system.
3. The process of
for at least some of the items, confirming the items so that a link is made between the candidate and its parent item and, if the confirmation is successful, using the confirmed items to determine items that depend from the determined entities.
4. The process of
the link includes a reference to metadata, a reference to a file, or a reference to an external piece of information needed by the software.
5. The process of
the link further includes a reference to a component of a network subsystem or a component of a network stack.
6. The process of
the link further includes a reference to network configuration information or network bindings.
7. The process of
the link includes a reference to a printer driver, a print spooler, a printing subsystem, or a printer configuration.
9. The process of
the operating system component is a subsystem of an operating system of the computer system.
10. The process of
the package contains state information suitable for installation, backup, or repair of the software.
11. The process of
the packaging records information sufficient to identify a particular item belonging to an entity, so that a computer program can determine salient characteristics about an item without actually having to investigate the item.
12. The process of
the information to identify a particular item includes a file name, file size information, and file version information.
13. The process of
determining an inter-entity relationship; and processing the entities based on the inter-entity relationship.
14. The process of
the package contains an entity that represents a single computer program application and includes for that entity information on one or more operating system settings.
15. The process of
the software includes one of an interactive application, an operating system component, or an operating system.
17. The computer program product of
after generating the candidates, prune candidates that do not reference valid items on the computer system.
18. The computer program product of
for at least some of the items, confirm the items so that a link is made between the candidate and its parent item and, if the confirmation is successful, use the confirmed items to determine items that depend from the determined entities.
19. The computer program product of
the link includes a reference to metadata, a reference to a file, or a reference to an external piece of information needed by the software.
20. The computer program product of
the link includes a reference to a component of a network subsystem or a component of a network stack.
21. The computer program product of
the link further includes a reference to network configuration information or network bindings.
22. The computer program product of
the link includes a reference to a printer driver, a print spooler, a printing subsystem, or a printer configuration.
23. The computer program product of
the link includes a reference to an operating system component.
24. The computer program product of
the operating system component is a subsystem of an operating system of the computer system.
25. The computer program product of
the package contains state information suitable for installation, backup, or repair of the software.
26. The computer program product of
the instructions to package the group are operable to record information sufficient to identify a particular item belonging to an entity, so that a computer program can determine salient characteristics about an item without actually having to investigate the item.
27. The computer program product of
the information to identify a particular item includes a file name, file size information, and file version information.
28. The computer program product of
determine an inter-entity relationship; and process the entities based on the inter-entity relationship.
29. The computer program product of
the package contains an entity that represents a single computer program application and includes for that entity information on one or more operating system settings.
30. The computer program product of
the software includes one of an interactive application, an operating system component, or an operating system.
|
This is a continuation of Ser. No. 09/377,669 filed Aug. 19,1999 now U.S. Pat. No. 6,158,001 which is a continuation of Ser. No. 08/993,103 filed Dec. 18, 1997 now U.S. Pat. No. 5,996,073.
Historically, software applications were typically batch-processed on a mainframe at a centralized computing center. More recently, the availability of inexpensive, yet powerful personal computers has displaced the batch-processing mode of the past. The availability of a wide range of user-friendly, productivity enhancement software has made personal computing ubiquitous. Although more easily customized to users' specific requirements, the proliferation of personal computers is making the job of managing large scale computing more difficult. In the past, the mainframe in the computing center performed centralized system management tasks, including library and configuration management and software version control, among others. However, in a modem network with diverse processors, peripherals, and software applications, the range of possible configurations is staggering.
Some of the configuration information is hardware specific, such as disk controller port addresses, communication port addresses and video port addresses. Further, software specific configuration parameters may be set within configuration files for each application. For example, a configuration file stored within an IBM-compatible personal computer known as an autoexec.bat file may include path statements. Additionally, specific application software may require specific initialization information to run effectively. Typically, this information may be set in an initialization (.ini) file.
Once installed, the computer configuration does not remain static, however. The user may update configurable preferences while operating the software, such as updating file open/save paths. Additionally, the user may "personalize" the software by adding new information such as bookmark data in the case of World-Wide-Web browser software, for example. Moreover, due to the constant competitive pressure to build a better product, by the time a software release is delivered to the user, software developers are already working on the next release. To cope with rising demands on friendlier and more functional applications, software developers have increasingly adopted a component model where an application is reduced into a plurality of modules or components. Modifications may be made to a single component to enhance its performance or implement new features not previously available without compromising the status of the remaining components. In this paradigm, a software application is a collection of many separate files, each of which may be generated by unrelated software developers who may be more aware of each component's integrity than the integrity of the assembled package. Although software reuse is promoted, the paradigm necessitates a higher level of inter-component integrity. Not surprisingly, although more frequent updates bring more functional software to users, the complexity of managing the release installation increases disproportionally with the number of changes.
Historically, relationships between components have been manually detected and component states recorded in a log. This information is external of the components themselves and must be updated whenever the components change. As state information is recorded only at the time of development, changes made subsequent to the time of development may be lost. As the pace of changes increases and complexity of the software assembly process grows, the external representation of the correct state relationship between components becomes prone to error.
Moreover, during use, users may personalize the software and thus change the state information. The difference in state information between software installation and software operation leads to an unpredictable operation and may require more support from information system (IS) personnel.
Maintenance of the current states of software applications in commercial operations is needed in a variety of applications, including software installation, synchronization, backup, recovery, analysis and repair. A detailed knowledge of a computer's dynamic environment and its system configuration is needed to prevent situations where modifications to one component to correct one problem may introduce other errors if improperly installed. Moreover, an accurate knowledge of system configuration is required in order to verify compatibility and to ensure integrity across multiple operating environments and across diverse processors.
The present invention determines an application state by determining entities which provide predetermined functionalities for a user, determining items that depend from the determined entities, grouping entities by pruning overlapping entities and combining similar entities, and packaging the group of entities using a predetermined format. The system provides automatic relationship resolution based on a current machine state to enumerate in a deterministic manner fundamental data, metadata and dependencies necessary for correct application function. A complete, persistent run-time state information about the application is generated which may be used in installation, synchronization, backup, recovery, analysis and repair of a computer system.
In one aspect, the entities are analyzed by determining tiers of user accessibility. Further, for each tier, root entities are enumerated based on predetermined criteria. For each enumerated entity, one or more dependencies of the entity are determined.
In another aspect, the item dependency is determined by generating one or more candidates, analyzing the candidates, confirming the candidates, and packaging items associated with the candidate.
In yet another aspect, the entity grouping and packaging is accomplished by determining an inter-entity relationship, processing the entities based on the inter-entity relationship, and placing the entities into a predetermined format.
In another aspect, the format contains detailed information about each item and each entity. The format has zero or one information block and one or more entity blocks. Multiple information blocks with their associated entity blocks may be grouped together.
Advantages of the present invention include the following. The invention dynamically rebuilds an external representation of correct state from the components themselves. Moreover, because the state construction process is dynamic, the invention can follow software through its entire life cycle and provide information for many management tasks that need detailed information about the application during execution.
As used herein, a candidate is a data packet containing information used to generate one or more items. An item relates to a fundamental unit of data or metadata that may be operated upon with or without dependencies from other items. An entity is a group of items. The entity represents a set of predetermined functionality for a computer system or for a user. In its simplest form the entity may represent a single application such as Corel WordPerfect, Microsoft Excel, among others. The entity may also include information on one or more operating system settings such as printer settings, font settings, network device settings, among others. Moreover, the entity may also include information on files such as data files, initialization files, source files, and templates, among others. Each entity has a state which is a logical subset of the entire functionality available in the computer system. The system state may include information on executable files such as .exe files, .dll files and .ocx files. The machine state may also include registry settings, environment variables, support files, and data files at particular points in time.
Referring now to the figures,
Next, the process determines item dependencies, which may change over time step 24. The determination of the item dependencies is also a complete and deterministic process to locate all dependencies and to generate a finite set of dependencies. The process groups entities into a set by deleting overlapping entities and combining similar entities. Moreover, the state generation for an unchanged item will be consistent and identical to all previous state generations, provided that no changes have been made to any dependencies of the item. Finally, the process packages the entities into a suitable format for subsequent use (step 26) before exiting (step 28). In the grouping of entities in step 26, an intersection of the entities is determined such that a package of entities can be succinctly defined and that all the information necessary for it can be represented in a file with or without the actual entities. Enough information about each entity is included so that an analysis of correctness may be performed.
Referring now to
For each of the entities enumerated in step 34, item dependencies are determined (step 36). This step translates the data found in a tier to an actual item, be it an executable file or a data file. The step is also a translation of the entity to a root item. An example would include a translation from a link file to an executable file or from a data file to the executable file that accesses the data file. Determinations of all the dependencies that make up that entity are then generated. Some items, for example data files, may be end points as they have no further dependencies. Other items, such as executable files, may have many dependencies that may be generated from that item. For the selection of the next tier, there may be a conditional determination that a predetermined threshold of entities have already been located and, upon reaching this threshold, the processing of the current tier may be stopped.
Once all enumerated entities of the current tier have been analyzed, the process selects the next tier for processing (step 37). The process then determines whether it has completed processing all tiers. If not, the process loops from step 38 back to step 34 to continue processing. Otherwise, the process exits (step 39).
Referring now to
In step 46, the resultant items from the analysis and confirmation are packaged (step 46). The packaging process records information necessary to identify a particular item belonging to an entity. The information is sufficient for another application to determine salient characteristics about that item without actually having to investigate the item. In addition to a file name, file size information, cross-check information that identify the file and the file version is added after the item has been confirmed in the item packaging. For each item that is packaged, step 46 is repeated to locate items that are below the current item in a dependency tree. For each item beneath the current item, the process continues recursively until an atomic level item is found that can undergo no further candidate generation. At that point, the process exits (step 48).
A graphical example of a hierarchical format 70 is shown in FIG. 5. The format 70 stores a persistent state for entity groups 80 and 90. The entity group 80 has zero or one information blocks 82. The entity group 80 is a collection of related entities that all share similar entity level description dependencies as described in the information block 82. The entity 80 also has one or more entity blocks 84-86. The entity blocks 84 through 86 are collections of items which were created during the item generation step 24 (FIG. 3). The entity blocks 84-86 are related in a predetermined way. For example, they may have related executables or a set of related document files of different types. Similarly, the entity 90 has zero or one information blocks 92 and one or more entity blocks 94-96. The format may be text based, binary based, compressed, and/or encrypted. An embodiment of the format may be as follows:
[INFO "entity set label"] |
key=value |
key2=value2 |
| |
[ENT "entity block label"] |
itemtype = value1, value2, value3, value4, ... itemtype2 = v2, v3, v4 ... |
... |
In this embodiment, blocks are represented with brackets and a block type and a block label. An arbitrary number of line separated key value pairs follows each block. If the key is recognized as an item type, an expected number of values is required on the same line depending on the item type. Three block types, INFO, ENT, DEP are used. The INFO block type contains general information about the entity set and descriptive information about the entire file. The ENT block type contains a collection of other entities and/or items, and the DEP block type contains dependencies which are represented as key=value pairs. Moreover, five or more item types: file, pefile, reg, ini, lnk, are basic types which may be used. The file type relates to any file on the system. The pefile type relates to executable files in a Portable Executable format. The reg type relates to metadata representing an entry in a Windows Registry. The ini type relates to metadata representing an entry in an ini style support file, and the lnk type relates to a binary metadata file representing a shortcut to another file. Other types may describe additional data or metadata.
Turning now to
In performing the process of
Referring now to
From step 106 or step 110, in the event that the item is not to be decomposed or that candidates are not to be generated, the process 99 proceeds to step 112 where it checks whether it is at a root item. If not, the process 99 proceeds from step 112 to step 108 to continue the candidate generation process. Alternatively, in the event that the process 99 is at a root item, the routine operates on the next tier in the entity hunt process 99.
From step 102, in the event that all entities have been analyzed, the process 99 proceeds to step 120 to cross-reference the entities previously determined in steps 104-113. The process 99 determines whether additional overhead processing on the entities is to be performed (step 122). If not, the entity is packaged using the suitable format discussed earlier in step 124. Alternatively, additional processing of the entity may be done in step 126.
Referring now to
Referring now to
From step 238, in the event that the file is a PE file, the file is decomposed and candidates are generated (step 240). In the event that the file is not a PE file, the process checks whether the format of the file is an executable (exe) binary file (step 242). If so, the process performs a decomposition of the binary executable and also generates the candidate (step 244).
Alternatively, in step 242, if the file format is not an exe binary file format, the process proceeds to check whether the file format is an exe script format (step 246). If so, the decomposition of the script exe file and a generation of the candidate is performed (step 248). Alternatively, the process proceeds from step 246 to package the item (step 250).
In step 236, in the event a format is not an executable file format, the process checks whether the file format is an information format (step 252). If so, an information file is generated for the candidate (step 254).
In step 252, in the event that the file format is not an information file format, the process proceeds to step 256 where it checks whether the file belongs to a known data format (step 256). If so, the process performs a data file candidate generation (step 258). Alternatively, the process proceeds from step 256 to package the item (step 234). Step 234 is also performed in the event that the item is not of a known type in step 232.
Referring now to
In the event that all modules have been scanned in step 262, the process performs a string scan operation (step 280). Next, the process determines whether additional strings remain to be processed (step 282). If so, a string matching operation is performed (step 284). From the string matching operation, the process determines whether the string is of a registry type (step 286). If so, a registry matching operation is performed (step 288). From step 286 or step 288, the process proceeds to check whether the string is of an ODBC type (step 290). If so, an ODBC match operation is performed (step 292). From step 290 or step 292, the process proceeds to determine whether the string is a COM type (step 294). If so, a COM matching operation is performed in step 296. From step 294 or step 296, the process detects whether the file names match (step 298). If so, the item is added to a sibling list (300) before it proceeds to step 276 to confirm the item.
In the event that the string scan has been performed on all strings in step 282, the process proceeds to perform a sibling scan to locate related items (step 302). Next, it determines whether additional files remain to be scanned (step 304). If not, the item is confirmed in step 306. Alternatively a sibling match operation is performed (step 308) before the item is confirmed (step 276).
As discussed above, the application state is arrived at by determining entities which provide predetermined functionalities for a user determining items that depend from the determined entities, grouping entities by pruning overlapping entities and combining similar entities, and packaging the group of entities using a predetermined format. The system provides automatic relationship resolution based on a current machine state to enumerate in a deterministic manner fundamental data, metadata and dependencies necessary installation, synchronization, backup, recovery, analysis and repair of a computer system.
The techniques described here may be implemented in hardware or software, or a combination of the two. Preferably, the techniques are implemented in computer programs executing on programmable computers that each includes a processor, a storage medium readable by the processor (including volatile and nonvolatile memory and/or storage elements), and suitable input and output devices. Program code is applied to data entered using an input device to perform the functions described and to generate output information. The output information is applied to one or more output devices.
Moreover, each program is preferably implemented in a high level procedural or object-oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
Each such computer program is preferably stored on a storage medium or device (e.g., CD-ROM, hard disk or magnetic diskette) that is readable by a general or special purpose programmable computer for configuring and operating the computer when the storage medium or device is read by the computer to perform the procedures described. The system also may be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner.
While the invention has been shown and described with reference to an embodiment thereof, those skilled in the art will understand that the above and other changes in form and detail may be made without departing from the spirit and scope of the following claims.
Lee, Cadir Batista, Dale, Scott William
Patent | Priority | Assignee | Title |
6681391, | Jun 21 2000 | ZHIGU HOLDINGS LIMITED | Method and system for installing software on a computer system |
6823376, | Apr 26 1999 | International Business Machines Corporation | Method and system for capturing and storing system changes for application to multiple users and systems in a heterogeneous server environment |
7281239, | Aug 22 2003 | Gateway Inc.; Gateway, Inc | Method for determining software load process |
7305465, | Nov 15 2000 | WING, ROBERT P | Collecting appliance problem information over network and providing remote technical support to deliver appliance fix information to an end user |
7669200, | Sep 02 2004 | TWITTER, INC | Resizing an install image |
8457044, | Sep 24 2007 | Qualcomm Incorporated | Selective review of bundled messages from a wireless communication device |
9198006, | Sep 24 2007 | Qualcomm Incorporated | Selective review of bundled messages from a wireless communication device |
Patent | Priority | Assignee | Title |
4536791, | Mar 31 1980 | General Instrument Corporation | Addressable cable television control system with video format data transmission |
5164941, | Jan 24 1990 | Canai Computer and Network Architecture Inc. | System for implementing improved attempt-and-defer access contention protocol |
5247683, | Jun 28 1990 | Lenovo PC International | System and method for installing software and updating configuration files |
5283864, | Oct 30 1990 | CHIPS & TECHNOLOGY, INC | Computer apparatus and method for graphical flip book |
5291490, | Feb 18 1992 | AT&T Bell Laboratories | Node for a communication network |
5499357, | May 28 1993 | Xerox Corporation | Process for configuration management |
5504879, | Jul 16 1992 | International Business Machines Corporation | Resolution of relationship source and target in a versioned database management system |
5509116, | Mar 30 1990 | International Business Machines Corporation | Graphical user interface management system |
5581764, | Apr 30 1993 | HEWLETT-PACKARD DEVELOPMENT COMPANY, L P | Distributed computer network including hierarchical resource information structure and related method of distributing resources |
5600565, | Dec 22 1994 | International Business Machines Corporation | Method and apparatus for error reduction in item packaging |
5666501, | Mar 30 1995 | International Business Machines Corporation | Method and apparatus for installing software |
5721824, | Apr 19 1996 | Oracle America, Inc | Multiple-package installation with package dependencies |
5752042, | Jun 07 1996 | International Business Machines Corporation | Server computer for selecting program updates for a client computer based on results of recognizer program(s) furnished to the client computer |
5828878, | Jan 20 1995 | Ericsson AB | Method and a scheduler for controlling when a server provides service with rate control to an entity |
5835777, | Mar 20 1996 | Hewlett Packard Enterprise Development LP | Method of automatically generating a software installation package |
5987636, | May 27 1998 | NEC Corporation | Static test sequence compaction using two-phase restoration and segment manipulation |
5996073, | Dec 18 1997 | CONSONA ERP, INC ; CONSONA CORPORATION | System and method for determining computer application state |
6052483, | Nov 04 1994 | THE CHASE MANHATTAN BANK, AS COLLATERAL AGENT | Methods and apparatus for classification of images using distribution maps |
6158001, | Dec 18 1997 | CONSONA ERP, INC ; CONSONA CORPORATION | Automatic configuration generation |
6163859, | Dec 02 1998 | AVOLIN, LLC | Software vault |
EP458495, | |||
EP632371, | |||
EP707264, |
Date | Maintenance Fee Events |
Feb 27 2006 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Aug 07 2009 | ASPN: Payor Number Assigned. |
Aug 07 2009 | RMPN: Payer Number De-assigned. |
Feb 01 2010 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
Jan 15 2014 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
Date | Maintenance Schedule |
Aug 27 2005 | 4 years fee payment window open |
Feb 27 2006 | 6 months grace period start (w surcharge) |
Aug 27 2006 | patent expiry (for year 4) |
Aug 27 2008 | 2 years to revive unintentionally abandoned end. (for year 4) |
Aug 27 2009 | 8 years fee payment window open |
Feb 27 2010 | 6 months grace period start (w surcharge) |
Aug 27 2010 | patent expiry (for year 8) |
Aug 27 2012 | 2 years to revive unintentionally abandoned end. (for year 8) |
Aug 27 2013 | 12 years fee payment window open |
Feb 27 2014 | 6 months grace period start (w surcharge) |
Aug 27 2014 | patent expiry (for year 12) |
Aug 27 2016 | 2 years to revive unintentionally abandoned end. (for year 12) |