Abstract:
A system and method for streaming an install package into a virtual environment. The system includes a server and a client. The server streams an install package to the client as a series of streamlets. The client starts an installer component in a suspended state outside the virtual environment. The client registers the installer component in the virtual environment and initiates execution of the installer component in the virtual environment to receive portions of the install package and install the received portions of the install package in the virtual environment. During package installation, a virtualization manager detects an attempt to execute a call to a file system and confines file system changes resulting from the call to the virtual environment in response to determining that the attempt was made by the installer component and the installer component is registered in the virtual environment.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    1. Field of the Invention 
         [0002]    This invention generally relates to installing files in a computing system. More particularly, the invention relates to a system and method for streaming an install package into a virtual environment. 
         [0003]    2. Description of the Related Art 
         [0004]    A common method of installing software in computing systems is via an installation package containing installation information and, often, the files that make up the software itself. For example, in computing systems running the Microsoft Windows® operating system, an install package commonly referred to as an MSI install package may be used. The term “MSI” comes from the default file extension of these installation packages. Install packages may be commonly delivered via removable storage media or via network download. 
         [0005]    In some cases, an install package may also be delivered to a target system via streaming. “Streaming” in this context generally refers to a form of on-demand software distribution in which an application is downloaded from a server, or other host, to a target in response to a request (demand) from the target. Such a software application may be referred to as a “streamed application.” Such techniques may include initially streaming only those portions of an application necessary to install and begin execution of the application with basic or otherwise required functionality. In this manner, the entire application need not be downloaded to a target computing system prior to beginning execution of the application. If other portions of the application are needed, they may be delivered in the background or on demand through the same streaming mechanism. For example, the server computer may first stream one or more startup blocks which include just enough executable code for the streamed application to be launched on the host computer. Upon receiving the startup blocks, the host computer may execute the startup blocks to launch the streamed application. Further blocks of code or data for the streamed application may then be dynamically streamed to the host computer from the server computer while the streamed application is executing. 
         [0006]    In some cases, an install package may be conveyed to a target computing system. Once the install package is received, one or more installation components may be employed to install the install package. For example, the Windows Installer Service and an MSI executable process may generally operate in the environment of the physical operating system of the target computing system according to standard Microsoft recommended practices. However, there may be times when it is desired to install an install package in a virtual environment on a target computing system. Accordingly, systems and methods of streaming an install package into a virtual environment are desired. 
       SUMMARY OF THE INVENTION 
       [0007]    Various embodiments of a system and method for streaming an install package into a virtual environment are contemplated. 
         [0008]    According to some embodiments, a system may include a server and a client. The client starts an installer component in a suspended state outside the virtual environment. For example, various operating systems provide utilities for suspending threads and/or processes. Such mechanisms may be utilized to either begin execution and immediately suspend processes and/or threads. Alternatively, it may be possible to start a process in a suspended state. Either way may be referred to as starting the installer component in a suspended state. Subsequently, the client registers the installer component in the virtual environment and initiates or resumes execution of the installer component in the virtual environment to begin installation of the package into the virtual environment. During installation of the received portion, a virtualization manager detects an attempt to execute a call to a file system. In response to determining that the attempt was made by the installer component and the installer component is registered in the virtual environment, the virtualization manager confines any file system changes that result from execution of the call to the virtual environment. 
         [0009]    In one embodiment, the installer component includes an installer service and an installer executable process. The client starts the executable process outside the virtual environment in a suspended state and subsequent to registering the installer executable process in the virtual environment, changes the state from suspended to active. Subsequent to installing the received portion of the install package in the virtual environment the client unregisters the installer service from the virtual environment and registers the installer service in a different environment. In a further embodiment, the client receives instructions from the server that identify a virtual environment into which to install the install package. In a still further embodiment, the server streams the install package to the client as a series of streamlets. The installer component extracts a file from a streamlet and issues a write request to write the file into the virtual environment. A driver, which may be outside of the virtual environment, intercepts the write request. In response to intercepting the write request, the driver determines if the file is a “sparse” file which does not include all of the file&#39;s data. If the file is a sparse file, the driver registers the file as a sparse file and allocates an amount of storage space sufficient to store the corresponding non-sparse file. In various embodiments, a sparse file includes a marker that includes data identifying a location from which data or code may be retrieved and in response to detecting a read request to read a sparse file, the driver conveys a demand/request to the location identified in the marker for the additional code or data and stores the retrieved code or data to the file. Embodiments are contemplated in which the driver is located on either the client or the server. 
         [0010]    Also contemplated is a method of streaming an install package into a virtual environment which includes starting an installer component in a suspended state outside the virtual environment. Subsequent to starting the installer component, the method further includes registering the installer component in the virtual environment and initiating execution of the installer component in the virtual environment to receive at least a portion of an install package and install the received portion of the install package in the virtual environment. During installation of the received portion, the method further includes detecting an attempt to execute a call to a file system. The method further includes confining file system changes resulting from execution of the call to the virtual environment in response to determining that the attempt was made by the installer component and the installer component is registered in the virtual environment. 
         [0011]    In a still further embodiment, a computer-accessible storage medium stores first program instructions executable by a client computing system to start an installer component in a suspended state outside the virtual environment. Subsequent to starting the installer component, the first program instructions are further executable by a client computing system to register the installer component in the virtual environment and initiate execution of the installer component in the virtual environment to receive at least a portion of an install package and install the received portion of the install package in the virtual environment. During installation of the received portion, the first program instructions are further executable to detect an attempt to execute a call to a file system. The first program instructions are further executable to confine file system changes resulting from execution of the call to the virtual environment in response to determining that the attempt was made by the installer component and the installer component is registered in the virtual environment. 
         [0012]    These and other embodiments will become apparent upon consideration of the following description and accompanying drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0013]      FIG. 1  illustrates one embodiment of a computing system for streaming an install package into a virtual environment. 
           [0014]      FIG. 2  illustrates one embodiment of a server computing system. 
           [0015]      FIG. 3  is a block diagram of one embodiment of a client computing system that may receive a streamed install package. 
           [0016]      FIG. 4  is a detailed block diagram of one embodiment of components used to install a streamed install package. 
           [0017]      FIG. 5  illustrates one embodiment of installed files after extraction and installation. 
           [0018]      FIG. 6  illustrates one embodiment of a process that may be used to install an install package. 
           [0019]      FIG. 7  illustrates one embodiment of a process that may be used to extract and install files from a streamlet source into a target environment. 
           [0020]      FIG. 8  illustrates one embodiment of a process that may be used to add code or data to sparse files. 
           [0021]      FIG. 9  illustrates one embodiment of a process that may be used to confine the effects of a process to a virtual environment. 
       
    
    
       [0022]    While the invention is susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the invention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims. 
       DETAILED DESCRIPTION 
       [0023]    Various embodiments of a system and method for streaming an install package into a virtual environment are described herein.  FIG. 1  illustrates one embodiment of such a system. In the embodiment shown, the system includes client computing systems  110 A- 110 E and server computing systems  120 A and  120 B. As used herein, elements referred to by a reference numeral followed by a letter may be collectively referred to by the numeral alone. For example, client computing systems  110 A- 110 E may be collectively referred to as client computing systems  110 . Server computing system  120 A is coupled to storage device(s)  125  and server computing system  120 B is coupled to storage device(s)  126 . Client computing systems  110  and server computing systems  120  may be interconnected through various network elements. For example, client computing systems  110 A and  110 B are shown coupled to server computing system  120 A via a local area network  17 , client computing systems  110 C,  110 D, and  110 E are shown coupled to server computing system  120 A via a virtual private network  18  and to server computing system  120 B via Internet  19 . In this embodiment, client computing systems  110 C- 110 E may be mobile and/or remote computing systems. In various embodiments the system may include any number and any type of client computing systems  110  and/or server computing systems  120 . Client computing systems  110  are representative of any number of stationary computers and/or mobile computing devices such as laptops, handheld computers, television set top boxes, home media centers, telephones, etc. Client computing systems  110  and server computing systems  120  may operate as peers in a peer-to-peer configuration, as clients and servers in a client/server configuration, or a combination or peer-to-peer and client/server configurations. Each client computer  110  may, for example, be used by a particular user or member of a business or other organization, a home user(s), or otherwise. 
         [0024]    In alternative embodiments, the number and type of computing systems and network elements is not limited to those shown in  FIG. 1 . Almost any number and combination of server, desktop, and mobile computing systems or devices may be interconnected in system  100  via various combinations of modem banks, direct LAN connections, wireless connections, WAN links, etc. Also, at various times one or more computing systems may operate offline. In addition, during operation, individual computing system connection types may change as mobile users travel from place to place connecting, disconnecting, and reconnecting to system  100 . In one embodiment, computing system  100  or a portion thereof may be implemented as part of a cloud computing environment. 
         [0025]    In one embodiment, server computing systems  120  may store one or more software applications on storage devices  125 ,  126 , etc. During operation, each of the client computing systems  110  may obtain, install, and execute one or more of these software applications via server computing systems  120 . For example, software applications obtained by client computing systems  110  may include e-mail, word processing, spreadsheet, and other office productivity applications, specialized applications for handling graphics, images, audio files, video files, performing numeric calculations and the like. Numerous other software applications are known and are contemplated. 
         [0026]    In one embodiment, software applications may be conveyed from a server computing system  120  to a host computing system  110  via streaming.  FIG. 2  illustrates one embodiment of a server computing system  120 A. It is noted that  FIG. 2  is provided as an example for purposes of discussion, and in other embodiments the server computing system  120 A may take on various other forms. Server computing system  120 A may be representative of any of server computing systems  120  described herein. Similarly, server computing system  120 A may be used to implement any of the below-described methods. Server computing system  120 A may be any of various types of devices, including, but not limited to, a personal computing system, desktop computer, laptop or notebook computer, mainframe computing system, handheld computer, workstation, network computer, a consumer device, application server, storage device, a peripheral device such as a switch, modem, router, etc, or in general any type of computing device. 
         [0027]    Server computing system  120 A may include one or more processors  250 , each of which may include one or more cores, any of which may be single or multi-threaded. Server computing system  120 A may also include one or more persistent storage devices  240  (e.g. optical storage, magnetic storage, hard drive, tape drive, solid state memory, etc), which may include various data items  242  (e.g., files) and/or applications  244 . Example applications include databases, email applications, office productivity applications, and a variety of others as known in the art. Server computing system  120 A may include one or more memories  210  (e.g., one or more of cache, SRAM, DRAM, RDRAM, EDO RAM, DDR 10 RAM, SDRAM, Rambus RAM, EEPROM, etc.). Server computing system  120 A may also include one or more network interfaces  260  for transmitting and receiving data, such as to or from client computing systems  110 , as described herein. Server computing system  120 A may further include one or more user interfaces  270  for receiving user input or displaying output to users, such as a keyboard, mouse or other pointing device, touch screen, and a monitor or other visual display device. Various embodiments may include fewer or additional components not illustrated in  FIG. 2  (e.g., video cards, audio cards, additional network interfaces, peripheral devices, a network interface such as an ATM interface, an Ethernet interface, a Frame Relay interface, etc.). 
         [0028]    One or more of the system memories  210  may contain program instructions  220 . Program instructions  220  may be encoded in platform native binary, any interpreted language such as Java® byte-code, or in any other language such as C/C++, Java®, etc or in any combination thereof. According to the illustrated embodiment, program instructions  220  may comprise specific modules executable to implement one or more operating systems  224 , such as the Windows® operating system, the Solaris® operating system, and/or the Linux® operating system. In addition, program instructions  220  may include modules to implement one or more of a filter driver  221 , an application manager  222 , a virtualization manager  223 , a streaming server  225 , a launch server  226 , and streamlet engine  227 . One or more of the system memories  210  may also contain application files  228 . Program code included in program instructions  220  can be combined together or separated into various modules as desired, according to a particular embodiment. Similar to server  120 A, clients may include any of a variety of storage types, interfaces, types of program code, and so on. 
         [0029]    During operation, launch server  226  may be used to view applications that are available to be streamed and to select an application to be streamed to a client computing system (e.g., client computing system  110  of  FIG. 1 ). An application that is chosen for streaming may be converted to a series of streamlets  280  by streamlet engine  227 . Streamlets, as used herein, are blocks into which an application is divided such that blocks of program code and/or data that are needed to run the application are transmitted first, thereby allowing the application to be launched with reduced latency. In one embodiment, streamlets may be 4 Kbyte blocks. Once streamlet engine  227  has generated streamlets  280 , they may be delivered to client computing system  110  by streaming server  225 . In one embodiment, streamlet engine  227  may convey streamlets to a client computing system irrespective of an environment in the client computing system targeted for installation of the streamlets. In various embodiments, streamlet engine  227  may add a tag to each streamlet that identifies a particular environment in the client computing system into which the software application corresponding to the streamlet is to be installed. 
         [0030]    Various types of software applications may be converted to streamlets by streamlet engine  227 . In one embodiment, software applications that have first been converted to install packages prior to conversion to streamlets may be streamed to a client. An install package, as used herein, refers to a set of files that have been organized into a package that may be received and processed by an installation component. For example, the Windows® Installer Service is a well known service that may be used to install, maintain, and remove MSI install packaged software applications—typically on a system that uses a Microsoft Windows operating system. An install package may include files corresponding to one or more software products. 
         [0031]    In one embodiment, the functions of application manager  222 , virtualization manager  223 , and filter driver  221  may be replaced by a corresponding application manager, virtualization manager, and filter driver located on a client computing system that perform functions that are described in detail below (e.g., application manager  322 , virtualization manager  323 , and filter driver  321  in  FIG. 3 ). In an alternative embodiment, the functions of client-side versions of application manager  322 , virtualization manager  323 , and filter driver  321  may be performed on the server by application manager  222 , virtualization manager  223 , and filter driver  221 . Various combinations of where such components are located are possible and are contemplated. 
         [0032]    Turning now to  FIG. 3 , a block diagram of one embodiment of a client computing system  110 A that may receive a streamed install package is shown. It is noted that  FIG. 3  is provided as an example, and in other embodiments the client computing system  110 A may take on various other forms. Client computing system  110 A may be representative of any of client computing systems  110  described herein. Similarly, client computing system  110 A may be used to implement any of the below-described methods. Client computing system  110 A may be any of various types of devices, including, but not limited to, a personal computing system, desktop computer, laptop or notebook computer, mainframe computing system, handheld computer, workstation, network computer, a consumer device, application server, storage device, a peripheral device such as a switch, modem, router, etc, or in general any type of computing device. 
         [0033]    During operation, in one embodiment, application manager  322  may generate a request to receive a streamed install package corresponding to a software application that is to be installed on a client computing system. In response to a request, application manager  322  may receive streamlets  280  that correspond to the requested package. In some embodiments, Application manager  322  may temporarily store each received streamlet in a local buffer or memory (not shown). If the requested software application is targeted to be installed in system (non-virtual) environment  410 , application manager  322  may cause Installer Component  325  to install the install package into system environment  410 . For example, Windows Installer Service, an installation and configuration service provided by Microsoft Windows, may be used to install MSI install packages. In other embodiments, an alternative service may be utilized to perform installation and configuration services. In one embodiment, installer component  325  includes an installer service that performs a series of actions specified by sequence tables in an installation database. These actions may generate a script that provides instructions for performing the installation. The installer service may then send the generated script for execution to another component of installer component  325  that uses the generated script to perform installation operations. For example, Windows Installer Service and MSI Executable may perform the functions of installer component  325 . 
         [0034]      FIG. 4  is a detailed block diagram of one embodiment of components used to install a streamed install package. Components illustrated in  FIG. 4  may operate on client system  110 A as shown in  FIG. 3 . Included in the components of  FIG. 4  are operating system  324 , a system environment  410 , and virtual environment  326 . In this embodiment, system environment  410  includes filter driver  321 , application manager  322 , and virtualization manager  323 . In this embodiment, virtual environment  326  includes installed file(s)  430 , Installer Service  440 , Installer Executable  450 , and a process table  420 . In some embodiments, the functions of Service  440  and Executable  450  may be combined in a single, or more than two, components. Windows-specific components may be used for purposes of discussion herein. In alternative embodiments, other install packages and installer components may be used instead. 
         [0035]    Application manager  322  is shown coupled to request a streamed application and receive streamlets  280  from a suitable source of streamed applications, such as a server computing system  120 . Application manager  322  may be further coupled to virtualization manager  323  and to filter driver  321 . Application manager  322  may also be coupled to Executable  450  for delivering streamed application files for installation. Virtualization manager  323  is shown coupled to a process table  420  that may be used to register and maintain a record of processes configured to operate within virtual environment  326 . Virtualization manager  323  is further shown coupled to Installer Service  440  and Executable  450  for managing their registration status. Filter driver  321  is shown coupled to installed file(s)  430  and may be used to manage writing and reading installed file(s)  430  within virtual environment  326 . Installer Service  440  and Executable  450  may each be coupled to installed file(s)  430  on which to perform install and uninstall operations. In one embodiment, Installer Service  440  and Executable  450  may be elements of an installer component  460 . 
         [0036]    During operation, if the requested software application is targeted to be installed in a virtual environment, such as virtual environment  326 , it may be desirable to prevent Installer Service  440  and Executable  450  from affecting the configuration of system environment  410  or operating system  324 . For example, Installer Service  440  may be provided by operating system  324  as a service that may be configured to run in system environment  410  or in a virtual environment such as virtual environment  410 . Various actions performed by Installer Service  440  including file system writes and changes to the operating system registry may have an effect on the environment in which Installer Service  440  is running. A scenario will now be described including additional steps to confine the effects of Installer Service  440  and Executable  450  to a particular virtual environment. 
         [0037]    In one embodiment, Installer Service  440  may be a process that is initially running outside of the virtual environment  326  (e.g., in the system environment  410 ) that makes a call to start Executable  450  to be used in an install operation. If the requested software application is targeted to be installed in a virtual environment, such as virtual environment  326 , virtualization manager  323  may change the operating environment of Installer Service  440  and/or Executable  450  from the system environment  410  to the virtual environment. In one embodiment, changing the operating environment of Service  440  and/or Executable  450  may comprise registering them in the virtual environment  326 . Registering Installer Service  440  and Executable  450  in a virtual environment may allow virtualization manager  323  to isolate the effects of actions performed by Installer Service  440  and Executable  450  to the target virtual environment, as described further below. In this manner, one or more changes to the virtual environment  326  may not affect the system environment  410 . 
         [0038]    In one embodiment, a target environment (e.g., a virtual or non-virtual environment) in which to install a software application may be determined on the client computing system, such as via a user selection. In an alternative embodiment, in order to identify a target environment in which to install a software application, application manager  322  may request and receive a set of rules from server computing system  120  that indicate, among other things, whether or not to install a software application into a particular environment. 
         [0039]    In one embodiment, virtualization manager  323  may manage processes that are registered in virtual environment  326 . For example, virtualization manager  323  may maintain a list of processes that have been registered in virtual environment  326  within a process table  420 . In the embodiment shown, process table  420  is shown within virtual environment  326 . However, in other embodiments, process table  410  may be located elsewhere. Once each of Installer Service  440  and Executable  450  has been registered in virtual environment  326 , a corresponding entry may be added to process table  420 . Virtualization manager  323  may be configured to monitor the operation of any of the processes operating on a client system such as client system  110 A. In one embodiment, if virtualization manager  323  detects a process call that corresponds to the virtualization environment  326 , the virtualization manager may cause the effects of the process to be maintained within the virtual environment  326 . Alternatively, if virtualization manager  323  detects a process call that corresponds to the system environment  410 , the virtualization manager  323  may permit the effects of the process to affect the system environment. 
         [0040]    In one embodiment, process table  420  may associate an indication with each process that indicates whether it is associated with a virtual environment  326  or other environment. In some embodiments, process table  420  may store only those processes registered with the virtual environment  326 . In such embodiments, the mere presence of a process identifier within the process table  420  indicates it is associated with the virtual environment  326 . For example, when a process makes a call to perform an operation such as a read or write to the file system, or seeks to make system or configuration changes (e.g., to the Windows registry), virtualization manager  323  may compare a process ID included in the call to process IDs stored in process table  420 . In various embodiments, if the process making the call or its parent process has a corresponding process ID in process table  420 , virtualization manager  323  may direct the call&#39;s operation to interact with the virtual environment only. Otherwise, if the process making the call or its parent process has a corresponding process ID in process table  420 , virtualization manager  323  may allow the call&#39;s operation to interact with the system environment. Accordingly, the effects of actions such as read and write requests to a file system or to the Windows registry by processes and their child processes that are registered in a virtual environment may be confined to the virtual environment. 
         [0041]    In one embodiment, before Executable  450  is registered in virtual environment  326 , it may be started in a suspended state as a process in the system environment. After Executable  450  has been registered, it may be triggered to begin execution. Subsequently, Installer Service  440  and Executable  450  may retrieve streamlets corresponding to the install package that have been received and extract one or more files to be written into virtual environment  326 . 
         [0042]    As files are being extracted from the streamlets, filter driver  321  may monitor writes performed by Executable  450 . If filter driver  321  detects an attempt by Executable  450  to write a file to virtual environment  326 , it may intercept the write, determine if the file includes a marker or other indication that indicates not all of the file data is present (e.g., the file is a “stub file” or “sparse file” that stands in for the actual file). If a file includes a marker, filter driver  321  may allocate or reserve additional space for the file to allow for additional data or code to replace the marker in the file&#39;s storage location if and when the file is received. In one embodiment, filter driver  321  may also register the file as a sparse file, such as by maintaining and adding an entry including a file identifier to a table of sparse files. Alternatively, the stored sparse file itself may indicate the file data is not present. As used herein, reference to a file with a marker as described above may refer to any suitable type of stub file or sparse file. Those skilled in the art will appreciate there are many ways a file may be identified as such stub/sparse file. The effect of this transformation of sparse files is illustrated in  FIG. 5 , which is described further below. If a read is subsequently addressed to a sparse file, file driver  321  may initiate a request to retrieve the data corresponding to the file from a streaming server (or other location) via application manager  322 . The retrieved data may then be used to service the read request—either before of after the retrieved data is written to a file system of the virtual environment. In one embodiment, a sparse file&#39;s marker may include data indicating the location from which further data corresponding to the file may be obtained, such as the location of a streaming server. For example, the marker may include an IP address and/or other address information. In such an embodiment, filter driver  321  may retrieve the file data from the location indicated in the marker of the file to which the read is addressed. 
         [0043]    Installer Service  440  and Executable  450  may continue to retrieve streamlets and install corresponding files into virtual environment  326  until all files, or enough files (e.g., a predetermined selection), have been installed to execute the corresponding software application. However, as long as Installer Service  440  is registered in virtual environment  326 , if a user or process attempts to use Installer Service  440  to perform an installation in another virtual or non-virtual environment, the effects of Installer Service  440  may be seen in virtual environment  326 , causing the effects to “leak” across environment boundaries. In one embodiment, to prevent such leaking across environment boundaries upon completion of an installation of an install package, Installer Service  440  and/or Executable  450  may be unregistered from virtual environment  326 . Unregistering Installer Service  440  and Executable  450  from virtual environment  326 , for example, by removing their corresponding process IDs from process table  420 , may allow them to be registered in another environment and used to install other installation packages into other target environments, either virtual or non-virtual. 
         [0044]      FIG. 5  illustrates one embodiment of installed files  430  after extraction and installation. In the illustrated embodiment, installed files  430  include files  510 ,  520 ,  530 , and  540 , etc. that represent any number of files that may be extracted from streamlets or otherwise made available to be installed in a target environment. In this embodiment, file  510  includes a header  511  and data  512 . Header  511  may include items such as a file ID and the size of the file. Data  512  is a variable length field containing the actual content of the file. Similarly, file  520  may include a header  521  and data  522 . However, some files, such as files  530  and  540 , may be sparse files that, in one embodiment, may include a header and a marker. For example, file  530  may include a header  531  and a marker  532 . Generally speaking, sparse files consume less storage space than the actual files they represent. However, as indicated in  FIG. 5 , more space has been allocated for file  530  than is needed to store header  531  and marker  532  to allow sparse file  530  and/or marker  532  to be replaced by additional file code or data without needing to increase the allocated storage space of file  530 . In one embodiment, marker  532  may include information identifying a location from which additional code or code data be obtained. File  540  may include a header  541  and a marker  542  that are used in a similar fashion to header  531  and marker  532 . 
         [0045]      FIG. 6  illustrates one embodiment of a process  600  that may be used to install an install package. Process  600  may begin with reception of a request to install a streamed install package (block  610 ). In response to the request, an install package may be retrieved from a streaming server (block  620 ). A target environment for installation of the install package may be identified (block  630 ). For example, a target environment in which to install a software application may be determined on a client computing system, such as via a user selection. In an alternative embodiment, in order to identify a target environment in which to install a software application, a request may be sent to a streaming server for target environment information. The streaming server may respond to the request by delivering a set of rules that indicate, among other things, whether or not to install a software application into a system environment, a virtual environment or into a particular virtual environment, etc. If the identified target environment is a system (non-virtual) environment (decision block  640 ), the install package may be written into the file system of the targeted system environment (block  642 ) and installed into the system environment using an installer component (block  644 ). For example, the install package may be received as a series of streamlets that are stored in the file system. Files may be extracted from the streamlets and installed in the system environment, completing the installation process. 
         [0046]    Alternatively, if the identified target environment is a virtual environment (decision block  640 ), the installer component may be started in a suspended state (block  660 ) and subsequently registered in the target virtual environment (block  665 ), such as by adding an entry that corresponds to the installer component to the process table. Once the installer component has been registered in the target virtual environment, execution of the installer component may begin (block  670 ). Streamlets may be received and stored in a file system region owned by the target virtual environment (block  680 ). Files may be extracted from the stored streamlets and installed into the target virtual environment (block  700 ). Once the files have been installed, the installer component may be unregistered from the target virtual environment (block  690 ), completing the installation process. 
         [0047]      FIG. 7  illustrates one embodiment of a process  700  that may be used to extract and install files from a streamlet source into a target environment. Process  700  may begin by triggering execution of an installer component in a target virtual environment (block  710 ). A streamlet may be received (block  720 ), such as from a streaming server via an application manager. A file may be extracted from the streamlet and a write request issued to write the extracted file to a storage region owned by the virtual environment (block  730 ). The write request may be intercepted by a file system driver (block  740 ). The file system driver may determine if the file is a sparse file (decision block  750 ). If the file is a sparse file, the file system driver may allocate additional space for the file to allow for replacement data to be placed in the file&#39;s storage location if and when the file is received and register the extracted file as a sparse file (block  760 ). After the file space has been allocated, or if the file is not a sparse file, the write request may be completed (block  770 ). It is noted that if a streamlet contains more than one file, blocks  730 ,  740 ,  750 ,  760 , and  770  may be repeated for each file. Once the write request has been completed, if additional files are needed to complete the installation (decision block  780 ), process  700  may continue at block  720 . If no additional files are needed, the installation process is complete. 
         [0048]      FIG. 8  illustrates one embodiment of a process  800  that may be used to add code or data to sparse files. Process  800  may begin with a file system driver monitoring a virtual environment for read requests (block  810 ). In response to detecting a read request (decision block  820 ), if the request does not target a file that is registered as a sparse file (decision block  830 ), the read request may be serviced (block  835 ) and process  800  may be repeated starting at block  810 . If the request targets a file that is registered as, or otherwise indicated to be, a sparse file (decision block  830 ), a request for a missing data of the sparse file data may be issued (block  840 ). For example, a request may be issued to an application manager to retrieve replacement data from a streaming server. In one embodiment, detecting that a file includes a marker may be sufficient to determine that the file is a sparse file. In addition, a marker may include information identifying the location from which replacement data may be obtained, such as the address of a streaming server. For example, streamed replacement data may be received (block  850 ), the received data may be stored into at least a portion of the storage location occupied by the sparse file, and the file un-registered as a sparse file. Additional, the read request may be serviced using the received data (block  860 ). In one embodiment, the replacement data may replace a marker, or any other portion, of the file. Further, the file may no longer be identified as a sparse file. Once the received data has been written, process  800  may be repeated starting at block  810 . 
         [0049]      FIG. 9  illustrates one embodiment of a process  900  that may be used to confine the effects of a process to a virtual environment. Process  900  may begin with creation of a process table in a selected virtual environment (block  910 ). Once a process table exists, a process ID may be added to the table for a selected process whose effects are to be confined to the selected virtual environment (block  920 ). All process calls to interact with a file system may then be monitored (block  930 ). When a call to perform a file system operation is detected (block  940 ), a process ID corresponding to the call may be identified (block  950 ) and the process table searched for a matching process ID (block  960 ). If a match is found in the process table (decision block  970 ), the call may be directed to interact with the selected virtual environment only (block  980 ) and monitoring may continue at block  930 . If a match is not found in the process table (decision block  970 ), the call may be permitted to interact with the system (non-virtual) environment (block  990 ) and monitoring may continue at block  930 . 
         [0050]    It is noted that the foregoing flow charts are for purposes of discussion only. In alternative embodiments, the elements depicted in the flow chart may occur in a different order, or in some cases concurrently. Additionally, some of the flow chart elements may not be present in various embodiments, or may be combined with other elements. All such alternatives are contemplated. 
         [0051]    It is noted that various embodiments may further include receiving, sending or storing instructions and/or data implemented in accordance with the foregoing description upon a computer-accessible storage medium. Generally speaking, a computer-accessible storage medium may include any storage media accessible by one or more computers (or processors) during use to provide instructions and/or data to the computer(s). For example, a computer-accessible storage medium may include storage media such as magnetic or optical media, e.g., one or more disks (fixed or removable), tape, CD-ROM, DVD-ROM, CD-R, CD-RW, DVD-R, DVD-RW, etc. Storage media may further include volatile or non-volatile memory media such as RAM (e.g. synchronous dynamic RAM (SDRAM), Rambus DRAM (RDRAM), static RAM (SRAM), etc.), ROM, Flash memory, non-volatile memory (e.g. Flash memory) accessible via a peripheral interface such as the Universal Serial Bus (USB) interface, etc. In some embodiments the computer(s) may access the storage media via a communication means such as a network and/or a wireless link. 
         [0052]    The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as may be suited to the particular use contemplated. It is intended that the following claims be interpreted to embrace all such variations and modifications.