Spoon Studio User Guide
Spoon Studio User Guide
2 Overview ............................................................................................................................8
6.9 Deploying virtual applications using Microsoft Terminal Services RemoteApp .... 65
7 Walkthroughs .................................................................................................................... 66
9.13 Applying the virtual application configuration to the host device ......................... 95
This product may contain technological defects and omissions, typographic errors, and technical
inaccuracies. Code Systems Corporation may modify this product at any time.
To the maximum extent permitted by applicable law, in no event shall Code Systems Corporation
be liable for any special, incidental, indirect, or consequential damages whatsoever (including, but
not limited to, damages for loss of profits or confidential or other information, for business
interruption, for personal injury, for loss of privacy, for failure to meet any duty including of good
faith or of reasonable care, for negligence, and for any other pecuniary or other loss whatsoever)
arising out of or in any way related to the use of or inability to use this product, the provision of or
failure to provide Support Services, or otherwise in connection with any aspect of this product,
even in the event of the fault, tort (including negligence), strict liability, breach of contract or
breach of warranty of Code Systems Corporation, and even if Code Systems Corporation has been
advised of the possibility of such damages.
Code Systems Corporation’s cumulative liability to you or any other party for any loss of damages
resulting from any claims, demands, or actions arising out of or relating to this product shall not
exceed the larger of the license fee paid to CODE SYSTEMS CORPORATION for the use of this
product and U.S. $5.00.
Microsoft, Windows, SQL Server, .NET, and .NET Framework are trademarks of Microsoft
Corporation.
This product will allow you to convert your Windows, .NET, Java, AIR, Flash, Shockwave, or
other Windows-compatible application into a self-contained virtual application that can be
streamed from the web and run instantly on an end-user device. Unlike traditional deployment
methods, virtual applications do not require reboots, administrative privileges, or separate setup
steps for external components and runtimes. Virtual applications are isolated from other system
applications, preventing DLL conflicts and other deployment nightmares.
This guide explains how to use Spoon Studio to create your own virtual applications and begin
enjoying the benefits of this next-generation deployment technology.
For example, a publisher of an application based on the Microsoft .NET Framework or Java
runtime engine might create a virtual application combining the application with the required
runtime engine. An end-user can run this application immediately, even if the user has not
installed the required runtime engine, or has an incompatible runtime engine installed. This
improves both the user experience and reduces test and support complexity associated with
deploying the application.
• Does not require any "player" software or separate installation: Spoon virtual
applications are executable files that run immediately on the end-user machine without
changes to system infrastructure.
• Does not incur significant processing or filesystem overhead: Spoon low-overhead
virtualization technology allows applications to run with essentially the same
performance characteristics as native executables.
• Does not require any operating system to be installed onto the virtual application: Spoon
virtual apps provide all required virtualized operating system functionality within the
internal virtual environment.
• Create virtual applications that can be streamed from the web: Eliminate long downloads
and installs, and run virtual apps from any desktop with broadband Internet access.
• Create an application as a single executable that runs immediately: Package all
application files, registry settings, runtimes, and components into a single executable that
runs immediately.
• Run Java and .NET without separate runtime installations: Java and/or .NET-based
applications run immediately, with no separate installation steps or runtime versioning
conflicts.
• Improve desktop security: Execute your applications without granting administrative
permissions to end-users. Stabilize desktop images by deploying applications in Spoon
sandboxed virtual environments.
• Eliminate third-party setup dependencies: Integrate third-party components, COM/VB
controls, and content viewers such as Acrobat, Flash, and Shockwave, directly into your
application.
• Eliminate Vista UAC prompts and compatibility errors: Deploy Spoon virtual apps
regardless of access to privileged system resources, relieving users of annoying Vista
UAC prompts.
• Leverage Terminal Services and Citrix investments: By isolating applications from global
resource areas, Spoon virtual application technology allows non-compliant
applications to function properly in Terminal Server and Citrix environments.
• Deploy instantly on USB drives: Improve mobile worker productivity by placing your
Spoon virtual application onto a USB flash-memory drive. Run your application
immediately on remote PCs, with no installation steps, administrative privileges or driver
installations.
• Dramatically reduce test and support costs: Eliminate versioning conflicts, dependencies,
and "DLL hell". Reduce test complexity and eliminate support requests associated with
dependency installation and inter-application resource conflicts.
Unlike hardware virtualization systems such as Microsoft Virtual PC and VMware, Spoon
virtualizes only those operating system features required for application execution. This allows
virtualized applications to operate extremely efficiently, with essentially the same performance
characteristics as native executables.
• Optimal performance: Spoon virtual apps execute at essentially the same speed as
applications running natively against the host hardware, with only a small additional
memory footprint. By contrast, applications running within hardware-virtualized
environments experience significant slowdowns and impose a large memory footprint
because the virtual machine must include an entire virtualized host operating system.
• Dramatically reduced application size: Spoon virtual apps require a disk footprint
proportional only to the size of the virtualized application, data, and included
components. As a result, Spoon virtual apps are typically small enough to be
conveniently and quickly downloaded by end-users. Hardware virtualization requires
an entire host operating system image, including many basic subsystems that are already
present on the end-user device. Each virtual machine may occupy several gigabytes of
storage.
• Ability to run multiple virtual applications: Because of low-overhead characteristics, it is
possible to run multiple simultaneous Spoon virtual environments per
processor. Conversely, due to the high overhead of hardware virtualization, only a very
small number of hardware-virtualized environments per processor can be run.
• Reduced licensing costs: Spoon does not require the purchase of separate operating
system licenses to use a virtual application. Hardware virtualization systems require a
host operating system in order function, possibly imposing additional licensing costs and
restrictions.
• Non-Windows operating systems: Spoon virtual apps run only on the Windows operating
system. Hardware virtualization can execute any operating system compatible with the
underlying virtualized hardware, such as Linux.
• Kernel mode virtualization: The Spoon Virtual OS only virtualizes user-mode operating
system features, whereas hardware virtualization systems emulate the entire OS stack,
including kernel mode components. Applications requiring device drivers or other non-
user-mode software may require a hardware-virtualized environment to function
properly.
You should carefully evaluate the advantages and disadvantages of different virtualization
approaches before deciding on a technology to adopt for your deployment scenario.
• Windows XP Professional
• Windows Embedded XP
• Windows 2000 Professional
• Windows 2000 Server
• Windows Server 2003, all editions
• Windows Vista, all editions
• Windows Server 2008, all editions
• Windows 7
Studio supports these operating systems running within VMware and Microsoft hardware
virtualization and hypervisor environments.
Studio also has limited support for the Windows Preinstallation Environment (WinPE), though
certain applications depending on operating system features unavailable in WinPE may not
function properly.
Studio creates 32- and 64-bit executables. Both 32-bit (under 32-bit mode) and 64-bit executables
can be run on x64-based platforms.
Spoon applications are compatible with most major anti-virus, runtime, and security packages
currently available.
• The Start menu button- located in the circle on the top left of the window- allows virtual
application configurations to be imported, opened, applied, saved, and closed.
• The Options bar provides Studio interface customization options, and the ability to
install license certificates
• The help bar provides access to the Studio documentation and knowledge base, including
a searchable version of this document.
• The Virtual Application tab provides access to the snapshot and build features, as well
as output configuration options such as the startup file, output directory, and diagnostic-
mode selection.
• The Runtimes tab provides a selection of auto-configurable runtime engines which can
be embedded into your application with a single click. These include .NET Framework,
Java, Flash, and Shockwave runtimes.
• The Advanced tab provides advanced Studio functions such as Profiling and Platform
Merge
Functions in the main panel are accessed by clicking the appropriate buttons along the left side of
the interface:
• The Start panel displays the latest Studio news, including updates, available licenses, and
usage suggestions.
• The Filesystem panel displays the application virtual filesystem, and allows adding and
removing virtual files and directories.
• The Registry panel displays the application virtual registry, and allows adding and
removing virtual registry keys and data values.
• The Settings panel allows configuration of virtual application metadata, startup image,
and process configuration options.
• The Components panel allows layering of external virtual application components, such
as toolbars and optional features.
• The Setup panel allows configuration of MSI setup package and shell integration
options.
• The Expiration panel allows configuration of application expiration options.
Note: Studio users are individually responsible for assuring compliance with licensing for any
third-party redistributable components included using virtualization.
• Use an application template: Studio includes templates for popular applications which
can be built and customized using a guided, step-by-step process. This method is
recommended for first-time users of Studio. (This method only applicable in certain
editions of Studio)
• Install via application snapshot: Snapshotting captures system state before and after an
application is installed and automatically configures virtual application settings based on
observed system changes. This method is ideal for virtualizing off-the-shelf applications
(Refer to the section “Snapshotting applications” for more information on this method).
• Manually configure an application: This method is most often used by developers
virtualizing internally developed applications. Manual configuration requires a high
degree of technical knowledge but allows the maximum amount of control over virtual
application settings (Refer to the sub-section “Manually configuring a simple virtual
application” in the “Walkthroughs” section for more information on this method).
All methods allow additional configuration and customization once the initial virtual application
configuration has been constructed.
For information on current available editions of Spoon Studio, visit the Studio section of
Spoon.net.
Studio includes automated virtual application configuration wizards for certain popular software
applications. Spoon recommends that first-time users begin by building one of these auto-
configurable virtual applications using the Studio Configuration Wizard.
• Open the Studio Configuration Wizard. The wizard is displayed on program startup, or
can be opened by pressing the Configuration Wizard button on the Virtual Application
ribbon bar.
• Click on the box labeled Build a virtual application from a template.
• Select an application to virtualize from the Application dropdown. Some applications
may require download of additional configuration information or source application
media.
• Follow the wizard steps to construct the virtual application.
After completing the wizard, the virtual application configuration will remain loaded in the Studio
interface. This allows the configuration settings generated by the wizard to be inspected and
additional customization to be performed (Refer to the following sections “Configuring virtual
applications” and “Customizing virtual applications” for more information on configuration and
customization).
3.6.1 Snapshotting
Snapshotting uses "before” and “after" images of the host machine to determine the virtual
application configuration:
• “Before” snapshot: Taken prior to installing the application. This captures the state of the
host device without the target application installed.
• “After” snapshot: Taken after installing the application. This captures all changes to the
host device during application installation. Studio then computes the changes, or deltas,
between the before and after snapshots, and inserts these changes into the configuration.
• Prepare the host device by either removing the target application and all dependencies, or
copying Studio onto a "clean" machine.
• Click on the Virtual Application tab on the ribbon bar and click Capture Before. This
captures the "before" snapshot image. Snapshotting iterates through the filesystem and
registry, and therefore may take several minutes to complete.
• (Optional) Spoon recommends you save the "before" snapshot before continuing. This
allows you to skip this step when snapshotting subsequent applications from the same
clean machine image. To save the snapshot, click on the down arrow underneath the
Capture Before button and select Save Snapshot. Note that while Studio automatically
saves the most recent captured "before" snapshot, this snapshot is reset once the Capture
and Diff process is complete.
• Install your application along with other files, settings, runtimes, and components you
wish to include in the virtual application (Refer to the following sub-section “Adding
runtimes and components” for more information on additional configuration). If the
application setup requests a reboot, be sure to save the "before" snapshot and then
proceed with the reboot.
• On the Virtual Application tab on the ribbon bar, click Capture and Diff. This
captures the "after" snapshot, computes the deltas between the two snapshots, and
populates the virtual application with the delta entries.
• (Optional) Review the filesystem and registry entries, and remove any files or settings
which are not required for proper execution of your virtual application. Removing unused
entries will reduce virtual application size, but be sure to avoid accidental removal of
required resources, as it will cause your virtual application to no longer function properly.
To save the "before" snapshot, click on the down arrow underneath the Capture Before button on
the Virtual Application ribbon bar and select Save Snapshot from the dropdown menu. Select
an appropriate filename and location and press Save. Similarly, to load a saved snapshot, select the
Load Snapshot menu item and navigate to the saved snapshot file. To clear the current "before"
snapshot image, select the Clear Snapshot menu item.
Additional runtimes and components should be added to the virtual application during the
snapshot process, before the “After” snapshot has been taken.
For example, if your application is a .NET Framework 4.0 application, then selecting the .NET
Framework 4.0 component will allow your executable to run on machines without the .NET
Framework installed.
Note: Depending on the size of the component, selecting a component for inclusion can
significantly increase the size of the resulting executable. Therefore, you should only select
components which are required for proper execution of your application.
Note: You are responsible for assuring compliance with licensing for any third-party
redistributable components included in your virtualized application.
Select the appropriate version of the Java runtime from the Java runtime version dropdown. If
you are deploying your application as a set of .class files, then select the Class option from the
Startup type dropdown; if you are deploying within a .jar file, select the Jar option. Enter
the startup class name or Jar name in the appropriate textbox, along with any additional Java
runtime options.
To save a configuration:
• Click on the Start button menu and select Save Configuration As...
• Select a filename and location and click Save. This saves the virtual application
configuration file. By default, configuration files use the extension .xappl.
Note: Configuration files do not store the contents of virtual filesystem files. The configuration
file specifies only the source path for each virtual filesystem entry. The source file must exist at
build time or the virtual application will not build successfully.
Studio automatically stores source file locations as paths relative to the location of the saved
XAPPL file, in the same directory as the XAPPL file (the folder marked Files).
Note: Studio users can create their own default settings for application building by saving a
XAPPL file with a few customization settings (E.g. changing the default sandbox location) and no
associated application, then loading this XAPPL file (and saving as a new file) before beginning
the snapshot process in a new project.
A startup file should be specified after the application has been installed and configured with
runtimes, and the “After” snapshot has been taken.
Files located on the host device (outside of the virtual filesystem) may also be used as startup
files. To select a file on the host device as the startup file, enter the full path to the desired startup
file in the Startup File text box. Remember to use well-known root folder variables such as
@WINDIR@ and @PROGRAMFILES@ as the root of the full path to ensure that the startup
file can be properly located on all base operating systems.
Note: While any file can be selected as the startup file, you should only select a file which is
executable or viewable. Selecting a file which cannot be opened will cause an error when the
virtual application is started.
Studio enables this scenario by allowing multiple entry points into the virtual application to be
triggered based on a command-line argument to the virtual application executable. For example,
in the office suite scenario described above, one might use the command line argument office
word to trigger the word processor and office spreadsheet to trigger the spreadsheet (Refer to the
sub-section “Building OpenOffice via snapshot process” in the “Walkthroughs” section for an
example of Jukeboxing during the OpenOffice build process).
• Click the Multiple button next to the Startup File textbox on the Virtual Application
ribbon bar. This displays the Startup Files selection dialog.
• Click on the File column on the first empty row in the startup file list and select the
desired file from the dropdown list. Files located on the host device (outside of the virtual
filesystem) may also be used as startup files. To select a file on the host device as the
startup file, enter the full path to the desired startup file in the Startup File text box.
• Enter the desired command line arguments, if any, in the Command Line column.
• Enter the desired command line trigger in the Trigger column. For example, in the
command line office word, the trigger would be word.
• Check the Auto Start checkbox if you want the startup file to always be automatically
launched on virtual application startup.
• After adding a new startup file, hit Enter in order to save
Note: When specifying a startup file located outside of the virtual filesystem, remember to use
well-known root folder variables such as @WINDIR@ and @PROGRAMFILES@ as the root
of the full path to ensure that the startup file can be properly located on all base operating systems.
Note: The Auto Start flag can be specified for multiple startup files to automatically launch
multiple applications that are typically used together in a single session (also known as
"shotgunning").
• Click on the Filesystem button located on the left side of the Studio window.
• Using the view on the right, add the files and folders you wish to embed in the
application executable. The Application Directory root folder represents the folder
containing the virtual application binary on the executing device; the other root folders
represent the corresponding folders on the host device.
Note: When running a virtual application on Windows 7, the All Users Directory\Application
Data and All Users Directory root folders will map to the same folder at runtime. Ensure that the
isolation settings for these folders are the same, preventing unpredictable behavior as one setting
will override another.
• Full mode: Only files in the virtual filesystem will be visible to the application- even if a
corresponding directory exists on the host device- and writes are redirected to the
sandbox data area. Full mode is generally used when a complete level of virtual
application isolation is desired.
• Merge mode: Files present in a virtual folder will be merged with files in the
corresponding directory on the host machine, if such a directory exists. Writes to host
files are passed through to the host device and writes to virtual files are redirected into the
sandbox data area. Merge mode is generally used when some level of interaction with the
host device is desired. For example, Merge mode might be used to allow the virtualized
application to write to the host device's My Documents folder.
• Write Copy mode: Files present on the host device are visible to the virtual environment,
but any modifications to folder contents are redirected to the sandbox data area. Write
Copy mode is generally used when a virtual application needs to read from files already
present on the host device but isolation of the host device is still desired.
• Hide mode: Files and folders with Hide isolation enabled will return a ‘File Not Found’
message to the application at runtime. This applies to both the virtual filesystem and the
Tip: To apply the selected isolation mode to all subfolders, right-click on the folder, choose
Isolation, click on the checkbox for Apply to subfolders, and click OK.
Note: The hidden flag should not be confused with Hide isolation mode. Enabling the hidden flag
only prevents a file or folder from being displayed in browse dialogs or from directory
enumeration APIs. It does not prevent the application, and therefore potentially the end-user, from
accessing the folder or file contents by direct binding. In order to prevent the file or folder from
being found by the application, Hide isolation mode should be enabled.
Flagging files and folders as read-only will prevent the application from modifying the file or
folder contents. To make a file or folder read-only, click on the checkbox in the Read Only
column next to the desired file or folder.
Note: Disabling payload compression may significantly increase the size of the virtual application
binary.
• Click on the Registry button located on the left side of the Studio window.
• Using the view on the right, add the registry keys and values you wish to embed in the
application executable. When adding blob data, enter the values in hexadecimal format.
The Classes root, Current user root, Local machine, and Users root folders correspond to the
HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, and
HKEY_USERS keys on the host machine.
Registry string values may include well-known root folder variables such as
@PROGRAMFILES@ and @WINDIR@.
• Full mode: Only values in the virtual registry will be visible to the application- even if a
corresponding key exists on the host device- and writes are redirected to the user registry
area.
• Merge mode: Values present in a virtual key will be merged with values in the
corresponding key on the host machine, if such a key exists. Writes to host keys are
passed through to the host registry and writes to virtual keys are redirected to the user
registry area.
• Hide mode: Keys and values in the virtual registry or the corresponding host registry will
not be found by the application at runtime.
Tip: To apply the selected isolation mode to all subkeys, right-click on the key, choose Isolation,
click on the checkbox for Apply to subkeys, and click OK.
Selecting a database engine displays the database configuration dialog. Selecting the Do not
embed SQL Server Express option disables this feature.
The virtualized SQL Server 2005 Express default instance name is stored in a special environment
variable named %SQLSPOON%. A unique instance of this name is created at build time and is
not user-configurable.
• Verify that the desired .mdf database file has been added to the virtual filesystem.
• Choose the .mdf database file to attach using the AttachDBFilename dropdown. This
path is stored in the %AttachDBFilename% environment variable.
To manually modify this selection at a later time, click the Environment Variables button on the
Process Configuration tab of the Settings pane.
Note: The .NET 2.0 Framework is automatically included when SQL Server Express 2005 engine
is selected. SQL Server 2005 Express requires this component to be installed. If this component is
removed, the application will only run on machines that have the .NET Framework 2.0 installed.
• Configure the virtual application settings exactly as in the case of a standard virtual
application (i.e. using snapshotting, manual configuration, etc.).
• On the Settings pane, select Component from the Project type dropdown.
• Press the Build button.
In Component mode, the build process results in creation of an SVM file instead of an executable
file. An SVM contains the virtual application settings and data payload. SVMs are similar to
virtual executable outputs, except that SVMs do not contain the Spoon virtual machine runtime
engine. Therefore, an SVM can only be used when combined as part of another virtual application.
Project virtualization settings take precedence over virtualization settings in any loaded shared
components.
To remove a shared virtual component from the project, select the component and click the
Remove Component button.
• Click the Sandbox Merge button in the Tools section of the Virtual Application
toolbar.
• Enter the path of the sandbox to be merged into the current configuration.
• Click OK.
For example, to customize the home page of the Firefox virtual application template:
• Use the Configuration Wizard to create a Firefox virtual application. (The wizard
allows customization of the home page, but we will later use the sandbox merge feature
to override the setting specified in the wizard.)
• Press Build and Run to launch the virtualized Firefox application.
• Using the Firefox interface, specify a new browser home page.
• Exit the Firefox virtual application.
• Press Sandbox Merge to display the sandbox merge dialog. The sandbox path will be
pre-populated with the location of the Firefox virtual sandbox.
• Click OK.
The virtual application settings are updated with the configuration changes made during Firefox
execution, including the updated browser home page.
Application: A virtual application project produces an executable file output (.exe file) that can be
run directly from the operating system. Application output mode is appropriate for most users and
is the default selection.
Component: A component project produces an SVM (.svm file). SVM is a Spoon file format
encoding all virtual application configuration and content into a single binary file. SVMs cannot
be executed directly from the operating system. SVMs are used to exchange virtual application
and component data between multiple virtual applications. For example, component output mode
is used to submit components into the Spoon Component Gallery.
Note: In order to create SVMs for use in streaming applications on Spoon Server, the project type
must be set to component.
To set the project type, press the Settings button and select the appropriate option from the
Project type dropdown.
To revert to the default inheritance behavior, recheck the Inherit properties option.
• Click the Custom Metadata... button. This displays the Custom Metadata dialog.
• Enter the custom metadata property names and values into the dialog. Only string-type
custom metadata values are supported.
For information on programmatically reading custom executable metadata, please consult the
Microsoft Windows Software Development Kit.
If you wish to remove the current startup image, click the Reset button.
• Click the Select... button next to the Transparency key label. This displays the
transparency key selection dialog.
• Select the color which represents transparent regions in the startup image and click OK.
For example:
Use the OnInitialize parameter field to specify parameters for your startup shim.
If you wish to remove the current startup shim, click the Reset button.
Note that these arguments override any arguments that might be specified by the end-user.
The Use startup file directory option sets the working directory to the directory of the virtual
application startup file. In the case of a jukeboxed application, the working directory is set to the
directory of the startup file specified on the jukebox command line.
The Use current directory option sets the working directory to the directory from which the
virtual application is launched.
The Use specified path option allows an explicit working directory to be specified. The working
directory specification can include environment and well-known root folder variables.
By default, the working directory is set to the directory of the startup file.
To override the application type, select the appropriate mode from the Application type
dropdown in the Process Configuration section of the Settings panel. The Inherit mode sets the
application type based on the type of the startup file, if possible.
x86: Use this option for applications that were snapshotted on x86 systems. This option maps the
Program Files directory to C:\Program Files on x86 systems or to C:\Program Files (x86) on
x64 systems. .NET applications always run as 32-bit applications.
x64: Use this option for applications that were snapshotted on x64 systems. This option maps the
Program Files directory to C:\Program Files on x64 systems. The Program Files (x86)
directory is mapped to C:\Program Files on x86 systems and C:\Program Files (x86) on x64
systems. .NET applications run as 32-bit applications on x86 systems and 64-bit applications on
x64 systems.
Any CPU: Use this option for .NET applications that are compiled to run on any CPU
architecture. This option maps the Program Files directory to C:\Program Files on x86 systems
and C:\Program Files on x64 systems. .NET applications run as 32-bit applications on x86
systems and 64-bit applications on x64 systems.
• Click the Environment Variables... button. This displays the Environment Variables
dialog.
• Enter environment variable names and values into the environment variable list.
Most virtual environment variables overwrite any environment variables defined in the host
environment. However, the special PATH and PATHEXT environment variables are always
merged with the corresponding host environment variables.
Environment variables are automatically captured and merged during the snapshotting delta
process. Therefore, it is generally unnecessary to manually configure environment variable
settings.
Studio fully supports virtualization of Windows services. To view or modify virtual service
settings, press the Virtual Services... button. This displays the Virtual Services dialog.
The Name field specifies the internal name of the virtual service. For example, the Windows web
server would use the name w3svc.
The Command Line field specifies the full command line (including the service executable name
and any parameters) used to launch the service.
The Auto Start flag indicates whether a virtual service automatically starts during virtual
application startup, or whether the service must be launched manually or by the virtualized service
control manager.
The Keep Alive flag indicates whether the virtual service process is automatically terminated
when the primary application executable terminates, or whether the service (and, therefore, the
host virtual application executable) continues to run until the service terminates itself.
Service installation and settings are automatically captured during the snapshotting
process. Therefore, it is generally unnecessary to manually configure virtual service settings. The
primary exception is the case of virtualized applications intended to run as background worker
services (for example, virtualized web servers); in this case, it is often required to explicitly enable
the Keep Alive option.
Child processes include processes spawned to service COM local server requests.
Note: Child processes created outside of the virtual application will not have access to virtualized
filesystem or registry contents. However, these processes will be able to access or modify host
operating system contents, even if this would otherwise be forbidden by the virtual application
configuration.
By default, child processes are created within the virtual application. To force child processes to
be created outside of the virtual application, uncheck the Spawn child process within virtualized
environment option. COM local servers can optionally be created within the virtual application
context. To force COM local servers to be created outside of the virtual application, uncheck the
Spawn COM servers with virtualized environment option.
Exceptions to the child process virtualization behavior specified by the Spawn child process
within virtualized environment and Spawn COM servers within virtualized environment
flags can be enumerated in the Child Process Exception List. Process names listed in the child
process exception list behave opposite to the master child process virtualization setting. To edit the
child process exception list, click the Child Process Exception List button. Process names may or
may not include the process filename extension.
To enable the automatic sandbox reset feature, check the Delete sandbox on application
shutdown option.
Note: By default, the startup file is the root process. However, if a virtual service is specified in
the application configuration file and is set to auto-start when the application is launched, the
virtual service acts as the root process in the process tree.
To build applications without compression, leave the Compress Payload option unchecked.
To disable processing of these arguments, uncheck the Enable Spoon command-line arguments
option.
When publishing a new version of a virtual application, direct the sandbox to the same location as
the older version if you want user settings and data to be retained in the new version. Direct the
sandbox to a different location (typically, by rolling the subdirectory version number forward) if
you want user settings and data to be reset.
If deploying the virtual application on a USB device, place the sandbox in a subfolder of the
@APPDIR@ directory, which represents the location of the virtual application executable. This
will have the effect of directing writes to the USB device. The recommended sandbox location for
USB deployment is:
@APPDIR@\Spoon\Sandbox\@TITLE@\@VERSION@
If deploying the virtual application on an intranet file share, place the sandbox in a user-accessible
subfolder on a shared network drive. The recommended sandbox location for intranet deployment
is:
\\ServerName\ShareName\%USERNAME%\Spoon\Sandbox\@TITLE@\@VERSION@
Generally, you should not place the sandbox under any privileged folders, such as @WINDIR@
or @PROGRAMFILES@. The virtual application may fail to execute properly if the Spoon
engine is unable to write to the sandbox location at runtime.
Environment variables may be referenced within the sandbox location by enclosing the variable
between percent signs, i.e. %VARIABLE%.
With the exception of the @BUILDTIME@ variable (set automatically), these variables are
based on the values specified in the Properties area of the Settings pane.
Studio includes the ability to generate Microsoft Windows Installer (MSI) setup packages to
facilitate deployment of virtualized applications. In addition to deploying the virtual application
executable file to the host filesystem, Studio-generated MSI packages also allow creation of
desktop and Start Menu shortcuts, creation of shell file extension associations to virtualized
applications, and Control Panel uninstallers for application cleanup.
This section describes configuration and build processes for MSI setup packages.
By default, MSI packages are not automatically generated or updated when the virtual application
is rebuilt.
To automatically update MSI packages after the virtual application is rebuilt, check the
Automatically generate MSI after successful application build option.
Regenerating MSIs may significantly increase the time required to complete the build
process. Therefore, Spoon recommends that this option be disabled during the virtual application
development process.
It is also possible to manually force the MSI package to be regenerated. To manually build the
MSI package, click the Build MSI button.
Note: You must build the virtual application executable before the MSI package may be
generated. The Build MSI button will be disabled if the virtual application executable has not yet
been built.
Note: The metadata published on the MSI package is distinct from the metadata published on the
virtual application executable itself. To modify executable shell metadata, specify the appropriate
metadata on the Settings pane.
Applications may be installed either for the current user or for all users of the target device. To
install the application for all users, check the Install applications for All Users option.
Note: Installing applications for all users requires privileged access to the host device. Do not
enable this option if the MSI package is designed for use by end users with standard user
permissions.
In the event that a user runs the setup package on a device which already has a version of the
application installed, the MSI package may be designed to update the existing application version
or side-by-side install with the existing application version.
To automatically update existing versions, select the Automatically upgrade earlier application
versions option; to use side-by-side installation, select the Allow side-by-side versions of the
same application option.
Note: Building with the Allow side-by-side versions of the same application option enabled
causes a new setup package GUID to be generated. Once a build is completed with this option
enabled, previous installations will no longer be upgraded in place, even if you revert to
Automatically upgrade earlier application versions mode.
• Click on the Desktop node under the Shortcuts node in the MSI tree view. This displays
the desktop shortcut list.
• Click the Add Shortcut button and select the desired shortcut name, target, and options.
The Target dropdown is populated with the startup file list, allowing shortcuts to be
quickly connected to jukebox entry points.
To install additional folders and subfolders on the desktop, click the Add Folder button and
specify the folder name.
The same procedure can be used to add shortcuts and folders to the Programs section of the
Windows Start bar, except that start bar items are configured under the Programs Menu of the
Shortcuts node in the MSI tree view. Note that Start Menu items are installed either to the current
user's Start Menu or to All Users’ start menu depending on the Install application for All Users
setting in the MSI installation parameters section.
Some common verbs are open, edit, print, and view. The Verb that is entered will be the text that
is displayed when the user right-clicks on the file. When Inherit is checked, the behavior of the
Verb will be controlled by the setup information in the virtual environment. When Inherit is
unchecked, a Target Startup File and Arguments will need to be entered manually. The
Arguments field should contain "%1" which is the full path to the file. When Default is
checked, the Verb will be automatically executed when the file is double-clicked.
File association properties may be modified or deleted by selecting the appropriate ProgId in
the Setup tree view and modifying the settings as appropriate.
For more information on deploying applications using Spoon Server, please refer to the Spoon
Server User Guide. Visit the Spoon.net web site for details on Spoon Server pricing and licensing.
Spoon automatically identifies a prefetch consisting of the components of the application which
must be loaded in order for the user to begin using the application. The prefetch is generally
around 10% of the total application size, though this can vary considerably depending on the
behavior of the specific application. Once the prefetch is transferred, the application launches
immediately.
Applications can optionally be registered to the local device upon transfer completion.
Registration moves the application content to a permanent location on the local device, making it
available offline, and creates all Start Menu icons, desktop shortcuts, and file associations related
to the application.
This section describes how to deploy virtual applications to USB storage devices using the
Publish to USB feature.
Remove the USB storage device to unregister the virtual applications from the host system.
Note: If AutoPlay is disabled on the host system, open the USB storage device's contents and
manually run XUsb.exe.
After virtualizing an application with Spoon Studio, it is often desirable to make the application
Start Menu icons, shortcuts, and file associations available on the users' desktop. SpoonReg allows
you to register Spoon virtual applications in the shell, creating all of the shell associations that
would generally be created during a standard install process. Unlike performing an installation,
however, registration and un-registration can be performed almost instantaneously.
SpoonReg also provides the ability to create, reset, and remove application sandboxes- virtual
environment "bubbles" where the virtualized applications reside. Sandbox management provides
fine-grained control over application linking and intercommunication.
Spoon Server users and administrators can use the SpoonReg mechanism associated with Spoon
Server to register applications to the desktop. For specialized deployment scenarios, contact your
Spoon representative to learn how to obtain your own version of the SpoonReg.exe utility.
Parameter Description
SpoonReg.exe AppSpec
By default, registration will create a local cached copy of the virtual application executable and
use the user's local profile as the sandbox location.
Note: The sandbox location specified during the virtual application build is ignored when
registering applications using the SpoonReg tool or Spoon Virtual Desktop Service.
Parameter Behavior
/nocache The virtual application executable will not be copied to the client machine. All
shortcuts and file associations will point to the full path as given by AppSpec.
SandboxSpec This parameter refers to the name and path to an existing sandbox. If this
parameter is specified and a sandbox with that name exists, the application will
be registered into that sandbox. (See the “Sandbox management” topic in this
section for additional details.)
Parameter Behavior
SpoonReg.exe /unregisterall
The Local profile is the default profile used by SpoonReg if no profile is explicitly specified on
the SpoonReg command line.
To register an application to the All Users profile, execute the SpoonReg command with the
/allusers command line flag.
You must have administrative permissions on the device to register applications to the All Users
profile.
To register an application to the Roaming profile, execute the SpoonReg command with the
/roaming flag.
Note: There is no roaming profile for All Users. Therefore, the /roaming flag has no impact when
used in conjunction with the /allusers flag.
Note: Because SpoonReg is applied to specific user profiles, it cannot be used for the
LocalSystem account (has no associated profile).
A sandbox contains all of a virtual application's isolated data and settings as determined by the
virtual application's isolation configuration settings. Applications registered to the same sandbox
can view and modify each others' virtualized data and settings.
By default, all applications are registered into a single default sandbox named Default. In some
cases, it may be desirable to group related applications into a sandbox that can be treated as a
single management unit. When a sandbox is reset, all of the application content and data stored in
that sandbox is purged and reverts back to the default state.
If no path is provided, a default path is created under the AppData folder under the specified
profile.
If a SandboxSpec is not supplied, the default sandbox will be reset (the default sandbox cannot be
deleted). Any applications registered to the deleted sandbox will be moved to the default sandbox.
To move a sandbox:
6.6.2 SpoonReg
SpoonReg manages the virtual desktop environment for a given user by registering and
unregistering virtual applications. A typical SpoonReg command to register an application such as
Firefox would be:
\\VirtualAppServer\Tools\SpoonReg.exe \\VitualAppServer\Apps\Firefox.exe
This represents the basic functionality of SpoonReg which would copy the virtual application
executable, create Start Menu items and desktop shortcuts and setup file associations. (For
additional functionality dealing with sandboxes, caching and automatic updates, refer to
“Deploying using Spoon Virtual Desktop”.)
Note: In order to manage virtual applications using Active Directory, the users must have access to
a shared network drive where the virtual application executable files exist. This can be specified
by a full UNC path, or by using a mapped network drive.
\\VirtualAppServer\Tools\SpoonReg.exe \\VirtualAppServer\AllVirtualApps\Excel.exe
\\VirtualAppServer\Tools\SpoonReg.exe \\VirtualAppServer\AllVirtualApps\Firefox.exe
\\VirtualAppServer\Tools\SpoonReg.exe \\VirtualAppServer\AllVirtualApps\AcrobatReader.exe
Whereas you might add the following for the graphic design group:
\\VirtualAppServer\Tools\SpoonReg.exe \\VirtualAppServer\AllVirtualApps\AdobeIllustrator.exe
\\VirtualAppServer\Tools\SpoonReg.exe \\VirtualAppServer\AllVirtualApps\Firefox.exe
\\VirtualAppServer\Tools\SpoonReg.exe \\VirtualAppServer\AllVirtualApps\AcrobatReader.exe
Note: SpoonReg has many other capabilities that can be applied in the GPO logon script, such as
unregistering applications or registering applications to a specific sandbox.
Sample 1. Register virtual applications to the default sandbox in the All Users profile:
\\VirtualAppServer\Tools\SpoonReg.exe /allusers
\\VirtualAppServer\AllVirtualApps\AcrobatReader.exe
Sample 2. Register virtual applications to the specified sandbox in the All Users profile:
\\VirtualAppServer\Tools\SpoonReg.exe /allusers
\\VirtualAppServer\AllVirtualApps\AcrobatReader.exe
• Navigate to Computer Configuration > Windows Settings > Scripts in the GPMC
• Open the Startup item
• Click Add
• Click Browse
• Select the Startup Script that was created
• Click Open
• Click OK
• Click OK
The recommended approach for using the virtual desktop service is to set up one machine with all
of the virtual applications that you want to distribute (see “Registering virtual applications in the
Windows shell”). The client configuration file from this machine will serve as the master
configuration file. Any users that you want to have the same virtual desktop configuration
synchronize with that file using the virtual desktop service.
SpoonReg.exe AppSpec
Note: Remember that the location of the virtual applications on the network must be accessible
and consistent for all of the users that are accessing those applications.
Note: The Spoon Virtual Desktop Service runs as LocalSystem, meaning that security must be
carefully considered. LocalSystem has access to resources on its domain via the machine
account. The machine account name is the machine name followed by a $ (e.g. the machine
account for server is server$). The machine account is also included in the Everyone domain
group. The final ramification of this is that the network location where the remote application
source is located must be a network share with read access for Everyone or for the specific
machine account. It cannot be a mapped network drive, since mapped drives are at the individual
user level.
Registering the client configuration file will automatically install and start the Spoon Virtual
Desktop Service and synchronize the virtual desktop environment.
Using zero or nothing as the parameter for seconds will disable automatic updates.
Deployment using generated MSI packages is appropriate in situations where existing MSI
package deployment mechanisms are in place, or for deploying applications with shell integration
without the SpoonReg Virtual Desktop client tool.
Virtual application and component shell integration settings are shared between MSI- and Virtual
Desktop-based deployment, enabling easy migration between deployment models.
Refer to the section “Building MSI setup packages” for more information on the creation of MSI
setup packages.
• On the TS RemoteApp server, open the TS RemoteApp Manager and choose Add
RemoteApp Programs by right-clicking inside the RemoteApp Programs list or
through the Action drop down menu.
• Click Next in the RemoteApp Wizard.
• Click Browse and select the virtual application executable.
• After the virtual application is added to the list, select it and click Properties.
• If the virtual application has multiple Startup Files, configure the RemoteApp Program
Name and Alias. If this is not done, the TS RemoteApp server will not distinguish
between the separate applications in the suite.
• Still in the Properties window, select Always use the following command-line
argument, enter in the Trigger for the Startup File that is to be executed, and click OK.
• In the RemoteApp Programs list, right-click the program that you added and choose
Create .rdp File. There are no special requirements for the .rdp files.
If there are multiple Startup Files, repeat these steps for the other applications in the suite and
deploy the shortcuts on the host systems.
To use your new Notepad virtual application, navigate to your desktop in a shell window and
double-click on Notepad.exe. The Notepad application starts.
But how do we know we are inside a virtual application? In the shell, delete the hello.txt file from
the desktop. Now, inside the Notepad window, click File / Open..., and navigate to the Desktop
folder. Notice that the hello.txt file is still present! This is because the Notepad virtual application
is using the virtual filesystem, which includes the hello.txt file that we added in the sixth step.
You can open and view hello.txt exactly as if it were a real file in the physical filesystem.
7.2.1 Snapshotting
The snapshot process consists of two phases -- the "before" snapshot and the "after" snapshot.
The before snapshot takes an inventory of all files and settings that are installed on the computer.
The after snapshot is taken after the application being virtualized is installed. The contents of the
after snapshot are compared to the before snapshot to determine all changes that were made to the
host system during installation. The after snapshot also copies the new or modified files to a
snapshot directory specified by the user.
Since it is required to install and capture all application dependencies during this process, it is
important that snapshotting be performed on a clean Windows machine. This guarantees that all
dependencies will be included in the installation and captured by the snapshot process.
To snapshot the OpenOffice installation:
• Capture the before snapshot by clicking Capture Before on the Studio ribbon bar. The
snapshot process may take a few minutes.
• Install OpenOffice and all of its necessary dependencies.
• Capture the after snapshot by clicking Capture and Diff. Studio will prompt for the
directory where the snapshot files are to be stored. This directory is usually located on an
external PC or network share.
Open the configuration menu and click Save Configuration or Save Configuration As.
Studio configuration files are stored in the Spoon XAPPL file format. The XAPPL file does not
contain the filesystem content. The filesystem content is stored in the Files directory which is
created during the "after" snapshot.
Note: The XAPPL file uses relative paths to identify snapshot files. Therefore it is required that
the Files directory and the XAPPL file be located in the same directory.
To set the Output File, click Browse next to the Output File field and assign it a file name.
• Open the Startup Files window by clicking on Multiple next to the Startup File field.
• Click the dropdown menu next to the File field, or navigate to the desired startup file in
the Filesystem pane, right-click the file, and select Add to Startup Files.
• Enter in command line arguments as needed.
• Enter in a unique Trigger for that executable. Triggers are command line arguments that
are passed onto the virtual executable that specify which Startup File to execute.
• Select Auto Start if the executable is to be started each time the virtual executable is run.
To create a setup file for the virtual application, the Output Location, Product Info, Installation
Parameters, Shortcuts, and File Associations need to be configured.
The Product Info is the metadata that will be associated with the setup file. The Product Info is
displayed in the Add/ Remove Programs window. It is recommended that this information be
accurate to avoid confusion.
The Installation Parameters control how the virtual application will be installed on the host
system.
Shortcuts allow the end user to launch the application directly from the Windows Start Menu or
Desktop.
• Click Browse next to the Output Location and assign it a file name.
• Check the Automatically generate MSI after successful build checkbox if the setup
file should be created automatically after the build process.
To automatically update existing versions, select the Automatically upgrade earlier application
versions option. This option will update previous versions of this virtual executable.
To use side-by-side installation, select the Allow side-by-side versions of the same application
option.
Note: The Company Name\Product Name needs to be entered in the Application Folder field.
If neither is entered, the virtual application will be installed under folders named “Company
Name\Product Name”.
Click Add Shortcut and assign it a Name, assign it a Target, select an Icon, and enter any
arguments that need to be passed to the specific application.
Folders that are created by the setup package can also be setup in this pane.
Click on the Add ProgId button and enter the ProgId and a Description of the file association.
Click Add Extension and enter the file extension and MIME Type (if necessary) to the ProgId.
If a verb is needed for the file extension, click Add Verb and enter the necessary information.
In OpenOffice, the installation files are created in the same directory that the install executable
was executed from.
• Click on the Build or the Build and Run button. This will create virtual application
binary file where the Output File is defined. The build process may take a few minutes.
• Execute the virtual application binary file. The OpenOffice splash screen will display and
the OpenOffice Quickstarter will open.
• Execute the virtual application binary file from a command prompt with the
"swriter" Trigger. For example, run "openoffice.exe swriter" from a command prompt
and the OpenOffice Quickstarter and Writer applications will open.
• Execute the setup file on a system without OpenOffice installed. The virtual application,
shortcuts, and file associations will be installed on the host system.
• Open the OpenOffice Writer Program from the start Menu shortcut.
• Open a file that is associated with the OpenOffice Writer program.
Virtual application updates can be captured within Studio via the snapshot process.
• Install the original native version of the application you wish to update on a clean
machine.
• Click Capture Before to snapshot the original version of the app.
• Install the necessary updates to the native application.
• Click Capture and Diff to create the “after” snapshot of the app. This will capture the
deltas between the original version and the updated version.
• Make sure the Project Type is set to Component, then click Build to create the SVM.
This process will only capture the changes between the original executable and the installed
updates. The resultant SVM can then be applied to the original virtual executable (for more
information on updating virtual applications using SVMs, refer to the topic “Specifying additional
SVM layers for a virtual application” in the “Advanced topics” section).
Each machine will need to be frequently re-imaged back to an initial configuration, or “clean”
state. “Clean” machines are required to effectively complete the build and testing processes. To
facilitate this process, you will need to save an image of the machines initial configuration on a
local partition, then use third party software to create an external drive that can be used to boot the
machine from that image.
Spoon recommends following these steps to setup the initial configuration for each machine:
• Install the operating system; delete all existing partitions, create a new partition to save
the “clean” image.
• Install all current patches for the OS (don’t upgrade Internet Explorer).
• Create accounts for an administrator, a standard user with UAC enabled, and a standard
user with UAC disabled.
• Disable automatic updates.
• For Windows 7 only: run Internet Explorer 8 once to prevent repeating the first-run
wizard each time you re-image the machine.
• Enable RDP access.
• In Power Options, configure the machine to never go to sleep.
• Disable the Windows Firewall.
• Right-click My Computer, select Properties, select Advanced, edit the Performance
Settings to “Adjust for best performance”
• Image the system, saving the image files to the appropriate partition.
Note: It is not strictly necessary to set up a build lab using physical machines; a build lab can also
be set up using a collection of virtual machine images. If this is your desired approach, Spoon
recommends creating virtual machine images for each of the six machine configurations described
in this section. The virtual machines should be configured following the steps set forth in this
section, excluding the creation of a new partition. It’s not necessary to create a partition to save
the “clean” image, because it’s possible to simply save the current state of a virtual machine.
• Use the snapshot technique to capture the application on a “clean” Windows XP 32-bit
machine. The snapshot process is covered in detail in the “Snapshotting Applications”
topic of the “Getting Started” section.
• Use Studio to generate a standalone executable (this will launch the virtual application).
• Test this executable per the recommendations in the “Build testing process” section.
• If the virtual application fails to run on Windows Vista or Windows 7, it may be
necessary to perform the snapshot on multiple platforms, and then perform a platform
merge. Refer to the “Platform Merge” topic in the “Advanced Topics” section for details
on how to perform a platform merge.
• After the application has been verified to work on all six platforms, use Studio to
generate a component (an SVM file) if needed.
If the virtual application fails to build or function correctly, please refer to the “Troubleshooting”
section in this document or contact Spoon support.
Spoon recommends adhering to the following strategies while testing virtual applications:
• Conduct testing on each of the six machine platforms identified in the “Setting up the
build lab” section.
• Under ideal circumstances, each machine in your build lab should be “cleaned” prior to
testing the virtual application.
• At a minimum, the virtual application should not be tested on a machine where the
application is also natively installed.
During the profiling process, you will use the application as a typical user would, while Studio
observes this behavior and stores it in a transcript. These transcripts are then subsequently used to
construct a streaming model of the application. There is no limit to the number of transcripts that
can be used to construct a streaming model, Spoon recommends gathering at least one transcript
from each of the six machine platforms identified in the “Setting up the build lab” section. The
profiling process is covered in detail in the “Creating application streaming models” topic in the
“Advanced Topics” section.
During the build process, Spoon recommends storing the snapshot files, the EXE and SVM in the
following folder structure: \\<Share>\Builds\<Application>\<Version>.
During the profiling process, Spoon recommends storing the transcripts and model files in the
following folder structure:
Transcripts - \\<Share>\Builds\<Application>\<Version>\Transcripts\
Models - \\<Share>\Builds\<Application>\<Version>\XStream\<Model Number>\
If it’s necessary to deliver virtual applications and models to Spoon, please contact Spoon support
([email protected]) for additional details.
To manually configure proxy settings, select the Proxy settings... option from the Options menu.
Provide the proxy server address, the server port and the type of authentication, if any, the proxy
server uses. Select the ‘Bypass proxy server for local addresses’ option to bypass the proxy server
when accessing resources located on the local network. Please contact your network administrator
if you need assistance configuring the proxy settings.
If you wish to disable this scan, uncheck the Automatically detect associated runtimes and
components option in the Options menu.
If you wish to disable this sound, uncheck the Play sound on build completion option in the
Options menu.
To disable quick snapshot mode, uncheck the Quick snapshot mode item from the Options
menu.
Note: "Before" and "after" snapshots must be taken using the same snapshotting
algorithm. Loading a saved snapshot image causes Studio to automatically configure the
snapshotting mode to be consistent with the algorithm used during the saved snapshot capture.
To use Internet Explorer snapshot compatibility mode, click the Options menu above the ribbon
bar in Spoon Studio, and select Internet Explorer snapshot compatibility mode from the
dropdown.
Most of the time, configurations are constructed using snapshotting or in the graphical user
interface. However, if manually modifying the configuration, the following well-known root
folder variables may be used to configure virtual filesystem locations. Root folder variables are
case sensitive.
The following is a complete list of root folder variables recognized by Studio and the
corresponding folder name displayed in the filesystem graphical user interface, followed by a brief
description of the root folder.
The command line version of Studio is called XStudio.exe and can be found in the Studio
installation directory. To build a virtual application from the command line, execute XStudio
Configuration.xappl from the command prompt, where Configuration.xappl is the name of the
Studio project created using the graphical interface.
Options specified in the XAPPL file may be overridden with the command-line flags given in the
following table.
Option Description
/before [/beforepath Snapshot Performs a before snapshot and saves the snapshot to the
Path] optionally specified snapshot folder. If no snapshot folder is
specified, the default snapshot folder is used.
/after [/beforepath Snapshot Performs an after snapshot using the optionally specified
Path] [/o Output Path] before snapshot path. If no before snapshot path is specified,
the default snapshot folder is used. The output XAPPL and
snapshot files are saved to the optionally specified output
path. If no output path is specified, the output XAPPL and
snapshot files are saved to the current user's desktop.
/component or /layer Forces the output type to component. This mode causes an
SVM to be generated.
• Click the Start menu button control menu (or press Alt-F)
• Select Import Configuration. This displays the configuration import wizard.
• Click Browse to select the configuration to be imported.
• Click Next.
• Follow the step-by-step instructions in the wizard to complete the import process.
Note: Some applications which depend on specialized custom actions during the MSI installation
process may require additional configuration following MSI import to be fully functional. Such
applications may need to be imported using the snapshot capture method.
• In the Virtual Application tab, click on the Multiple button next to the Startup File
field
• In the File column, enter the local path of the natively installed application.
• (Optional) Check the Auto Start option to have your natively installed application
automatically run when the virtual application is launched
• Click OK
This will enable your virtual application and natively installed application to interact with each
other in the same virtual environment.
A sample startup file path for Microsoft Word would look like this:
@PROGRAMFILES@\Microsoft Office\Office12\WINWORD.exe
If Auto Start has been enabled, Microsoft Word will launch with the virtual application, in the
same virtual environment.
Spoon allows the following virtualization settings to be specified on the virtual application
command line. Settings specified on the command line supersede design-time virtual application
settings.
Flag Behavior
The first mechanism is via the command line using the /XLayerPath= syntax. This syntax takes
a path with optional wildcards to additional SVMs to load.
virtual-app.exe /XLayerPath=@APPDIR@\patches\*.svm
virtual-app.exe /XLayerPath=@APPDIR@/patches/*.svm
/XLayerPath=@APPDIR@\officepatches\*.svm
virtual-app.exe /XLayerPath=\\network\share\patches\*.svm
MSOffice.exe /XLayerPath=c:\Patches\MSOffice_*.svm.
This would do a wildcard match finding any files such as MSOffice_001.svm in the c:\Patches
directory.
Note: The SVMs are applied in reverse-alphabetical priority. This means that items in
MSOffice_002.svm have higher priority than items in MSOffice_001.svm.
The second mechanism is a XAPPL file specified way to load additional SVMs. It is via the
<XLayers> portion of the XAPPL file and has the following elements:
Attribute Description
<XLayers XLayerSearchPattern="@APPDIR@\StudioDependencies.svm">
Note: Newer versions of Studio make use of SVMs as opposed to XLayer files. Older XLayer
files must be rebuilt as SVMs as there is currently no supported conversion utility. SVMs function
in the same way as XLayer files in that they will be auto-integrated with virtual executables by
being placed in the same directory as the executable.
Tip: The most common platform merge scenario is a merge of snapshots taken on Windows XP
and Windows Vista. This is because some newer applications use operating system features
specific to Windows Vista.
The Filesystem and Registry panels will only display settings specific to the selected operating
system. Note that you cannot edit configurations which are inherited from other platforms; to edit
inherited configurations, you must select and edit the master configuration.
The Profile feature generates transcripts, or profiles, which are then used to create a streaming
model for the virtual application. Clicking the Profile button launches the application and creates
a single transcript file based on observed user behavior during that run. It is recommended that
multiple transcripts are created before creating a streaming model. Using multiple transcripts
allows the streaming system to take into consideration different use cases for the application. It is
also recommended that at least one transcript be created for each operating system.
Note: Only uncompressed virtual applications can be profiled and streamed. Compression is
automatically disabled during the model build process.
Once the necessary profiles have been created, the streaming model is ready to be built. The model
build process uses the transcripts and Connection Speed parameter to compute a model of
execution. After the model build process is complete, the streaming files are written to the
selected output folder. The Connection Speed setting is used to optimize delivery of application
content to the end-user.
• Select the desired Connection Speed. The 1.5Mbps connection speed setting is
recommended for most scenarios.
• Click the Build Model button.
• Select the folder where the transcripts are located and click OK.
• Select the folder where the streaming model will be created and click OK.
For all expiration modes, the System clock setting will use the host system's clock to validate the
date. The Web server clock setting will validate the date against an HTTPS-based web
server. Check the Disallow execution if web server is unreachable checkbox to prevent the
application from being executed offline.
Tip: The Web server clock setting is more secure than the System clock setting since it prevents
the expiration mechanism from being circumvented by modifying the system clock. However, this
setting will prevent applications from executing on devices which cannot connect to the time
server source.
Optionally, an Expiration Warning can be set to warn the user when the virtual application is
about to expire. The message will be displayed each time the virtual application is executed when
it is within the specified threshold.
Studio allows the virtual application configuration to be applied to the host system. Applying the
virtual application configuration to the host system is helpful when creating SVM updates for
virtual applications.
• Click the Apply Configuration button in the Start menu of the Studio application.
• Enter the path of the sandbox to be merged into the current configuration.
• Click Yes to acknowledge that the Apply Configuration process cannot be undone.
Note: The Apply Configuration feature is not intended for use as an installation process for
virtual applications.
For example, to create an SVM update to the Firefox virtual application template:
Currently, shared object isolation can only be enabled by manually editing the XAPPL file for a
virtual application.
In the following scenario, OBJECT 1 and OBJECT 2 are named objects used by a virtual
application that conflict with identically-named objects used by a natively installed application.
Common named objects include mutexes and named pipes.
To enable shared object isolation for OBJECT 1 and OBJECT 2 in a virtual application:
• Open the XAPPL file of the virtual application you are working with in a text editor
• Replace the <NamedObjectIsolation ../> element with the example below:
<NamedObjectIsolation enabled="False">
</NamedObjectIsolation>
The resulting virtual application will have shared object isolation enabled. Note that multiple
objects in memory can be isolated simultaneously.
All paths in the XAPPL file are relative to where the XAPPL file resides. For example, the
source attribute of a File element will begin with ".\Files\". The ".\" directory is the path where the
XAPPL file should reside in order for Studio to locate the physical source files during the build
process.
The XAPPL file must adhere to all XML syntax rules. If there are syntax errors in the XAPPL
file, Studio will not load the file.
In this section, attribute values are shown in parenthesis after their description and default values
are shown in bold.
• The outputlocation attribute is the path to the folder where the virtual application
executable will be created. This can be a local path, a UNC path, or a mapped drive.
OutputFile
• The outputfile attribute is the file name of the virtual application executable.
Project Type
• The project type attribute denotes whether this configuration is for a virtual application
(Application) or an SVM (Component).
Licensing
• The licensing attribute contains information about the license that was used to build the
virtual application.
Output
• The diagnosticMode attribute denotes when the application output should log diagnostic
information (True) or not (False). If true, the virtual application will create diagnostic
logs in the directory where it was executed from.
• The sourcePackage attribute is not used.
MSI
All sub-elements contain settings pertaining to the configuration of the MSI setup file.
• The outputMsiPath attribute indicates the location where the setup MSI will be built.
• The title attribute indicates the value of the MSI title property.
Packages
All sub-elements contain settings pertaining to the configuration of the packages included in the
virtual application.
Clr
The .NET Clr runtime element and all sub-elements contain settings pertaining to the
configuration of the virtual .NET Framework runtime.
Direct X
The DirectX element and all sub-elements contain settings pertaining to the configuration of the
virtual DirectX runtime.
Java
All sub-elements contain settings pertaining to the configuration of the virtual java runtime.
RunTime
Settings
• The startupType attribute denotes whether to use the jar file (JAR) or class path (Class)
command line parameters for java.exe to launch the application.
• The startup attribute indicates the jar file path or class name depending on the
StartupType.
• The classpath attribute indicates the path to the class files of the Java runtime.
• The options attribute denotes any additional command line parameter.
Package
Virtualization Settings
All sub-elements contain settings pertaining to the configuration of the virtual operating system.
• The suppressBranding attribute controls the branding pop-up that is displayed (False),
or not displayed (True) in the lower right-hand corner during application startup.
• The isolateWindowClasses attribute is used to isolate windows classes, as registered via
the Windows ::RegisterClass or ::RegisterClassEx APIs. For example, this allows a
virtualized Firefox instance to run while a non-virtualized instance is running.
• The readOnlyVirtualization attribute denotes whether the virtual application has the
ability to modify virtual files and registry settings (False) or not (True). Setting this
attribute to True will prevent modification to the virtual filesystem and virtual registry.
• The disableXenocodeCommandLine attribute controls the ability to execute (False) any
file from within the virtual filesystem.
• The subsystem attribute indicates the application output type. It can be inherited from the
startup file (Inherit) or set explicitly to be a Windows application (GUI) or console
application (Console). If Inherit is set, but the startup file is either not in the virtual
filesystem or not an executable, then the output will be a Windows application.
• The ie6Emulation attribute denotes a special mode required for the Internet Explorer 6
template (True). For all other apps, this should be disabled (False).
• The sandboxPath attribute indicates the base path of the application sandbox
(@APPDATALOCAL@\Spoon\Sandbox\@TITLE@\@VERSION@).
• The workingDirectory attribute defines what directory the application will run in.
ChildProcessVirtualization
ChildProcessException
• The name attribute indicates the name of the executable file (extension included) to
except from the effects of the spawnVm attribute.
CustomMetadata
All sub-elements contain settings pertaining to the configuration of the individual custom
metadata items.
• The property attribute indicates the name of the custom metadata item.
• The value attribute indicates the value of the custom metadata item.
StandardMetadata
All sub-elements contain settings pertaining to the configuration of the individual standard
metadata items.
StandardMetadataItem
• The property attribute indicates the name of the standard metadata item. The following
are the available standard metadata:
o Product Title (Title)
o Publisher (Publisher)
o Description (Description)
o Website (Website)
o Product Version (Version)
SplashImage
• The path attribute indicates the source path to the splash image displayed at application
startup.
• The transparency attribute indicates the color in the splash image that should be made
transparent when the image is displayed (E.g. Magenta).
StartupFiles
StartupFile
StartupShim
The startup shim is a virtualized binary that is invoked prior to the startup file. Startup shims are
used to perform customized licensing checks or other initialization tasks.
Layers
Layer
The Layer element and all sub-elements contain settings pertaining to the configuration of this
layer of the virtual operating system.
• The name attribute indicates the name of the layer. The default layer (Default) is the
only layer for whom the name matters. All other layer names are purely informational.
Condition
• The variable attribute indicates the host system setting that will be evaluated. The
operating system version (OS) is the only available option.
• The operator attribute indicates the Boolean operation that will be used to evaluate the
host system. The available Boolean operations are:
o greater than or equal to (GREATEREQUAL)
o greater than (GREATER)
o equal to (EQUAL)
o not equal to (NOTEQUAL)
o less than (LESS)
o less than or equal to (LESSEQUAL)
• The value attribute indicates the value against which the host system will be evaluated,
using the Boolean operation. The available values in ascending order are:
o Windows 2000 (Win2k)
o Windows XP (WinXP)
o Windows 2003 (Win2k3)
o Windows Vista (Vista)
Filesystem
All sub-elements contain settings pertaining to the configuration of the virtual filesystem.
Directory
All sub-elements contain settings pertaining to the configuration of this directory of the virtual
filesystem.
• The rootType attribute indicates the root system folder that this virtual folder is mapped
to on the host filesystem. Directory elements with the rootType attribute are always
File
All sub-elements contain settings pertaining to the configuration of the virtual registry.
Key
All sub-elements contain settings pertaining to the configuration of this key of the virtual
filesystem.
• The rootType attribute indicates the root system folder that this virtual folder is mapped
to on the host filesystem. Key elements with the rootType attribute are always directly
beneath the Registry element. The following are the available rootType values:
o HKEY_CLASSES (ClassesRoot)
o HKEY_CURRENT_USER (CurrentUser)
o HKEY_LOCAL_MACHINE (CurrentUser)
o HKEY_USERS (Users)
• The name attribute indicates the name of the key.
• The namePathInformationTuples indicates that there is a path in the name or value of
the registry item. There are 3 comma delimited integers for each path found in the
name/value.
1. Flags that indicate the state of the path (valid combinations: 0x0, 0x1, 0x2, 0x4, 0x5,
0x6)
• The isolation attribute indicates the isolation setting of the virtual folder. The available
values are:
o Full isolation (Full)
o Merge isolation (Merge)
Value
1. Flags that indicate the state of the path (valid combinations: 0x0, 0x1, 0x2, 0x4, 0x5,
0x6)
• The value attribute indicates the value of the value. This is true for all types, except
StringArray, which contains the String sub-element.
Environment Variables
Services
Shortcuts
All sub-elements contain settings pertaining to the configuration of the MSI shortcuts.
All sub-elements contain settings pertaining to the configuration of the MSI shortcuts in this
folder.
• The name attribute indicates the name of the folder. The two top level folders represent
the Desktop (Desktop) and the Programs menu on the Start menu (Programs Menu).
Shortcut
IconResource
• The IconResource sub-element contains an identifier of the icon that is used for the
Shortcut.
ProgIds
IconResource
• The IconResource sub-element contains an identifier of the icon that is used for the file
association.
Extension
All sub-elements contain settings pertaining to the configuration of the file extensions for the
ProgId.
• The extension attribute indicates the file extension that is associated with the ProgId.
• The mimeType attribute indicates the MIME type of all files with the extension.
Verb
All sub-elements contain settings pertaining to the configuration of the Verb for the file extension.
If you encounter a problem with a virtual application, please carefully read this section or query
the online knowledge base before using other support options. It is very likely that the issue you
have encountered is addressed in one of these places.
In many corporate environments, access to the Internet is filtered through a firewall or proxy
server. In these cases, Studio will attempt to automatically configure itself for Internet access
based on the system Internet settings. In some cases, however, it may be necessary to manually
configure the proxy server settings.
• Click the Proxy Settings... option on the Options menu. This displays the Proxy
Settings dialog.
• Enter appropriate proxy server settings in the dialog. It may be necessary for you to
consult your system administrator to obtain your organization's proxy server settings.
To assist in diagnosis of these problems, Studio offers the option of creating diagnostic-mode
executables. Diagnostic-mode executables generate logging data during execution that can assist
in diagnosis of problems related to virtualization.
Execution of the instrumented executable will generate a xclog_<id>.txt file in the application
startup directory that contains detailed diagnostic data gathered during execution. Inspection of
this file, particularly of entries labeled WARNING or ERROR, often allows diagnosis of
virtualization errors. If you require assistance from Spoon technical support to resolve your
problem, we strongly encourage you to submit this information along with your support request to
facilitate resolution of your issue.
Note: Because diagnostic-mode executables run significantly slower than standard executables and
generate very large log files, diagnostic-mode executables should not be distributed to your end-
users.