US20100306270A1 - Generating a local copy of a virtualized application package from a local installation - Google Patents
Generating a local copy of a virtualized application package from a local installation Download PDFInfo
- Publication number
- US20100306270A1 US20100306270A1 US12/471,476 US47147609A US2010306270A1 US 20100306270 A1 US20100306270 A1 US 20100306270A1 US 47147609 A US47147609 A US 47147609A US 2010306270 A1 US2010306270 A1 US 2010306270A1
- Authority
- US
- United States
- Prior art keywords
- file
- data
- data block
- application package
- copy
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
Definitions
- Application virtualization allows software applications to be deployed to users' computers from virtualized application packages maintained on a virtual application server.
- Application virtualization may remove the requirement for an application to be installed locally on a user's computer. Instead, a virtual application runtime may execute on the computer and stream the application components from the virtualized application package on the server.
- Application virtualization generally requires that the computer initially be connected to the virtual application server in order to execute the application and retrieve components from the virtualized application package.
- a laptop computer or other computer that is often disconnected from the network, it may be desirable for a local copy of the virtualized application package to be available, for use in the initial execution the application or the retrieval of additional components, for example.
- a computer may contain local copies of most, if not all, of the component files of the application.
- generating a copy of the original virtual application package from these local copies may be difficult, and may require that the entire virtual application package be retrieved from the virtual application server a second time, increasing network utilization.
- a copy of a virtualized application package can be generated from application component files presented in a virtual file system representation of a local installation of the application on a computer.
- the local copy of the virtualized application package can then be utilized by the computer or another computer to execute the application without having to be connected to a virtual application server.
- Generating the local copy of the virtualized application package from the local installation relieves the computer from having to retrieve the entire virtual application package from the virtual application server a second time, thus saving the additional network bandwidth utilization.
- an empty copy of the virtualized application package is generated from a skeleton file containing hash values corresponding to data blocks storing the contents of the component files in the original virtualized application package.
- the component files of the application are then retrieved from the virtual file system representation of the local installation, and each component file is divided into one or more blocks of data.
- a hash value is then computed for each block.
- the skeleton file is searched for a hash value that matches the hash value computed for each block of data. If a match is found, the block of data is copied to the corresponding data block of the empty copy of the virtualized application package.
- FIG. 1 is a block diagram showing aspects of an illustrative operating environment and several software components provided by the embodiments presented herein;
- FIG. 2 is a block diagram showing an illustrative data structure for a virtualized application package, according to embodiments described herein;
- FIG. 3 is a block diagram showing an illustrative data structure for an application package skeleton file, according to embodiments described herein;
- FIGS. 4A and 4B are flow diagrams showing one method for generating a local copy of a virtualized application package from a local installation, according to embodiments described herein;
- FIG. 5 is a block diagram showing an illustrative computer hardware and software architecture for a computing system capable of implementing aspects of the embodiments presented herein.
- FIG. 1 shows an illustrative operating environment 100 including several software components for generating a local copy of a virtualized application package from a local installation, according to embodiments provided herein.
- the environment 100 includes a user computer 102 .
- the user computer 102 may be a personal computer (“PC”), a desktop workstation, a laptop, a notebook, a personal digital assistant (“PDA”), an application server, a Web server hosting Web-based application programs, or any other computing device that can execute application programs.
- PC personal computer
- PDA personal digital assistant
- the user computer 102 executes a virtual application client 104 .
- the virtual application client 104 may allow the user computer 102 to launch and execute application software that has not been previously installed on the computer.
- the virtual application client 104 may instead stream the components of the application software in real-time over a network 108 from a virtual application server 110 executing on a server computer 112 .
- the virtual application client 104 and virtual application server 110 may be based upon the MICROSOFT® APP-V technology from MICROSOFT Corporation of Redmond, Wash., the CITRIX XENAPPTM technology from CITRIX SYSTEMS Inc. of Fort Lauderdale, Fla., or any other application streaming and virtualization platform or technologies.
- the network may be a local-area network (“LAN”), a wide-area network (“WAN”), the Internet, or any other networking topology that connects the user computer 102 to the virtual application server 110 .
- the components of the application software may be stored in a virtualized application package 114 located on a storage device 116 accessible by the server computer 112 .
- the virtualized application package 114 consists of a number of blocks 118 of data that contain application structure information as well as the individual component files and other elements of the application, as will be described in detail below in regard to FIG. 2 .
- the blocks 118 in the virtualized application package 114 may be sequenced such that the core components of the application software are streamed to the virtual application client 104 first, thereby allowing the application to be started quickly by the user computer 102 . Once the application is started, the blocks 118 containing common functions are streamed in order of priority. If a specific function of the application software is requested by the user computer 102 , then the sequence of streaming the blocks 118 may be modified to satisfy the request. Otherwise, the full application may be streamed from the virtual application server 110 to the virtual application client 104 over time in the background.
- the virtual application client 104 may create a separate virtual environment, referred to herein as an application sandbox 106 , to execute each application streamed from the virtual application server 110 .
- the application sandbox 106 allows the components of the application software to execute in isolation from the remainder of the system.
- the application software may execute using its own version of common library files, without a danger of the library files being overwritten by the installation of another software package or an update to the operating system (“OS”) of the user computer 102 .
- OS operating system
- any changes made by the initialization or execution of the application software are further isolated to the application sandbox 106 . If a user of the application software modifies configuration files or registry entries related to the application, these changes may only be reflected in the particular application sandbox 106 in which the application software is executing.
- the virtual application client 104 presents the component files and other elements of the application software to the OS and other programs executing on the user computer 102 through a virtual file system representation 120 .
- the virtual file system representation 120 may appear to the OS and the other programs as a local installation of the application, including the traditional file and folder structure.
- the OS and other programs executing on the computer may interact with these application component files through the file system provided by the OS. This allows traditional application software to be packaged, streamed, and virtualized in the manner presented herein without requiring changes to the structure of the application.
- the virtual file system representation 120 may initially reflect all the files in a typical local installation of the application software, even though some of the actual application component files have not yet been streamed from the virtual application server 110 to the virtual application client 104 . If the application or another program executing on the user computer 102 requests a specific component file from the virtual file system representation 120 which has not yet been received, the virtual application client 104 will request that the required blocks 118 from the virtualized application package 114 be streamed in real-time from the virtual application server 110 to satisfy the request.
- the virtual application client 104 may maintain any local changes made to component files or other elements during initialization or execution of the application software in the application sandbox 106 in a user delta cache 122 .
- the component files presented through the virtual file system representation 120 will include these local changes. In this way, local changes may be persisted across different executions of the application software. For example, if a particular application maintains personal user settings in an application configuration file, the blocks 118 of data streamed from the virtual application server 110 to the virtual application client 104 may contain the file with default configuration settings. Any changes made to the application configuration file by a user while the application is executing in the application sandbox 106 will be stored in the user delta cache 122 .
- the virtual application client 104 When the application or another program executing on the user computer 102 reads the application configuration file from the virtual file system representation 120 , the virtual application client 104 will combine the user changes stored in the user delta cache 122 with the blocks 118 from the virtualized application package 114 representing the original file to present the modified version of the file.
- the user computer 102 also includes an application package generation module 124 configured to generate a local copy of the virtualized application package 114 from the local installation of the application presented through the virtual file system representation 120 .
- the application package generation module 124 may be a component of the application software, streamed to the virtual application client 104 and executed in the application sandbox 106 , or it may be a separate application module installed and executed on the user computer 102 .
- the application package generation module 124 accesses the individual component files and other elements of the software application through the virtual file system representation 120 and generates a local copy of the original virtualized application package 114 on a local storage device 126 .
- the application package generation module 124 may have to retrieve specific blocks 118 of the virtualized application package 114 from the server computer 112 in order to complete the generation of the local copy of the virtualized application package 114 .
- the application package generation module 124 may request the specific blocks 118 of the virtualized application package 114 directly from the virtual application server 110 , or it may utilize a file transfer service 128 that has access to the virtualized application package 114 stored on the server computer 112 . It will be appreciated that any of a number of file transfer services 128 known in the art that support retrieval of a byte range of a file may be utilized by the application package generation module 124 to retrieve the blocks of the virtual application package 114 .
- FIG. 2 shows one example of a file layout 200 of a virtualized application package 114 , according to embodiments.
- the virtualized application package 114 may consist of a number of blocks 118 of data. Theses blocks 118 may be further divided into header blocks 202 A- 202 K (also referred to herein as header blocks 202 ) and data blocks 204 A- 204 N (also referred to herein as data blocks 204 ).
- the first part of the virtualized application package 114 may contain one or more header blocks 202 .
- the header blocks 202 may contain specific information regarding the properties and structure of the application software contained in the virtualized application package 114 , such as user access information, version information, execution requirements, and the file and folder structure of the installation to be reproduced by the virtual application client 104 .
- the header blocks may map the application component files to their respective data blocks 204 , describe in detail below.
- header blocks 202 There may be a fixed number of header blocks 202 in every virtualized application package 114 .
- the number of header blocks 202 may depend on the amount of header data stored in a particular virtualized application package 114 .
- each of the header blocks 202 may be of a fixed size, for example 64 KB, or the size of the header blocks 202 may be variable. It will be appreciated that the number, size, and contents of the header blocks 202 may vary based on the application streaming technology utilized by the virtual application client 104 and the virtual application server 110 . In addition, the contents of the header blocks 202 are likely not re-creatable from the virtual file system representation 120 on the user computer 102 , even after the virtualized application package 114 has been streamed to the computer.
- the header blocks 202 in the virtualized application package 114 are followed by a number of data blocks 204 .
- the data blocks 204 contain the contents of the various component files and other elements of the application.
- the contents of the data blocks 204 may be compressed to improve the efficiency of streaming the blocks to the virtual application client 104 .
- the data blocks 204 may vary in size, but each block is less than a maximum block size, for example 64 KB.
- a component file of the application is broken down into one or more blocks of the maximum block size or less, and then each block is compressed using a lossless compression algorithm, such as BZIP2.
- the resulting compressed data blocks 204 are then added to the virtualized application package 114 . It will be appreciated that this approach results in each data block 204 containing all or a portion of only one component file, while one component file may occupy several data blocks 204 . While FIG. 2 shows a relatively similar number of header blocks 202 and data blocks 204 , it will be further appreciated that the number of data blocks 204 may far exceed the number of header blocks 202 in the virtualized application package 114 for a typical application.
- Each data block 204 may also contain a data block header 206 A- 206 N (also referred to herein as data block header 206 ).
- the data block header 206 contains information regarding the size and position within the virtualized application package 114 of the corresponding data block 204 .
- the data block header 206 may also contain other information regarding the corresponding data block 204 , such as an identifier of the component file to which the data block belongs and the uncompressed size of the data stored in the block.
- the data block header 206 may be of a fixed size, such as 45 bytes, depending on the data contained therein.
- FIG. 3 shows a layout of a virtualized application package skeleton file 300 corresponding to the virtualized application package 114 shown in FIG. 2 , according to embodiments.
- the skeleton file 300 is utilized by the application package generation module 124 to generate an “empty” virtualized application package as well as to map compressed data blocks from component files of the application into the local copy of the virtualized application package 114 , as will be explained in detail below in regard to FIGS. 4A and 4B .
- the skeleton file 300 contains the same header blocks 202 A- 202 K as the corresponding virtualized application package 114 .
- the skeleton file 300 includes a fixed size block of data containing the data block header 206 A- 206 N from the corresponding data block 204 A- 204 N, and a data block hash 302 A- 302 N (also referred to herein as data block hash 302 ).
- the data block hash 302 A- 302 N contains a hash value computed from the compressed data contained in the corresponding data block 204 A- 204 N.
- the skeleton file 300 may be generated from the corresponding virtualized application package 114 before the application is made available for streaming by the virtual application server 110 .
- the skeleton file 300 may be constructed simultaneously with the packaging of the application software into the virtualized application package 114 .
- the data block hashes 302 may be computed using a hashing algorithm that results in a hash value of sufficient length such that each data block hash value represents a nearly unique identifier for the corresponding data block 204 in the virtualized application package 114 .
- the data block hashes 302 are computed using the MD5 algorithm resulting in a 128-bit (16 byte) hash value. It will be appreciated that any number of hashing algorithms could be utilized in computing the data block hash 302 for each of the data blocks 204 in the virtualized application package 114 . It will be further appreciated that, because the skeleton file 300 contains only the data block hashes 302 and not the full data blocks 204 , the skeleton file 300 may be significantly smaller in size than the corresponding virtualized application package 114 . The skeleton file 300 may be retrieved by the application package generation module 124 from the server computer as a separate file, or the skeleton file may be appended to the end of the virtual application package 114 on the server.
- FIGS. 4A and 4B additional details will be provided regarding the embodiments presented herein.
- the logical operations described with respect to FIGS. 4A and 4B are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system.
- the implementation is a matter of choice dependent on the performance and other requirements of the computing system.
- the logical operations described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. It should also be appreciated that more or fewer operations may be performed than shown in the figures and described herein. The operations may also be performed in a different order than described.
- FIGS. 4A and 4B illustrate a routine 400 for generating a local copy of the original virtualized application package 114 from the virtual file system representation 120 and the corresponding skeleton file 300 described above in regard to FIG. 3 .
- the routine 400 begins at operation 402 depicted in FIG. 4A , where the application package generation module 124 generates an “empty” copy of the virtualized application package 114 on the local storage device 126 of the user computer 102 .
- the empty application package is generated from the skeleton file 300 .
- the application package generation module 124 first copies the header blocks 202 A- 202 K from the skeleton file 300 to the empty application package. Then, the application package generation module 124 creates a data block 204 in the empty package for each data block header 206 and data block hash 302 pair in the skeleton file 300 . Because the data block header 206 contains information regarding the size of the corresponding data block 204 , the application package generation module 124 may reserve space for the entire data block but only copy the data block header 206 from the skeleton file 300 to the empty application package.
- the routine 400 proceeds to operation 404 , where the application package generation module 124 iterates each component file of the application software that is to be included in the local copy of the virtualized application package 114 .
- the application package generation module 124 may simply iterate through every file in the virtual file system representation 120 , or it may utilize an inventory of files known to be in the application package to drive the process.
- the routine 400 proceeds from operation 404 to operation 406 , where the application package generation module 124 retrieves the first component file to process from the virtual file system representation 120 in the application sandbox 106 .
- every component file may be represented in the virtual file system representation 120 , even if the blocks 118 of the virtualized application package 114 containing the component file have not yet been streamed to the virtual application client 104 .
- the application package generation module 124 attempts to access the component file, if it has not yet been streamed to the client, the virtual application client 104 will request that the corresponding blocks 118 be streamed from the virtual application server 110 .
- routine 400 proceeds from operation 406 to operation 408 , where the application package generation module 124 divides the component file into blocks based on the maximum block size of the virtualized application package 114 . It will be appreciated that the last block of the file may not be the full maximum block size.
- the routine 400 then proceeds to operation 410 , where the application package generation module 124 compresses the first block of the component file, utilizing the same compression algorithm utilized in the creation of the original virtualized application package 114 on the server computer 112 .
- the compression algorithm may be known to the application package generation module 124 , or the algorithm may be determined by reading information from the header blocks 202 of the empty application package.
- the application package generation module 124 utilizes the BZIP2 compression scheme to compress the data blocks.
- the routine 400 proceeds to operation 412 , where the application package generation module 124 computes a hash value for the compressed block using the same hashing algorithm utilized to generate the skeleton file 300 .
- the MD5 hashing algorithm is used, producing a 128-bit hash value.
- the routine 400 proceeds to operation 414 , where the application package generation module 124 searches the skeleton file 300 for a data block hash 302 having the same value as the hash value calculated for the block. If, at operation 416 , no matching data block hash 302 is found, then the routine 400 proceeds to operation 418 , where the compressed block is discarded.
- a compressed block having no matching data block hash 302 in the skeleton file 300 is likely due to a component file that has been modified locally, as will be discussed below in regard to operation 426 .
- the routine 400 proceeds to operation 420 , where the compressed block is copied into the data block 204 of the empty virtualized application package file corresponding to the matching data block hash 302 in the skeleton file 300 .
- the length of the compressed block may be checked against the length of the compressed data specified in the data block header 206 of the matching data block 204 to further verify that the compressed block should be copied into the data block. It will be appreciated that there is a possibility of two, identical component files or other elements existing in an application package, resulting in identical hash values calculated from the corresponding blocks of data. Therefore, even after finding a first matching data block hash 302 , the application package generation module 124 may continue to search the skeleton file 300 for any remaining matching data block hash values.
- the routine 400 proceeds from operation 418 or operation 420 to operation 422 , as shown in FIG. 4B , where the application package generation module 124 determines if there are more blocks from the current component file to be processed. If more blocks exist, then the routine 400 returns to operation 410 where the routine is repeated for the next block until all blocks of the current component file have been processed. Once all blocks of the current component file have been processed, the routine 400 proceeds from operation 422 to operation 424 , where the application package generation module 124 determines if there are more component files to be included in the local copy of the virtualized application package 114 . If more files are to be processed, then the routine 400 returns to operation 406 where the routine is repeated for the next component file until all component files of the application package have been processed.
- routine 400 proceeds from operation 424 to operation 426 , where the application package generation module 124 iterates through any remaining empty data blocks 204 in the local copy of the virtualized application package 114 .
- the local copy of the virtualized application package 114 will be substantially complete.
- the virtual application client 104 maintains any local changes made to component files or other elements during initialization or execution of the application software in the user delta cache 122 . Component files accessed through the virtual file system representation 120 are presented including these local changes.
- a component file has been changed locally, when the application package generation module 124 retrieves the file, it will include the local changes from the user delta cache 122 . This may result in the hash values computed for one or more of the compressed blocks corresponding to the component file not have matching data block hash 302 values in the skeleton file 300 . Accordingly, once all of the component files have been processed, there may be a few remaining empty data blocks 204 in the local copy of the virtualized application package 114 corresponding to those component files with local changes.
- the application package generation module 124 iterates through these remaining empty data blocks 204 in the local copy of the virtualized application package 114 . From operation 426 , the routine proceeds to operation 428 , where the application package generation module 124 retrieves the data block 204 from the server computer 112 containing the original virtualized application package 114 corresponding to the first empty data block in the local copy of the virtualized application package 114 .
- the application package generation module 124 utilizes a file transfer service 128 located on the server computer 112 to retrieve a byte range from the original virtualized application package 114 .
- the byte range to retrieve can be ascertained from the information stored in the data block header 206 regarding the size and position within the original virtualized application package 114 of the data block 204 , as discussed above in regard to FIG. 2 .
- the application package generation module 124 may utilize other methods to retrieve the data block 204 from the original virtualized application package 114 , including requesting the block from the virtual application server 110 . It will be appreciated that the process of retrieving only missing data blocks 204 uses less network resources than would be used by retrieving the entire file of which the missing data block is a part.
- the routine 400 proceeds to operation 430 where the application package generation module 124 copies the retrieved data block 204 to the empty data block in the local copy of the virtualized application package 114 .
- the routine then proceeds from operation 430 to operation 432 , where the application package generation module 124 determines if more empty data blocks 204 exist in the local copy of the virtualized application package 114 . If more empty data blocks 204 exist, then the routine 400 returns to operation 428 where the routine is repeated for the next empty data block 204 , until all the empty data blocks have been retrieved from the server computer 112 . Once no more empty data blocks 204 exist in the local copy of the virtualized application package 114 , the routine 400 ends.
- routine 400 described above could be used to generate local copies of other types of file packages, beyond the virtualized application package 114 described above.
- a local copy of a backup file created by a backup program could be recreated from the associated files in the file system.
- a local copy of an archive file such as a ZIP file, could be recreated using the method described above. It is intended that this application include all such generations of a local copy of a file package from a corresponding skeleton file containing data block hashes and files from a file system.
- FIG. 5 shows an example computer architecture for a computer 500 capable of executing the software components described herein for generating a local copy of a virtualized application package from a local installation, in the manner presented above.
- the computer architecture shown in FIG. 5 illustrates a conventional computing device, PDA, digital cellular phone, communication device, desktop computer, laptop, or server computer, and may be utilized to execute any aspects of the software components presented herein described as executing on the user computer 102 , server computer 112 , or other computing platform.
- the computer architecture shown in FIG. 5 includes a central processing unit (“CPU”) 502 .
- the CPU 502 may be a standard central processor that performs the arithmetic and logical operations necessary for the operation of the computer 500 .
- the CPU 502 performs the necessary operations by transitioning from one discrete, physical state to the next through the manipulation of switching elements that differentiate between and change these states.
- Switching elements may generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on the logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements may be combined to create more complex logic circuits, including registers, adders-subtractors, arithmetic logic units, floating-point units, and other logic elements.
- the computer 500 may include a multitude of CPUs 502 .
- the computer architecture further includes a system memory 508 , including a random access memory (“RAM”) 514 and a read-only memory 516 (“ROM”), and a system bus 504 that couples the memory to the CPU 502 .
- the computer 500 also includes a mass storage device 510 for storing an operating system 518 , application programs, and other program modules, which are described in greater detail herein.
- the mass storage device 510 is connected to the CPU 502 through a mass storage controller (not shown) connected to the bus 504 .
- the mass storage device 510 provides non-volatile storage for the computer 500 .
- the computer 500 may store information on the mass storage device 510 by transforming the physical state of the device to reflect the information being stored. The specific transformation of physical state may depend on various factors, in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the mass storage device, whether the mass storage device is characterized as primary or secondary storage, and the like.
- the computer 500 may store information to the mass storage device 510 by issuing instructions to the mass storage controller to alter the magnetic characteristics of a particular location within a magnetic disk drive, the reflective or refractive characteristics of a particular location in an optical storage device, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage device.
- Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.
- the computer 500 may further read information from the mass storage device 510 by detecting the physical states or characteristics of one or more particular locations within the mass storage device.
- a number of program modules and data files may be stored in the mass storage device 510 and RAM 514 of the computer 500 , including an operating system 518 suitable for controlling the operation of a computer.
- the mass storage device 510 and RAM 514 may also store one or more program modules.
- the mass storage device 510 and the RAM 514 may store the application package generation module 124 , which was described in detail above in regard to FIG. 1 .
- the mass storage device 510 and the RAM 514 may also store other types of program modules or data.
- computer 500 may have access to other computer-readable media to store and retrieve information, such as program modules, data structures, or other data.
- computer-readable media may include volatile and non-volatile, 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-readable media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks (DVD), HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computer 500 .
- the computer-readable storage medium may be encoded with computer-executable instructions that, when loaded into the computer 500 , may transform the computer system from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein.
- the computer-executable instructions may be encoded on the computer-readable storage medium by altering the electrical, optical, magnetic, or other physical characteristics of particular locations within the media. These computer-executable instructions transform the computer 500 by specifying how the CPU 502 transitions between states, as described above.
- the computer 500 may have access to computer-readable storage media storing computer-executable instructions that, when executed by the computer system, perform the routine 400 , described above in regard to FIGS. 4A and 4B .
- the computer 500 may operate in a networked environment using logical connections to remote computing devices and computer systems through a network 108 .
- the computer 500 may connect to the network 108 through a network interface unit 506 connected to the bus 504 . It should be appreciated that the network interface unit 506 may also be utilized to connect to other types of networks and remote computer systems.
- the computer 500 may also include an input/output controller 512 for receiving and processing input from a number of input devices, including a keyboard, a mouse, a touchpad, a touch screen, an electronic stylus, or other type of input device. Similarly, the input/output controller 512 may provide output to a display device, such as a computer monitor, a flat-panel display, a digital projector, a printer, a plotter, or other type of output device.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
- Application virtualization allows software applications to be deployed to users' computers from virtualized application packages maintained on a virtual application server. Application virtualization may remove the requirement for an application to be installed locally on a user's computer. Instead, a virtual application runtime may execute on the computer and stream the application components from the virtualized application package on the server.
- Application virtualization generally requires that the computer initially be connected to the virtual application server in order to execute the application and retrieve components from the virtualized application package. In a laptop computer or other computer that is often disconnected from the network, it may be desirable for a local copy of the virtualized application package to be available, for use in the initial execution the application or the retrieval of additional components, for example. If a computer has previously executed the application from the virtual application server, it may contain local copies of most, if not all, of the component files of the application. However, generating a copy of the original virtual application package from these local copies may be difficult, and may require that the entire virtual application package be retrieved from the virtual application server a second time, increasing network utilization.
- It is with respect to these considerations and others that the disclosure made herein is presented.
- Technologies are described herein for generating a local copy of a virtualized application package from a local installation. Utilizing the technologies described herein, a copy of a virtualized application package can be generated from application component files presented in a virtual file system representation of a local installation of the application on a computer. The local copy of the virtualized application package can then be utilized by the computer or another computer to execute the application without having to be connected to a virtual application server. Generating the local copy of the virtualized application package from the local installation relieves the computer from having to retrieve the entire virtual application package from the virtual application server a second time, thus saving the additional network bandwidth utilization.
- According to one embodiment, an empty copy of the virtualized application package is generated from a skeleton file containing hash values corresponding to data blocks storing the contents of the component files in the original virtualized application package. The component files of the application are then retrieved from the virtual file system representation of the local installation, and each component file is divided into one or more blocks of data. A hash value is then computed for each block. The skeleton file is searched for a hash value that matches the hash value computed for each block of data. If a match is found, the block of data is copied to the corresponding data block of the empty copy of the virtualized application package.
- It should be appreciated that the above-described subject matter may be implemented as a computer-controlled apparatus, a computer process, a computing system, or as an article of manufacture such as a computer-readable medium. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.
- This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended that this Summary be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
-
FIG. 1 is a block diagram showing aspects of an illustrative operating environment and several software components provided by the embodiments presented herein; -
FIG. 2 is a block diagram showing an illustrative data structure for a virtualized application package, according to embodiments described herein; -
FIG. 3 is a block diagram showing an illustrative data structure for an application package skeleton file, according to embodiments described herein; -
FIGS. 4A and 4B are flow diagrams showing one method for generating a local copy of a virtualized application package from a local installation, according to embodiments described herein; and -
FIG. 5 is a block diagram showing an illustrative computer hardware and software architecture for a computing system capable of implementing aspects of the embodiments presented herein. - The following detailed description is directed to technologies for generating a local copy of a virtualized application package utilizing the files from a virtual file system representation of a local installation of the application. While the subject matter described herein is presented in the general context of program modules that execute in conjunction with the execution of an operating system and application programs on a computer system, those skilled in the art will recognize that other implementations may be performed in combination with other types of program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the subject matter described herein may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.
- In the following detailed description, references are made to the accompanying drawings that form a part hereof and that show, by way of illustration, specific embodiments or examples. In the accompanying drawings, like numerals represent like elements through the several figures.
-
FIG. 1 shows anillustrative operating environment 100 including several software components for generating a local copy of a virtualized application package from a local installation, according to embodiments provided herein. Theenvironment 100 includes a user computer 102. The user computer 102 may be a personal computer (“PC”), a desktop workstation, a laptop, a notebook, a personal digital assistant (“PDA”), an application server, a Web server hosting Web-based application programs, or any other computing device that can execute application programs. - The user computer 102 executes a
virtual application client 104. Thevirtual application client 104 may allow the user computer 102 to launch and execute application software that has not been previously installed on the computer. Thevirtual application client 104 may instead stream the components of the application software in real-time over anetwork 108 from avirtual application server 110 executing on aserver computer 112. Thevirtual application client 104 andvirtual application server 110 may be based upon the MICROSOFT® APP-V technology from MICROSOFT Corporation of Redmond, Wash., the CITRIX XENAPP™ technology from CITRIX SYSTEMS Inc. of Fort Lauderdale, Fla., or any other application streaming and virtualization platform or technologies. The network may be a local-area network (“LAN”), a wide-area network (“WAN”), the Internet, or any other networking topology that connects the user computer 102 to thevirtual application server 110. - The components of the application software may be stored in a virtualized
application package 114 located on astorage device 116 accessible by theserver computer 112. According to embodiments, the virtualizedapplication package 114 consists of a number ofblocks 118 of data that contain application structure information as well as the individual component files and other elements of the application, as will be described in detail below in regard toFIG. 2 . - The
blocks 118 in the virtualizedapplication package 114 may be sequenced such that the core components of the application software are streamed to thevirtual application client 104 first, thereby allowing the application to be started quickly by the user computer 102. Once the application is started, theblocks 118 containing common functions are streamed in order of priority. If a specific function of the application software is requested by the user computer 102, then the sequence of streaming theblocks 118 may be modified to satisfy the request. Otherwise, the full application may be streamed from thevirtual application server 110 to thevirtual application client 104 over time in the background. - The
virtual application client 104 may create a separate virtual environment, referred to herein as anapplication sandbox 106, to execute each application streamed from thevirtual application server 110. Theapplication sandbox 106 allows the components of the application software to execute in isolation from the remainder of the system. For example, the application software may execute using its own version of common library files, without a danger of the library files being overwritten by the installation of another software package or an update to the operating system (“OS”) of the user computer 102. In addition, any changes made by the initialization or execution of the application software are further isolated to theapplication sandbox 106. If a user of the application software modifies configuration files or registry entries related to the application, these changes may only be reflected in theparticular application sandbox 106 in which the application software is executing. - According to embodiments, the
virtual application client 104 presents the component files and other elements of the application software to the OS and other programs executing on the user computer 102 through a virtualfile system representation 120. The virtualfile system representation 120 may appear to the OS and the other programs as a local installation of the application, including the traditional file and folder structure. The OS and other programs executing on the computer may interact with these application component files through the file system provided by the OS. This allows traditional application software to be packaged, streamed, and virtualized in the manner presented herein without requiring changes to the structure of the application. - The virtual
file system representation 120 may initially reflect all the files in a typical local installation of the application software, even though some of the actual application component files have not yet been streamed from thevirtual application server 110 to thevirtual application client 104. If the application or another program executing on the user computer 102 requests a specific component file from the virtualfile system representation 120 which has not yet been received, thevirtual application client 104 will request that the requiredblocks 118 from thevirtualized application package 114 be streamed in real-time from thevirtual application server 110 to satisfy the request. - The
virtual application client 104 may maintain any local changes made to component files or other elements during initialization or execution of the application software in theapplication sandbox 106 in auser delta cache 122. The component files presented through the virtualfile system representation 120 will include these local changes. In this way, local changes may be persisted across different executions of the application software. For example, if a particular application maintains personal user settings in an application configuration file, theblocks 118 of data streamed from thevirtual application server 110 to thevirtual application client 104 may contain the file with default configuration settings. Any changes made to the application configuration file by a user while the application is executing in theapplication sandbox 106 will be stored in theuser delta cache 122. When the application or another program executing on the user computer 102 reads the application configuration file from the virtualfile system representation 120, thevirtual application client 104 will combine the user changes stored in theuser delta cache 122 with theblocks 118 from thevirtualized application package 114 representing the original file to present the modified version of the file. - It will be appreciated that, even though all of the
blocks 118 from thevirtualized application package 114 for a particular application may have been streamed to thevirtual application client 104 on the user computer 102, it may not be possible for a program executing on the computer to access the original contents of thevirtualized application package 114. This is because access to the contents may be limited to the virtualfile system representation 120, which presents the individual component files and other elements of the application including local modifications. It may be desired, however, to produce a local copy of the originalvirtualized application package 114. For example, the local copy of thevirtualized application package 114 may be copied to another computer, such as a laptop, so that that the application software may be executed by the laptop even when the laptop is not connected to thenetwork 108. Or, the user computer 102 may need a local copy of thevirtualized application package 114 in order to repair the local installation of the application while being used offline. - According to embodiments, the user computer 102 also includes an application
package generation module 124 configured to generate a local copy of thevirtualized application package 114 from the local installation of the application presented through the virtualfile system representation 120. The applicationpackage generation module 124 may be a component of the application software, streamed to thevirtual application client 104 and executed in theapplication sandbox 106, or it may be a separate application module installed and executed on the user computer 102. - As will be described in detail below in regard to
FIGS. 4A and 4B , the applicationpackage generation module 124 accesses the individual component files and other elements of the software application through the virtualfile system representation 120 and generates a local copy of the originalvirtualized application package 114 on alocal storage device 126. In one embodiment, the applicationpackage generation module 124 may have to retrievespecific blocks 118 of thevirtualized application package 114 from theserver computer 112 in order to complete the generation of the local copy of thevirtualized application package 114. The applicationpackage generation module 124 may request thespecific blocks 118 of thevirtualized application package 114 directly from thevirtual application server 110, or it may utilize afile transfer service 128 that has access to thevirtualized application package 114 stored on theserver computer 112. It will be appreciated that any of a number offile transfer services 128 known in the art that support retrieval of a byte range of a file may be utilized by the applicationpackage generation module 124 to retrieve the blocks of thevirtual application package 114. -
FIG. 2 shows one example of afile layout 200 of avirtualized application package 114, according to embodiments. As described above, thevirtualized application package 114 may consist of a number ofblocks 118 of data. Theses blocks 118 may be further divided into header blocks 202A-202K (also referred to herein as header blocks 202) and data blocks 204A-204N (also referred to herein as data blocks 204). - The first part of the
virtualized application package 114 may contain one or more header blocks 202. The header blocks 202 may contain specific information regarding the properties and structure of the application software contained in thevirtualized application package 114, such as user access information, version information, execution requirements, and the file and folder structure of the installation to be reproduced by thevirtual application client 104. In addition, the header blocks may map the application component files to their respective data blocks 204, describe in detail below. - There may be a fixed number of header blocks 202 in every
virtualized application package 114. Alternatively, the number of header blocks 202 may depend on the amount of header data stored in a particularvirtualized application package 114. Further, each of the header blocks 202 may be of a fixed size, for example 64KB, or the size of the header blocks 202 may be variable. It will be appreciated that the number, size, and contents of the header blocks 202 may vary based on the application streaming technology utilized by thevirtual application client 104 and thevirtual application server 110. In addition, the contents of the header blocks 202 are likely not re-creatable from the virtualfile system representation 120 on the user computer 102, even after thevirtualized application package 114 has been streamed to the computer. - As shown in the
exemplary file layout 200, the header blocks 202 in thevirtualized application package 114 are followed by a number of data blocks 204. The data blocks 204 contain the contents of the various component files and other elements of the application. The contents of the data blocks 204 may be compressed to improve the efficiency of streaming the blocks to thevirtual application client 104. The data blocks 204 may vary in size, but each block is less than a maximum block size, for example 64 KB. - According to one embodiment, a component file of the application is broken down into one or more blocks of the maximum block size or less, and then each block is compressed using a lossless compression algorithm, such as BZIP2. The resulting compressed data blocks 204 are then added to the
virtualized application package 114. It will be appreciated that this approach results in each data block 204 containing all or a portion of only one component file, while one component file may occupy several data blocks 204. WhileFIG. 2 shows a relatively similar number of header blocks 202 and data blocks 204, it will be further appreciated that the number of data blocks 204 may far exceed the number of header blocks 202 in thevirtualized application package 114 for a typical application. - Each data block 204 may also contain a data block header 206A-206N (also referred to herein as data block header 206). In one embodiment, the data block header 206 contains information regarding the size and position within the
virtualized application package 114 of the corresponding data block 204. The data block header 206 may also contain other information regarding the corresponding data block 204, such as an identifier of the component file to which the data block belongs and the uncompressed size of the data stored in the block. The data block header 206 may be of a fixed size, such as 45 bytes, depending on the data contained therein. -
FIG. 3 shows a layout of a virtualized applicationpackage skeleton file 300 corresponding to thevirtualized application package 114 shown inFIG. 2 , according to embodiments. Theskeleton file 300 is utilized by the applicationpackage generation module 124 to generate an “empty” virtualized application package as well as to map compressed data blocks from component files of the application into the local copy of thevirtualized application package 114, as will be explained in detail below in regard toFIGS. 4A and 4B . - As shown in
FIG. 3 , theskeleton file 300 contains the same header blocks 202A-202K as the correspondingvirtualized application package 114. Following the header blocks 202, for each of the data blocks 204A-204N in the correspondingvirtualized application package 114, theskeleton file 300 includes a fixed size block of data containing the data block header 206A-206N from the corresponding data block 204A-204N, and adata block hash 302A-302N (also referred to herein as data block hash 302). The data blockhash 302A-302N contains a hash value computed from the compressed data contained in the corresponding data block 204A-204N. - According to embodiments, the
skeleton file 300 may be generated from the correspondingvirtualized application package 114 before the application is made available for streaming by thevirtual application server 110. Alternatively, theskeleton file 300 may be constructed simultaneously with the packaging of the application software into thevirtualized application package 114. The data block hashes 302 may be computed using a hashing algorithm that results in a hash value of sufficient length such that each data block hash value represents a nearly unique identifier for the corresponding data block 204 in thevirtualized application package 114. - According to one embodiment, the data block hashes 302 are computed using the MD5 algorithm resulting in a 128-bit (16 byte) hash value. It will be appreciated that any number of hashing algorithms could be utilized in computing the data block hash 302 for each of the data blocks 204 in the
virtualized application package 114. It will be further appreciated that, because theskeleton file 300 contains only the data block hashes 302 and not the full data blocks 204, theskeleton file 300 may be significantly smaller in size than the correspondingvirtualized application package 114. Theskeleton file 300 may be retrieved by the applicationpackage generation module 124 from the server computer as a separate file, or the skeleton file may be appended to the end of thevirtual application package 114 on the server. - Referring now to
FIGS. 4A and 4B , additional details will be provided regarding the embodiments presented herein. It should be appreciated that the logical operations described with respect toFIGS. 4A and 4B are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. It should also be appreciated that more or fewer operations may be performed than shown in the figures and described herein. The operations may also be performed in a different order than described. -
FIGS. 4A and 4B illustrate a routine 400 for generating a local copy of the originalvirtualized application package 114 from the virtualfile system representation 120 and thecorresponding skeleton file 300 described above in regard toFIG. 3 . The routine 400 begins atoperation 402 depicted inFIG. 4A , where the applicationpackage generation module 124 generates an “empty” copy of thevirtualized application package 114 on thelocal storage device 126 of the user computer 102. The empty application package is generated from theskeleton file 300. - The application
package generation module 124 first copies the header blocks 202A-202K from theskeleton file 300 to the empty application package. Then, the applicationpackage generation module 124 creates a data block 204 in the empty package for each data block header 206 and data block hash 302 pair in theskeleton file 300. Because the data block header 206 contains information regarding the size of the corresponding data block 204, the applicationpackage generation module 124 may reserve space for the entire data block but only copy the data block header 206 from theskeleton file 300 to the empty application package. - From
operation 402, the routine 400 proceeds tooperation 404, where the applicationpackage generation module 124 iterates each component file of the application software that is to be included in the local copy of thevirtualized application package 114. The applicationpackage generation module 124 may simply iterate through every file in the virtualfile system representation 120, or it may utilize an inventory of files known to be in the application package to drive the process. - The routine 400 proceeds from
operation 404 tooperation 406, where the applicationpackage generation module 124 retrieves the first component file to process from the virtualfile system representation 120 in theapplication sandbox 106. As described above, every component file may be represented in the virtualfile system representation 120, even if theblocks 118 of thevirtualized application package 114 containing the component file have not yet been streamed to thevirtual application client 104. When the applicationpackage generation module 124 attempts to access the component file, if it has not yet been streamed to the client, thevirtual application client 104 will request that the correspondingblocks 118 be streamed from thevirtual application server 110. - Next, the routine 400 proceeds from
operation 406 tooperation 408, where the applicationpackage generation module 124 divides the component file into blocks based on the maximum block size of thevirtualized application package 114. It will be appreciated that the last block of the file may not be the full maximum block size. The routine 400 then proceeds tooperation 410, where the applicationpackage generation module 124 compresses the first block of the component file, utilizing the same compression algorithm utilized in the creation of the originalvirtualized application package 114 on theserver computer 112. The compression algorithm may be known to the applicationpackage generation module 124, or the algorithm may be determined by reading information from the header blocks 202 of the empty application package. According to one embodiment, the applicationpackage generation module 124 utilizes the BZIP2 compression scheme to compress the data blocks. - From
operation 410, the routine 400 proceeds tooperation 412, where the applicationpackage generation module 124 computes a hash value for the compressed block using the same hashing algorithm utilized to generate theskeleton file 300. According to one embodiment, the MD5 hashing algorithm is used, producing a 128-bit hash value. Next, the routine 400 proceeds tooperation 414, where the applicationpackage generation module 124 searches theskeleton file 300 for a data block hash 302 having the same value as the hash value calculated for the block. If, atoperation 416, no matching data block hash 302 is found, then the routine 400 proceeds tooperation 418, where the compressed block is discarded. A compressed block having no matching data block hash 302 in theskeleton file 300 is likely due to a component file that has been modified locally, as will be discussed below in regard tooperation 426. - If, however, a matching data block hash 302 is found in the
skeleton file 300, the routine 400 proceeds tooperation 420, where the compressed block is copied into the data block 204 of the empty virtualized application package file corresponding to the matching data block hash 302 in theskeleton file 300. In a further embodiment, the length of the compressed block may be checked against the length of the compressed data specified in the data block header 206 of the matching data block 204 to further verify that the compressed block should be copied into the data block. It will be appreciated that there is a possibility of two, identical component files or other elements existing in an application package, resulting in identical hash values calculated from the corresponding blocks of data. Therefore, even after finding a first matching data block hash 302, the applicationpackage generation module 124 may continue to search theskeleton file 300 for any remaining matching data block hash values. - The routine 400 proceeds from
operation 418 oroperation 420 tooperation 422, as shown inFIG. 4B , where the applicationpackage generation module 124 determines if there are more blocks from the current component file to be processed. If more blocks exist, then the routine 400 returns tooperation 410 where the routine is repeated for the next block until all blocks of the current component file have been processed. Once all blocks of the current component file have been processed, the routine 400 proceeds fromoperation 422 tooperation 424, where the applicationpackage generation module 124 determines if there are more component files to be included in the local copy of thevirtualized application package 114. If more files are to be processed, then the routine 400 returns tooperation 406 where the routine is repeated for the next component file until all component files of the application package have been processed. - Once all component files to be included in the local copy of the
virtualized application package 114 have been processed, the routine 400 proceeds fromoperation 424 tooperation 426, where the applicationpackage generation module 124 iterates through any remaining empty data blocks 204 in the local copy of thevirtualized application package 114. It will be appreciated that after processing all the components files in the application inventory or presented through the virtualfile system representation 120, the local copy of thevirtualized application package 114 will be substantially complete. However, as discussed above in regard toFIG. 1 , thevirtual application client 104 maintains any local changes made to component files or other elements during initialization or execution of the application software in theuser delta cache 122. Component files accessed through the virtualfile system representation 120 are presented including these local changes. - Therefore, if a component file has been changed locally, when the application
package generation module 124 retrieves the file, it will include the local changes from theuser delta cache 122. This may result in the hash values computed for one or more of the compressed blocks corresponding to the component file not have matching data block hash 302 values in theskeleton file 300. Accordingly, once all of the component files have been processed, there may be a few remaining empty data blocks 204 in the local copy of thevirtualized application package 114 corresponding to those component files with local changes. - At
operation 426, the applicationpackage generation module 124 iterates through these remaining empty data blocks 204 in the local copy of thevirtualized application package 114. Fromoperation 426, the routine proceeds tooperation 428, where the applicationpackage generation module 124 retrieves the data block 204 from theserver computer 112 containing the originalvirtualized application package 114 corresponding to the first empty data block in the local copy of thevirtualized application package 114. - In one embodiment, the application
package generation module 124 utilizes afile transfer service 128 located on theserver computer 112 to retrieve a byte range from the originalvirtualized application package 114. The byte range to retrieve can be ascertained from the information stored in the data block header 206 regarding the size and position within the originalvirtualized application package 114 of the data block 204, as discussed above in regard toFIG. 2 . In further embodiments, the applicationpackage generation module 124 may utilize other methods to retrieve the data block 204 from the originalvirtualized application package 114, including requesting the block from thevirtual application server 110. It will be appreciated that the process of retrieving only missing data blocks 204uses less network resources than would be used by retrieving the entire file of which the missing data block is a part. - From
operation 428, the routine 400 proceeds tooperation 430 where the applicationpackage generation module 124 copies the retrieved data block 204 to the empty data block in the local copy of thevirtualized application package 114. The routine then proceeds fromoperation 430 tooperation 432, where the applicationpackage generation module 124 determines if more empty data blocks 204 exist in the local copy of thevirtualized application package 114. If more empty data blocks 204 exist, then the routine 400 returns tooperation 428 where the routine is repeated for the next empty data block 204, until all the empty data blocks have been retrieved from theserver computer 112. Once no more empty data blocks 204 exist in the local copy of thevirtualized application package 114, the routine 400 ends. - It will be appreciated that the routine 400 described above could be used to generate local copies of other types of file packages, beyond the
virtualized application package 114 described above. For example, given askeleton file 300 of the appropriate structure and containing the appropriate header information and data block hashes, a local copy of a backup file created by a backup program could be recreated from the associated files in the file system. In another example, a local copy of an archive file, such as a ZIP file, could be recreated using the method described above. It is intended that this application include all such generations of a local copy of a file package from a corresponding skeleton file containing data block hashes and files from a file system. -
FIG. 5 shows an example computer architecture for acomputer 500 capable of executing the software components described herein for generating a local copy of a virtualized application package from a local installation, in the manner presented above. The computer architecture shown inFIG. 5 illustrates a conventional computing device, PDA, digital cellular phone, communication device, desktop computer, laptop, or server computer, and may be utilized to execute any aspects of the software components presented herein described as executing on the user computer 102,server computer 112, or other computing platform. - The computer architecture shown in
FIG. 5 includes a central processing unit (“CPU”) 502. TheCPU 502 may be a standard central processor that performs the arithmetic and logical operations necessary for the operation of thecomputer 500. TheCPU 502 performs the necessary operations by transitioning from one discrete, physical state to the next through the manipulation of switching elements that differentiate between and change these states. Switching elements may generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide an output state based on the logical combination of the states of one or more other switching elements, such as logic gates. These basic switching elements may be combined to create more complex logic circuits, including registers, adders-subtractors, arithmetic logic units, floating-point units, and other logic elements. Thecomputer 500 may include a multitude ofCPUs 502. - The computer architecture further includes a
system memory 508, including a random access memory (“RAM”) 514 and a read-only memory 516 (“ROM”), and asystem bus 504 that couples the memory to theCPU 502. A basic input/output system containing the basic routines that help to transfer information between elements within thecomputer 500, such as during startup, is stored in theROM 516. Thecomputer 500 also includes amass storage device 510 for storing anoperating system 518, application programs, and other program modules, which are described in greater detail herein. - The
mass storage device 510 is connected to theCPU 502 through a mass storage controller (not shown) connected to thebus 504. Themass storage device 510 provides non-volatile storage for thecomputer 500. Thecomputer 500 may store information on themass storage device 510 by transforming the physical state of the device to reflect the information being stored. The specific transformation of physical state may depend on various factors, in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the mass storage device, whether the mass storage device is characterized as primary or secondary storage, and the like. - For example, the
computer 500 may store information to themass storage device 510 by issuing instructions to the mass storage controller to alter the magnetic characteristics of a particular location within a magnetic disk drive, the reflective or refractive characteristics of a particular location in an optical storage device, or the electrical characteristics of a particular capacitor, transistor, or other discrete component in a solid-state storage device. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion. Thecomputer 500 may further read information from themass storage device 510 by detecting the physical states or characteristics of one or more particular locations within the mass storage device. - As mentioned briefly above, a number of program modules and data files may be stored in the
mass storage device 510 andRAM 514 of thecomputer 500, including anoperating system 518 suitable for controlling the operation of a computer. Themass storage device 510 andRAM 514 may also store one or more program modules. In particular, themass storage device 510 and theRAM 514 may store the applicationpackage generation module 124, which was described in detail above in regard toFIG. 1 . Themass storage device 510 and theRAM 514 may also store other types of program modules or data. - In addition to the
mass storage device 510 described above, thecomputer 500 may have access to other computer-readable media to store and retrieve information, such as program modules, data structures, or other data. By way of example, and not limitation, computer-readable media may include volatile and non-volatile, 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. For example, computer-readable media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks (DVD), HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by thecomputer 500. - The computer-readable storage medium may be encoded with computer-executable instructions that, when loaded into the
computer 500, may transform the computer system from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. The computer-executable instructions may be encoded on the computer-readable storage medium by altering the electrical, optical, magnetic, or other physical characteristics of particular locations within the media. These computer-executable instructions transform thecomputer 500 by specifying how theCPU 502 transitions between states, as described above. According to one embodiment, thecomputer 500 may have access to computer-readable storage media storing computer-executable instructions that, when executed by the computer system, perform the routine 400, described above in regard toFIGS. 4A and 4B . - According to various embodiments, the
computer 500 may operate in a networked environment using logical connections to remote computing devices and computer systems through anetwork 108. Thecomputer 500 may connect to thenetwork 108 through anetwork interface unit 506 connected to thebus 504. It should be appreciated that thenetwork interface unit 506 may also be utilized to connect to other types of networks and remote computer systems. Thecomputer 500 may also include an input/output controller 512 for receiving and processing input from a number of input devices, including a keyboard, a mouse, a touchpad, a touch screen, an electronic stylus, or other type of input device. Similarly, the input/output controller 512 may provide output to a display device, such as a computer monitor, a flat-panel display, a digital projector, a printer, a plotter, or other type of output device. - Based on the foregoing, it should be appreciated that technologies for generating a local copy of a virtualized application package from a local installation are provided herein. Although the subject matter presented herein has been described in language specific to computer structural features, methodological acts, and computer-readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features, acts, or media described herein. Rather, the specific features, acts, and mediums are disclosed as example forms of implementing the claims.
- The subject matter described above is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter described herein without following the example embodiments and applications illustrated and described, and without departing from the true spirit and scope of the present invention, which is set forth in the following claims.
Claims (20)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/471,476 US8533151B2 (en) | 2009-05-26 | 2009-05-26 | Generating a local copy of a virtualized application package from a local installation |
US14/019,594 US9081846B2 (en) | 2009-05-26 | 2013-09-06 | Generating a local copy of a virtualized application package from a local installation |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/471,476 US8533151B2 (en) | 2009-05-26 | 2009-05-26 | Generating a local copy of a virtualized application package from a local installation |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/019,594 Continuation US9081846B2 (en) | 2009-05-26 | 2013-09-06 | Generating a local copy of a virtualized application package from a local installation |
Publications (2)
Publication Number | Publication Date |
---|---|
US20100306270A1 true US20100306270A1 (en) | 2010-12-02 |
US8533151B2 US8533151B2 (en) | 2013-09-10 |
Family
ID=43221449
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/471,476 Active 2031-01-27 US8533151B2 (en) | 2009-05-26 | 2009-05-26 | Generating a local copy of a virtualized application package from a local installation |
US14/019,594 Active US9081846B2 (en) | 2009-05-26 | 2013-09-06 | Generating a local copy of a virtualized application package from a local installation |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/019,594 Active US9081846B2 (en) | 2009-05-26 | 2013-09-06 | Generating a local copy of a virtualized application package from a local installation |
Country Status (1)
Country | Link |
---|---|
US (2) | US8533151B2 (en) |
Cited By (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110179083A1 (en) * | 2010-01-15 | 2011-07-21 | Galloway Curtis C | Accessing Specialized Fileserver |
US20110219365A1 (en) * | 2010-03-05 | 2011-09-08 | Microsoft Corporation | High and low value application state |
US20120159479A1 (en) * | 2010-12-21 | 2012-06-21 | Microsoft Corporation | Providing a persona-based application experience |
US20120166597A1 (en) * | 2010-12-23 | 2012-06-28 | Microsoft Corporation | Satisfying application dependencies |
US20120227061A1 (en) * | 2011-03-03 | 2012-09-06 | Microsoft Corporation | Application compatibility with library operating systems |
US20140279936A1 (en) * | 2011-09-02 | 2014-09-18 | Compuverde Ab | Method for data retrieval from a distributed data storage system |
US20140351301A1 (en) * | 2011-12-15 | 2014-11-27 | Microsoft Corporation | Fast application streaming using on-demand staging |
US20150106440A1 (en) * | 2011-12-15 | 2015-04-16 | Microsoft Technology Licensing, Llc | Autonomous network streaming |
CN106257450A (en) * | 2015-06-19 | 2016-12-28 | 杭州海康威视数字技术股份有限公司 | The document alignment of group system, storage method and apparatus |
US20170083630A1 (en) * | 2015-09-21 | 2017-03-23 | Egemen Tas | Method to virtualize large files in a sandbox |
US9762701B1 (en) * | 2009-04-10 | 2017-09-12 | Open Invention Network Llc | System and method for cached streaming application isolation |
US9948716B2 (en) | 2010-04-23 | 2018-04-17 | Compuverde Ab | Distributed data storage |
US9965542B2 (en) | 2011-09-02 | 2018-05-08 | Compuverde Ab | Method for data maintenance |
US20180130092A1 (en) * | 2016-11-04 | 2018-05-10 | Google Inc. | Systems and methods for validating interaction with third-party interactive media |
US20180300325A1 (en) * | 2017-04-17 | 2018-10-18 | StorageOS Limited | System and method for managing volumes of data in a block storage system |
US10289435B2 (en) | 2011-05-16 | 2019-05-14 | Microsoft Technology Licensing, Llc | Instruction set emulation for guest operating systems |
US20190272178A1 (en) * | 2018-03-05 | 2019-09-05 | Beijing Zhanxinzhanli Information Technology Co., Ltd. | Application-level runtime environment for executing applications native to mobile devices without full installation |
US10568510B2 (en) * | 2015-05-12 | 2020-02-25 | Dexcom, Inc. | Distributed system architecture for continuous glucose monitoring |
US10650022B2 (en) | 2008-10-24 | 2020-05-12 | Compuverde Ab | Distributed data storage |
US10671370B2 (en) * | 2018-05-30 | 2020-06-02 | Red Hat, Inc. | Distributing file system states |
CN111462233A (en) * | 2020-03-20 | 2020-07-28 | 武汉理工大学 | Recovery data processing method and system for ship cab and storage medium |
CN111858675A (en) * | 2020-07-24 | 2020-10-30 | 北京玉符科技服务有限公司 | Custom property editor |
US10824716B2 (en) | 2009-05-11 | 2020-11-03 | Microsoft Technology Licensing, Llc | Executing native-code applications in a browser |
US11016785B2 (en) * | 2016-11-21 | 2021-05-25 | Zheng Yang | Method and system for mirror image package preparation and application operation |
US20220156052A1 (en) * | 2020-11-19 | 2022-05-19 | Foundation Of Soongsil University-Industry Cooperation | Software packaging device and method for performing binary analysis, and recording medium on which program for performing the same is recorded |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP2650799A1 (en) * | 2012-04-11 | 2013-10-16 | Bigpoint GmbH | Online game system and method |
US20140344538A1 (en) * | 2013-05-14 | 2014-11-20 | Netapp, Inc. | Systems, methods, and computer program products for determining block characteristics in a computer data storage system |
WO2015069162A1 (en) * | 2013-11-08 | 2015-05-14 | Telefonaktiebolaget L M Ericsson (Publ) | Method and device for the management of applications |
CN105653936A (en) * | 2014-11-12 | 2016-06-08 | 江苏威盾网络科技有限公司 | Desktop virtualization system and method based on web sandbox technology |
CN104715209B (en) * | 2015-04-03 | 2017-08-01 | 山东华软金盾软件股份有限公司 | A kind of outgoing document encryption protecting method |
CN108253977B (en) * | 2016-12-28 | 2020-11-24 | 沈阳美行科技有限公司 | Generation method and generation device of incremental data for updating navigation data |
Citations (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6154747A (en) * | 1998-08-26 | 2000-11-28 | Hunt; Rolf G. | Hash table implementation of an object repository |
US6389385B1 (en) * | 1999-07-02 | 2002-05-14 | International Business Machines Corporation | System and method for translating source code |
US20030145282A1 (en) * | 2001-10-31 | 2003-07-31 | Metacyber.Net | Computer-based method for parsing and hashing source information including a combined grammar |
US20040139309A1 (en) * | 2002-07-23 | 2004-07-15 | Twingo Systems | Method, system, apparatus and program product for temporary personalization of a computer terminal |
US20040250259A1 (en) * | 2003-06-04 | 2004-12-09 | Johannes Lauterbach | System and method for incremental object generation |
US7062567B2 (en) * | 2000-11-06 | 2006-06-13 | Endeavors Technology, Inc. | Intelligent network streaming and execution system for conventionally coded applications |
US7305671B2 (en) * | 2002-03-22 | 2007-12-04 | Sun Microsystems, Inc. | Conversion of an object model to a source file generation model |
US20080059631A1 (en) * | 2006-07-07 | 2008-03-06 | Voddler, Inc. | Push-Pull Based Content Delivery System |
US20080222219A1 (en) * | 2007-03-05 | 2008-09-11 | Appassure Software, Inc. | Method and apparatus for efficiently merging, storing and retrieving incremental data |
US7565495B2 (en) * | 2002-04-03 | 2009-07-21 | Symantec Corporation | Using disassociated images for computer and storage resource management |
US7574418B1 (en) * | 2004-02-13 | 2009-08-11 | Data Domain, Inc. | Method and apparatus for storing composite data streams |
US20100037235A1 (en) * | 2008-08-07 | 2010-02-11 | Code Systems Corporation | Method and system for virtualization of software applications |
US20100095380A1 (en) * | 2006-12-12 | 2010-04-15 | Fortinent, Inc. | Detection of undesired computer files in damaged archives |
US7735057B2 (en) * | 2003-05-16 | 2010-06-08 | Symantec Corporation | Method and apparatus for packaging and streaming installation software |
US7793266B2 (en) * | 2007-06-04 | 2010-09-07 | International Business Machines Corporation | Method, apparatus and computer program product for optimizing access to the content of a virtual application container on a fixed, read-only medium |
US20100235641A1 (en) * | 2006-09-12 | 2010-09-16 | Pando Networks, Inc. | Security techniques for cooperative file distribution |
US7890689B2 (en) * | 2003-12-08 | 2011-02-15 | The Board Of Trustees Of The Leland Stanford Junior University | Virtual appliance management |
US8112392B1 (en) * | 2009-02-13 | 2012-02-07 | Symantec Corporation | Methods and systems for creating snapshots of virtualized applications |
US8370835B2 (en) * | 2009-03-12 | 2013-02-05 | Arend Erich Dittmer | Method for dynamically generating a configuration for a virtual machine with a virtual hard disk in an external storage device |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6735601B1 (en) * | 2000-12-29 | 2004-05-11 | Vmware, Inc. | System and method for remote file access by computer |
US8261258B1 (en) * | 2005-10-28 | 2012-09-04 | Google Inc. | Common installer client |
US8606846B2 (en) * | 2007-10-15 | 2013-12-10 | Nbcuniversal Media, Llc | Accelerating peer-to-peer content distribution |
US8661428B2 (en) * | 2008-04-25 | 2014-02-25 | Vmware, Inc. | Updating a file using differences and file format therefor |
US8510271B1 (en) * | 2009-03-30 | 2013-08-13 | Symantec Corporation | Application and file system data virtualization from image backup |
-
2009
- 2009-05-26 US US12/471,476 patent/US8533151B2/en active Active
-
2013
- 2013-09-06 US US14/019,594 patent/US9081846B2/en active Active
Patent Citations (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6154747A (en) * | 1998-08-26 | 2000-11-28 | Hunt; Rolf G. | Hash table implementation of an object repository |
US6389385B1 (en) * | 1999-07-02 | 2002-05-14 | International Business Machines Corporation | System and method for translating source code |
US7062567B2 (en) * | 2000-11-06 | 2006-06-13 | Endeavors Technology, Inc. | Intelligent network streaming and execution system for conventionally coded applications |
US20030145282A1 (en) * | 2001-10-31 | 2003-07-31 | Metacyber.Net | Computer-based method for parsing and hashing source information including a combined grammar |
US20040199516A1 (en) * | 2001-10-31 | 2004-10-07 | Metacyber.Net | Source information adapter and method for use in generating a computer memory-resident hierarchical structure for original source information |
US7305671B2 (en) * | 2002-03-22 | 2007-12-04 | Sun Microsystems, Inc. | Conversion of an object model to a source file generation model |
US7565495B2 (en) * | 2002-04-03 | 2009-07-21 | Symantec Corporation | Using disassociated images for computer and storage resource management |
US20040139309A1 (en) * | 2002-07-23 | 2004-07-15 | Twingo Systems | Method, system, apparatus and program product for temporary personalization of a computer terminal |
US7735057B2 (en) * | 2003-05-16 | 2010-06-08 | Symantec Corporation | Method and apparatus for packaging and streaming installation software |
US20040250259A1 (en) * | 2003-06-04 | 2004-12-09 | Johannes Lauterbach | System and method for incremental object generation |
US7890689B2 (en) * | 2003-12-08 | 2011-02-15 | The Board Of Trustees Of The Leland Stanford Junior University | Virtual appliance management |
US7574418B1 (en) * | 2004-02-13 | 2009-08-11 | Data Domain, Inc. | Method and apparatus for storing composite data streams |
US20080059631A1 (en) * | 2006-07-07 | 2008-03-06 | Voddler, Inc. | Push-Pull Based Content Delivery System |
US20100235641A1 (en) * | 2006-09-12 | 2010-09-16 | Pando Networks, Inc. | Security techniques for cooperative file distribution |
US20100095380A1 (en) * | 2006-12-12 | 2010-04-15 | Fortinent, Inc. | Detection of undesired computer files in damaged archives |
US20080222219A1 (en) * | 2007-03-05 | 2008-09-11 | Appassure Software, Inc. | Method and apparatus for efficiently merging, storing and retrieving incremental data |
US7793266B2 (en) * | 2007-06-04 | 2010-09-07 | International Business Machines Corporation | Method, apparatus and computer program product for optimizing access to the content of a virtual application container on a fixed, read-only medium |
US20100037235A1 (en) * | 2008-08-07 | 2010-02-11 | Code Systems Corporation | Method and system for virtualization of software applications |
US8112392B1 (en) * | 2009-02-13 | 2012-02-07 | Symantec Corporation | Methods and systems for creating snapshots of virtualized applications |
US8370835B2 (en) * | 2009-03-12 | 2013-02-05 | Arend Erich Dittmer | Method for dynamically generating a configuration for a virtual machine with a virtual hard disk in an external storage device |
Cited By (51)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11907256B2 (en) | 2008-10-24 | 2024-02-20 | Pure Storage, Inc. | Query-based selection of storage nodes |
US10650022B2 (en) | 2008-10-24 | 2020-05-12 | Compuverde Ab | Distributed data storage |
US11468088B2 (en) | 2008-10-24 | 2022-10-11 | Pure Storage, Inc. | Selection of storage nodes for storage of data |
US9762701B1 (en) * | 2009-04-10 | 2017-09-12 | Open Invention Network Llc | System and method for cached streaming application isolation |
US10824716B2 (en) | 2009-05-11 | 2020-11-03 | Microsoft Technology Licensing, Llc | Executing native-code applications in a browser |
US10305910B2 (en) * | 2010-01-15 | 2019-05-28 | Apple Inc. | Accessing specialized fileserver |
US10091203B2 (en) | 2010-01-15 | 2018-10-02 | Apple Inc. | Specialized network fileserver |
US20110179083A1 (en) * | 2010-01-15 | 2011-07-21 | Galloway Curtis C | Accessing Specialized Fileserver |
WO2011109566A3 (en) * | 2010-03-05 | 2011-12-22 | Microsoft Corporation | High and low value application state |
US20110219365A1 (en) * | 2010-03-05 | 2011-09-08 | Microsoft Corporation | High and low value application state |
US9948716B2 (en) | 2010-04-23 | 2018-04-17 | Compuverde Ab | Distributed data storage |
US20120159479A1 (en) * | 2010-12-21 | 2012-06-21 | Microsoft Corporation | Providing a persona-based application experience |
US9116728B2 (en) * | 2010-12-21 | 2015-08-25 | Microsoft Technology Licensing, Llc | Providing a persona-based application experience |
US10165079B2 (en) | 2010-12-21 | 2018-12-25 | Microsoft Technology Licensing, Llc | Providing a persona-based application experience |
US20120166597A1 (en) * | 2010-12-23 | 2012-06-28 | Microsoft Corporation | Satisfying application dependencies |
US9354852B2 (en) * | 2010-12-23 | 2016-05-31 | Microsoft Technology Licensing, Llc | Satisfying application dependencies |
US9977665B2 (en) | 2010-12-23 | 2018-05-22 | Microsoft Technology Licensing, Llc | Satisfying application dependencies |
KR101963912B1 (en) | 2011-03-03 | 2019-03-29 | 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 | Application compatibility with library operating systems |
US20120227061A1 (en) * | 2011-03-03 | 2012-09-06 | Microsoft Corporation | Application compatibility with library operating systems |
KR20140046402A (en) * | 2011-03-03 | 2014-04-18 | 마이크로소프트 코포레이션 | Application compatibility with library operating systems |
US9891939B2 (en) * | 2011-03-03 | 2018-02-13 | Microsoft Technology Licensing, Llc | Application compatibility with library operating systems |
US10289435B2 (en) | 2011-05-16 | 2019-05-14 | Microsoft Technology Licensing, Llc | Instruction set emulation for guest operating systems |
US20140279936A1 (en) * | 2011-09-02 | 2014-09-18 | Compuverde Ab | Method for data retrieval from a distributed data storage system |
US9965542B2 (en) | 2011-09-02 | 2018-05-08 | Compuverde Ab | Method for data maintenance |
US10579615B2 (en) * | 2011-09-02 | 2020-03-03 | Compuverde Ab | Method for data retrieval from a distributed data storage system |
US11372897B1 (en) | 2011-09-02 | 2022-06-28 | Pure Storage, Inc. | Writing of data to a storage system that implements a virtual file structure on an unstructured storage layer |
US10769177B1 (en) | 2011-09-02 | 2020-09-08 | Pure Storage, Inc. | Virtual file structure for data storage system |
US10430443B2 (en) | 2011-09-02 | 2019-10-01 | Compuverde Ab | Method for data maintenance |
US10909110B1 (en) | 2011-09-02 | 2021-02-02 | Pure Storage, Inc. | Data retrieval from a distributed data storage system |
US9870372B2 (en) * | 2011-12-15 | 2018-01-16 | Microsoft Technology Licensing, Llc | Fast application streaming using on-demand staging |
JP2015506044A (en) * | 2011-12-15 | 2015-02-26 | マイクロソフト コーポレーション | High-speed application streaming with on-demand staging |
US20150106440A1 (en) * | 2011-12-15 | 2015-04-16 | Microsoft Technology Licensing, Llc | Autonomous network streaming |
US20140351301A1 (en) * | 2011-12-15 | 2014-11-27 | Microsoft Corporation | Fast application streaming using on-demand staging |
US11212284B2 (en) | 2014-09-22 | 2021-12-28 | Comodo Security Solutions, Inc. | Method to virtualize large files in a sandbox |
US11756682B2 (en) | 2015-05-12 | 2023-09-12 | Dexcom, Inc. | Distributed system architecture for continuous glucose monitoring |
US10568510B2 (en) * | 2015-05-12 | 2020-02-25 | Dexcom, Inc. | Distributed system architecture for continuous glucose monitoring |
CN106257450A (en) * | 2015-06-19 | 2016-12-28 | 杭州海康威视数字技术股份有限公司 | The document alignment of group system, storage method and apparatus |
US20170083630A1 (en) * | 2015-09-21 | 2017-03-23 | Egemen Tas | Method to virtualize large files in a sandbox |
US20180130092A1 (en) * | 2016-11-04 | 2018-05-10 | Google Inc. | Systems and methods for validating interaction with third-party interactive media |
US11763343B2 (en) * | 2016-11-04 | 2023-09-19 | Google Llc | Systems and methods for validating interaction with third-party interactive media |
US11016785B2 (en) * | 2016-11-21 | 2021-05-25 | Zheng Yang | Method and system for mirror image package preparation and application operation |
US20180300325A1 (en) * | 2017-04-17 | 2018-10-18 | StorageOS Limited | System and method for managing volumes of data in a block storage system |
US10831385B2 (en) * | 2017-04-17 | 2020-11-10 | StorageOS Limited | System and method for managing volumes of data in a block storage system |
US11625253B2 (en) | 2018-03-05 | 2023-04-11 | Beijing Zhanxinzhanli Information Technology Co., Ltd. | Application-level runtime environment for executing applications native to mobile devices without full installation |
US11237843B2 (en) * | 2018-03-05 | 2022-02-01 | Beijing Zhanxinzhanli Information Technology Co., Ltd. | Application-level runtime environment for executing applications native to mobile devices without full installation |
CN110231941A (en) * | 2018-03-05 | 2019-09-13 | 北京展心展力信息科技有限公司 | Suitable for run mobile device native applications program without the application-level running environment installed completely |
US20190272178A1 (en) * | 2018-03-05 | 2019-09-05 | Beijing Zhanxinzhanli Information Technology Co., Ltd. | Application-level runtime environment for executing applications native to mobile devices without full installation |
US10671370B2 (en) * | 2018-05-30 | 2020-06-02 | Red Hat, Inc. | Distributing file system states |
CN111462233A (en) * | 2020-03-20 | 2020-07-28 | 武汉理工大学 | Recovery data processing method and system for ship cab and storage medium |
CN111858675A (en) * | 2020-07-24 | 2020-10-30 | 北京玉符科技服务有限公司 | Custom property editor |
US20220156052A1 (en) * | 2020-11-19 | 2022-05-19 | Foundation Of Soongsil University-Industry Cooperation | Software packaging device and method for performing binary analysis, and recording medium on which program for performing the same is recorded |
Also Published As
Publication number | Publication date |
---|---|
US20140007081A1 (en) | 2014-01-02 |
US8533151B2 (en) | 2013-09-10 |
US9081846B2 (en) | 2015-07-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9081846B2 (en) | Generating a local copy of a virtualized application package from a local installation | |
US9268783B1 (en) | Preferential selection of candidates for delta compression | |
US9262434B1 (en) | Preferential selection of candidates for delta compression | |
US9405764B1 (en) | Method for cleaning a delta storage system | |
US8701106B2 (en) | Hashing storage images of a virtual machine | |
US8972672B1 (en) | Method for cleaning a delta storage system | |
US9043555B1 (en) | Single instance buffer cache method and system | |
US9436614B2 (en) | Application-directed memory de-duplication | |
US20120089579A1 (en) | Compression pipeline for storing data in a storage cloud | |
US20120089775A1 (en) | Method and apparatus for selecting references to use in data compression | |
CN114008592A (en) | Container management system with layout manager system | |
US9400610B1 (en) | Method for cleaning a delta storage system | |
JP5886447B2 (en) | Location independent files | |
US9026740B1 (en) | Prefetch data needed in the near future for delta compression | |
US9946724B1 (en) | Scalable post-process deduplication | |
US10929176B2 (en) | Method of efficiently migrating data from one tier to another with suspend and resume capability | |
US20190155798A1 (en) | Cache management | |
US11520759B2 (en) | Processing time series metrics data | |
US10185573B2 (en) | Caching based operating system installation | |
US9116902B1 (en) | Preferential selection of candidates for delta compression | |
WO2010097848A1 (en) | Storage system | |
JP2009282604A (en) | Duplicated data exclusion system, duplicated data exclusion method, and duplicated data exclusion program | |
US11586493B2 (en) | Efficient checksum computation | |
Tchaye-Kondi et al. | Hadoop Perfect File: A fast access container for small files with direct in disc metadata access | |
US11132401B1 (en) | Distributed hash table based logging service |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: MICROSOFT CORPORATION, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MCDIARMID, TREVOR WILLIAM;BRAR, GURASHISH SINGH;REEL/FRAME:023006/0761 Effective date: 20090522 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034564/0001 Effective date: 20141014 |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 8 |