Home > Blogs > VMware ThinApp Blog > Author Archives: Travis Sales

Author Archives: Travis Sales

Anti-Virus Questions

There are two scenarios to consider with AV.

  1. Files you packaged yourself and are delivering to end-users
  2. Files the end user or app might try to create/modify at runtime.

AV systems cannot scan inside of a Thinstalled EXE.    You can protect against this by making sure your packaging computer has AV installed and up-to-date before you build into an EXE file, since the ThinApp project structure is just normal files on the filesystem your AV should scan these.   

If you inadvertently package a virus/Trojan inside of one of your packages, then two things are true:

  1. The virus Trojan will be largely unable to spread to the rest of the system.  For example, viruses and Trojan typically to spread by writing to HKLM\…\Run, the Startup folder, or overwriting system32 files.  In all of these cases ThinApp will sandbox those changes, so when the computer restarts or the user logins in again – the Trojan will not run again because those changes haven’t occurred.   One exception is that by default we don’t sandbox writes to network shares, so if you have exposed writable network shares a Trojan could spread through this.
  2. If the app tries to copy files from inside the package to the system or makes a network connection and tries to download new content (usually EXE files), ThinApp will write these files to the sandbox.  The sandbox is just normal plain files on the filesystem, and your AV system will definitely scan and quarantine anything detected as malicious.

Because ThinApp doesn’t use any device drivers it is compatible with all AV solutions.  The only issue we have is the occasional false-positive, but that happens with everyone and this usually gets correct by AV vendors within a few days.


Creating Links to Non-Exe objects using Thinreg.exe

This may not be the most elegant but in the meantime, here a solution that you can use if needed.

  1. You will need to download the ShellExecute.exe application from the web.
  2. During capture, copy ShellExecute.exe onto capture PC (let’s say c:\app) 2. Create a Shortcut on the StartMenu which will launch the template document using ShellExecute like this "c:\app\ShellExecute c:\mydocument.xls"
  3. When you finish the capture you should have an EXE target which will launch a template document using the virtualized application and it will install to the StartMenu using Thinreg.

You can manually do this in package.ini after the capture completes if you know the format to use.

Excel DDE Workaround

For those who have needed a workaround to the DDE file type issue surrounding Excel, please download the .reg file below and follow these directions. Remember, you can always script this into your .exe if you rather have this run at first launch. Just be sure to use the ExecuteExternalProcess function to have it apply to your local system.

  1. Use ThinReg as usual to register file types (Or MSI installer)
  2. Download the linked ExcelDDEOpen.reg file, open the .reg file using notepad
  3. Change the path to "Microsoft Office Excel 2007.exe", remember to use "\\" instead of "\" to separate directories
  4. Save ExcelDDEOpen.reg
  5. Add entries to registry by double-clicking the modified ExcelDDEOpen.reg file

The attached code for ExcelDDEOpen.reg file is set up to use per-user registry entries. If you want per-machine registry entries, change all occurrences of HKEY_CURRENT_USER to HKEY_LOCAL_MACHINE


Please create a file called ExcelDDEOpen.reg and paste this info into it.

———Copy Below———-

Windows Registry Editor Version 5.00




@="\"C:\\Path\\to\\virtual\\package\\Microsoft Office Excel 2007.EXE\" /e"










@="\"C:\\Path\\to\\virtual\\package\\Microsoft Office Excel 2007.EXE\" /e"







Compression Tip

When using Compression in your application, be sure to remember that
you can use compression at the folder level by specifying the
"CompressionType=Fast" command within the ##Attributes.ini in lieu of
using the global setting in the package.ini. You may decide that you
just need to compress certain folders that contain very large files
while leaving the remainder of the application uncompressed. This
technique can help you reduce the overall footprint without needing to
compress the entire application.

MSI Generation Tip

There has been some recent talk about what is required to deploy a Thinstalled application as an MSI. Well, as we all know, Thinstall has an MSI generation feature already built into the product today. With nothing more than a simple deletion of a semi-colon in the package.ini, Thinstall will generate for you an MSI installer for your Thinstalled application. Below is a list of some of the finer points to consider when using this feature.

If you wish to deploy the MSI to a user who does not have local admin privileges, just set the entry in the package.ini for MSIRequireElevatedPrivileges=0. This will allow a limited user account to install the Thinstalled application without Admin rights.

  1. If you are an administrator and you want to install the Thinstalled application machine wide, simply use the MSIDefaultInstallAllUsers=1 in the package.ini to accomplish this.
  2. If you want to have it both ways, so that users get a per-user install while anyone in the Administrators group is allowed to perform a machine wide install, than simply set MSIDefaultInstallAllUsers=2 in the package.ini instead.

CachePath Setting in Package.ini

When using AppSync, remember that you now have a new entry that will allow you to control the location of the upgraded file on the local file system.

CachePath–Sets the path to the cache directory where Application Sync updates and font files are stored. This setting can contain macros like %Local AppData% which will be expanded before use. If the path is relative, it is interpreted relative to the directory where the package is stored.

The setting can be overridden at runtime by the environment variable, THINSTALL_CACHE_DIR.

If neither the CachePath setting nor the THINSTALL_CACHE_DIR environment variable are present, a default is used. The default depends on the presence of a SandboxPath setting in the package.ini file. If there is a SandboxPath setting and it is a relative path, then CachePath defaults to the same path. If there is no SandboxPath setting or the path setting is absolute, then CachePath will default to %Local AppData%\Thinstall\Cache.

For example, set the cache directory to C:\VirtCache:

  • CachePath=C:\VirtCache

With the package located in C:\VirtApps, this will set the cache to C:\VirtApps\Cache:

  • CachePath=Cache

In a typical USB key scenario, you force the sandbox to the USB key. If the packages are stored in a subdirectory, \VirtApps, on the USB key, enter the following to force the cache directory to the USB key too:

  • SandboxPath=Sandbox