This disclosure relates application installation and installation modification.
A component installation application (installer) such as a WINDOWS Installer provides product deployment and component management. For instance, an installer takes an installation package, for example, an MSI file, as input to install one or more products or applications into an original or baseline installation. The installer is typically used to modify (patch) the baseline installation according to predefined settings. To make changes or modifications to an original or baseline application (e.g., product) installation, a new, modifying installation package is created. Conventional modifying installation packages are typically not portable across different operating environments. This is because a modifying installation package is typically compatible only with the data format required by the particular operating environment and/or installer that is going to unpack the modifying installation package to perform the baseline installation modification(s). As a result, several different modifying installation packages must typically be generated to modify any particular baseline installation deployed across different operating environments (e.g., different operating systems, systems that use different types of installer applications, etc.).
Additionally, a conventional modifying installation package typically represents an entire re-installation package for a baseline installation targeted for modification. This is because the modifying installation package generally includes all aspects (e.g., information, components (files), data resources, etc.) associated with the baseline installation targeted for modification, plus and/or minus those aspects that are being modified with respect to the baseline installation. As a result, existing modifying installation packages typically include a lot of extraneous material that will not be directly utilized to actually modify a baseline application installation.
When a complex build environment is targeted for modification, the need to specify/include extraneous material into a modifying installation package can be problematic. One reason for this is because the extraneous material may represent a tremendous amount of information, possibly including specification/inclusion of many-thousands of extraneous files and/or data resources. Representing such extraneous information is typically time consuming, requiring a substantial amount of administrative supervision, as well as computer processing, and resource utilization.
Systems and methods for modifying application installations are described. In one aspect, a generic installation modifier package is created. The generic installation modifier package specifies differences between a target modified application installation and an already installed baseline application installation. The generic installation modifier package does not include information that is extraneous to modification of the already installed baseline application installation unless the information is designated as transparent to an installer application. The generic installation modifier package is communicated to a patch engine for subsequent modification of the baseline installation.
In the Figures, the left-most digit of a component reference number identifies the particular figure in which the component first appears.
Overview
The systems and methods for modifying existing application or product installations as described below with respect to
Additionally, a generic installation package is relatively lightweight as compared to a conventional modifying installation package. This is because the generic installation package does not specify extraneous information, components (files), data resources, and/or so on, of a baseline installation that is targeted for modification. Rather, the generic installation package specifies/includes only information and material representing the difference (modification) between a baseline installation targeted for modification, and the modified baseline installation.
These and other aspects of the systems and methods for bi-directional temporal error concealment are now described in greater detail.
An Exemplary System
Although not required, the systems and methods for modifying application installations are described in the general context of computer-executable instructions (program modules) being executed by a computing device such as a personal computer. Program modules generally include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. While the systems and methods are described in the foregoing context, acts and operations described hereinafter may also be implemented in hardware.
Server 102 includes program modules 108 and program data 110. Program modules 108 include, for example, editor 112. Editor 112 is configured to allow a user to create generic installation modifier package 114. In this implementation, editor 112 implements a markup language such as XML to generate generic installation modifier package 114. Generic installation modifier package 114 is generic (not proprietary) because it is not specifically designed to target a proprietary data format of a particular installer or runtime environment. Rather, content of generic installation modifier package 114 is interpreted within any arbitrary runtime environment for conversion to any arbitrary target data format used by an installer executing within that particular runtime environment or a different runtime environment. (Such generic installation modifier package 114 conversion for a baseline application installation modification is described in greater detail below in reference to a patch engine and an installer of client 106). This is in contrast to conventional installation packages, which are typically hardwired (i.e., unidirectional) in data format to conform to a particular operating environment and installer.
Besides basic identification and machine state tracking information, generic installation modifier package 114 specifies only information, components, and/or data resources that represent the difference(s) between a client 102 baseline application installation and a target modified representation of the baseline application installation. For purposes of illustration, such a baseline application installation is shown as one or more respective portions of “other applications” 116 on client 106. In this implementation, the differences indicate, for example, state tracking information, and/or modifications to the existing baseline installation, locations of files. File include resource collections, for example, such as supporting file(s) (e.g., “inf” files, executable(s), registry changes, and/or so on) and a payload of file(s) and/or configuration data (e.g., DLLs, executables, scripts, configuration data, and/or so on). Collectively, these differences are referred to as package contents. The package contents are directly specified by user interaction (e.g., keyboard, voice recognition, and/or so on) with editor 112, and not by generating an installer image (e.g., a patch file such as an MSP file) via programmatic comparison between a baseline installation package installed on the client computing device 102 and a target updated installation package for communicating to the client computing device 102.
Table 1 shows an exemplary tag set for a generic installation modifier package 114.
As shown in TABLE 1, generic installation modifier package 114 includes customizable tags, enabling a user to define, transmit, validate, and interpret data for modifying a baseline application installation. In this implementation, the tag names are arbitrary and represent data for converting contents of the generic installation modifier package 114 into a patch file. Such a patch file is described below with respect to translated patch 118. For example, the tag “patch” denotes the beginning and end of the contents for generic installation modifier package 114. The tag “state tracking information” denotes a section for supplying installation and target device (e.g., client 102) state information such as versioning, and/or other information.
The “MetaData” tag provides a data definition area to specify data that is transparent to the installer application that will parse generic installation modifier package 114. In one implementation, for example, an application (see, “other applications” 116) other than an installer application (e.g., installer 120) utilizes the transparent data to present user interface information indicating modifications made, or to be made, to a baseline application installation. (As described below, such modifications are detailed in the data area denoted by the “Application Installation Differences Information” tag pair). In another implementation, the transparent data is used to describe feature layout for a different patch file. In another implementation, the transparent data describes configuration information for an application in combination with, or independent of, components/resources for an installation modification. As can be appreciated, purpose and data format of such transparent data is arbitrary and a function of the particular implementation.
TABLE 2 shows an exemplary implementation of the MetaData tag pair in generic installation modifier package 114.
In this exemplary implementation, the metadata is provided for an application other than installer 120 for compressing to a path and application to customize a product.
An “Application Installation Differences Information” tag pair, of which there may be one or more, provides a data area to identify a particular application, and indicate the modifications to the particular application and/or associated resources, as well as the location(s) of corresponding files, data, etc. In this implementation, this data area includes table, row, and column specifications that map to corresponding ones of table, row, and column identifiers in an original patch file used to install the baseline application that is being targeted for modification. As indicated above, and although the generic installation modifier package 114 shows a single “Application Installation Differences Information” tag pair, generic installation modifier package 114 can have any number of such tag pairs—one tag pair for each application of a baseline application installation that is being modified in some manner.
Table 3 shows another exemplary implementation of generic installation modifier package 114.
In this implementation, server 102 communicates the generic installation modifier package 114 in message 122 to client 106. In another implementation, client 106 receives the generic installation modifier package 114 in some other manner (e.g., via CD-ROM, etc.). Responsive to receiving generic installation modifier package 114, client 106—and more particularly patch engine 124, parses the generic installation modifier package 114 to covert its content into a data format that is compatible data format requirements of installer application 120. For purposes of discussion and exemplary illustration, converted content of generic installation modifier package 114 is shown as translated patch 118. The data format used by installer 120, and therefore the data format of translated patch 118, is arbitrary, and typically a function of the particular architecture of the target installer 120 and/or the particular operating system used to provide a runtime environment on client 106.
In one implementation, installer 120 is a WINDOWS installer and the target data format is a MSP file data format for modification of an existing application installation, wherein the existing application installation was described by a conventional installation package in the MSI data format.
An Exemplary Procedure
An Exemplary Operating Environment
The methods and systems described herein are operational with numerous other general purpose or special purpose computing system, environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use include, but are not limited to, mobile computing devices such as mobile phones and personal digital assistants, personal computers, server computers, multiprocessor systems, microprocessor-based systems, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and so on. The invention is practiced in a distributed computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
With reference to
A computer 310 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computer 310 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 310.
Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example and not limitation, communication media includes wired media such as a wired network or a direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer-readable media.
System memory 330 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 331 and random access memory (RAM) 332. A basic input/output system 333 (BIOS), containing the basic routines that help to transfer information between elements within computer 310, such as during start-up, is typically stored in ROM 331. RAM 332 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 320. By way of example and not limitation,
The computer 310 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into the computer 310 through input devices such as a keyboard 362 and pointing device 361, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 320 through a user input interface 360 that is coupled to the system bus 321, but may be connected by other interface and bus structures, such as a parallel port, game port, or a universal serial bus (USB).
A monitor 391 or other type of display device is also connected to the system bus 321 via an interface, such as a video interface 390. In addition to the monitor, computers may also include other peripheral output devices such as printer 396 and audio devices 397, which may be connected through an output peripheral interface 395.
The computer 310 operates in a networked environment using logical connections to one or more remote computers, such as a remote computer 380. In one implementation, computer 310 represents server computing device 102 and remote computer 380 represents client computing device 106 of
When used in a LAN networking environment, the computer 310 is connected to the LAN 371 through a network interface or adapter 370. When used in a WAN networking environment, the computer 310 typically includes a modem 372 or other means for establishing communications over the WAN 373, such as the Internet. The modem 372, which may be internal or external, may be connected to the system bus 321 via the user input interface 360, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 310, or portions thereof, may be stored in the remote memory storage device. By way of example and not limitation,
Although the systems and methods for modifying application installations have been described in language specific to structural features and/or methodological operations or actions, it is understood that the implementations defined in the appended claims are not necessarily limited to the specific features or actions described. For example, although operations to create a generic installation modifier package 114 (