Home > Blogs > VMware ThinApp Blog > Tag Archives: 4.5

Tag Archives: 4.5

Changes made to the ThinApp EULA in version 4.5

Many of you might not know that one big change was made to the End User License Agreement (EULA) in ThinApp 4.5.

The EULA now states:

You must have a separate VMware ThinApp license for each Device or individual named end user, except for Device or individual named end user running ThinApp in an authorized concurrent use environment. You may run an unlimited number of ThinApps on a licensed Device. Dynamic Reassignment of VMware ThinApp is prohibited.  

Continue reading

VMware ThinApp 4.5 – What’s new?

ThinApp 4.5 is VMWare's most significant application virtualization update since its debut in 2008.

What's New?

Full support for Windows 7 and Server 2008 R2

One of the most anticipated features of ThinApp 4.5 is full support for Windows 7 and Server 2008 R2 (both 32 and 64bit editions). Some questions about Win7 support which were common with our beta users are:

Q: Do I need to recapture my packages to enable them for Win7?
A: No, existing projects will work on Win7 if you rebuild them using ThinApp 4.5. The new relink feature (see below) makes upgrading packages even easier.

Q: What OS should I capture on to support Win7/Server 2008 R2?
A: As before, you should capture applications using the lowest platform you plan to deploy to. For most of our customers, this is Windows XP.

New utility: Relink – upgrade packages in seconds without repackaging or rebuilding


Relink can be run against existing ThinApp packages in either .exe or .msi format and automatically upgrades them use the latest and greatest version of the ThinApp runtime and package format.    Relink accepts wildcard filenames and can work in recursive mode to upgrade all packages located under some parent directory.    Relink is very handy if you have packages without associated projects and you want to upgrade them to support Windows 7.   Relink usage looks like this:

relink [-Recursive] ExistingPackage [ExistingPackage…]

Relink will automatically create a backup of files it upgrades, so make sure you have enough disk space for 2 copies of your packages. Currently the AppLink feature requires that both the base package and the dependency packages both be current ThinApp 4.5 packages if either is built with 4.5.  Relink makes it fast and easy to upgrade any packages needed.   With relink, there is no need to recapture applications that work fine on other platforms.

Improved support for MSI packages.  

Support for >2GB single file MSIs. As applications have grown in size over the years, it has become more and more common to generate deployment packages larger than 2GB however the MSI/CAB file formats do not support files larger than 2GB. ThinApp has always supported creation of EXE/DAT packages of any arbitrary size (100GB or more) , and now with ThinApp 4.5, an industry first, ThinApp generated MSI packages can be larger than 2GB without requiring separate CABs or data files.  Because native MSI & CAB don’t natively support file sizes above 2GB we pulled off some clever tricks to make this work.   In the past if you wanted to deploy something like AutoCAD as an MSI package to end-users you had to split it up into multiple CAB files and wrap this in a ZIP file or other container (ZIP32 doesn’t support files larger than 4GB either).   It simplifies many processes if you can work with one single file for deployment or point end-users to a single http link and tell them to “just run this file”.     As before, ThinApp MSI files are still compatible with all versions of Windows Installer so you don’t need to worry about what your clients have installed.

MSI Install now twice as fast. MSI installation times have also dramatically improved in ThinApp 4.5.   Compared with ThinApp 4.0.4, installing a ThinApp generated MSI is approximately twice as fast for both the case where the source MSI is located on the local hard drive or a network share.

Fast random access to MSIs from ThinApp Management SDK. The ThinApp Management SDK can be used to access data inside of ThinApp generated MSI files.   In ThinApp 4.0.4, in order to access that data the entire CAB file needed to be decompressed.  In ThinApp 4.5 we now have fast random access to data inside of MSI files so there is very little performance difference between operating on a ThinApp EXE/primary data container and a ThinApp MSI.

I/O performance improvements for VDI
In 4.5, use of the system swap file is greatly reduced which means few disk I/O writes occur.  In VDI environments with shared storage this will effectively allows you to support larger numbers of users per storage array.   For example,  in ThinApp 4.0.4 Word 2007 requires approximately 99MB in page file backing and in ThinApp 4.5 this is reduced to 88MB.  When running multiple applications from a shared suite of applications the saving are even bigger.  Launching Word, Excel, and PowerPoint simultaneously results in a 37MB page file backing savings with ThinApp 4.5.


Memory sharing improvements for suites of applications and Terminal Server
In shared multi-user environments it is common to run many instances of a single application.    For example 10 users may be logged into a single Terminal Server box each running their own instance of Microsoft Word.    In ThinApp 4.5 pages from one instance of an application will be shared with other users running the same application even if they are logged into different sessions.   This memory sharing also works with suites of applications like Office where a set of common DLLs are loaded into different applications (Word & Excel). For example, the MSO.dll library is loaded by all Office applications but only one copy of the DLL is actually present in memory if one user runs Word ® and another runs Excel ®. In order for this memory sharing to occur, the same package must be run by both users from the same location on disk (or network share).


Startup time improvements
For many users, application startup time is one of the most important criteria for user acceptance. In ThinApp 4.5, many applications will start significantly faster. For example, Power Point 2007 loads approximately twice as
fast compared with previous versions of ThinApp when launched from a local hard drive with a cold disk cache.

Time in seconds to startup Power Point 2007, 2nd+ execution, cold disk cache


Bandwidth consumption improvements
Compared with ThinApp 4.0.4, ThinApp 4.5 typically uses less bandwidth to stream an application from a network share during initial application startup. For Office 2007 applications, the amount of bandwidth consumed to stream an application from a network share has been reduced by approximately 50% (half the bandwidth required from 4.0.4). This improvement comes from a new build optimization process that performs static analysis on executable data and arranges packages such that less executable code needs to be present on client systems in order to begin execution.

Example bandwidth consumption (in MB) when streaming Word 2007


New package.ini parameter: OptimizeFor
ThinApp 4.5 adds a new optional package.ini parameter called "OptimizedFor" which can be set to either "Memory" (default) or "Disk". ThinApp's new performance and memory sharing features may result in larger package files.  In the worst case scenario packages can be twice as large as before but in most cases the size difference, if any, is will be less significant. If disk size is more important than memory utilization and startup performance, you can set "OptimizeFor=Disk" in package.ini under [BuildOptions]. The result of such a change will cause package sizes to be similar as 4.0.4 and lower. In ThinApp 4.5, virtual executable files such as EXEs and DLLs are not compressed inside of packages on disk even when CompressionType=fast is enabled unless OptimizeFor=Disk is also set.

Support for capturing on partially non-clean PC
In order to capture applications using Setup Capture, you need a clean instance of Windows so that a proper install diff can be generated. The most popular way to capture applications is to use a clean instance of Windows using VMware Workstation to run the installation and revert back to a clean snapshot. Guest VMs are a lot more usable with vmware tools installed in the guest however vmware tools installs some libraries such as a newer C runtime which could cause a resulting install capture diff to miss such libraries if the application also installs them. In ThinApp 4.5, when installing an MSI based application ThinApp 4.5 can automatically detect files and registry entries that the application requires even if those entries already exists on the capture PC. This results in correct captures even in the case where some libraries are installed on the PC. Our solution for detecting dependent registry keys and files is generic and should work with other libraries but at this point we only test the VMware Tools scenario and using a clean PC is still best practice. Our detection logic only works when both the libraries and captured application using MSI based installation.

Quality Reporting 1.0
ThinApp 4.5 includes a new feature called Quality Reporting that can optionally be enabled to allow virtualized applications to report quality metrics to VMWare servers. When enabled, applications try to report the following information to qualityreporting.vmware.com via a simple http query once every 10 days.

– Operating System version the application ran on
– Name, Version, and vendor of the application
-The Inventory name you selected for the application
– Start and cumulative total execution time for the application
– Number of executions of the application
– Number of times crashes were detected during execution

Some clarifications about this feature:

– This feature doesn't transmit any data that can identify you, your company, or your license key
– VMware doesn't record the IP address of clients making connections to report data
– Enabling the feature does not impact the performance of the application
– Data reported to the server is small (a few kilobytes) and occurs once every 10 days so has almost no network impact
– This feature is invisible to end-users. There is no impact if network connectivity is unavailable.

Our goal with this feature is to build a database of what applications work well with ThinApp and which applications we should focus more attention on. We expect to aggregate this information over time and share the information with the community so our customers have better guidance on application compatibility before getting to testing phases. The information collected will also help to ensure our engineering team is focused on applications that are most important to our customers. In other words, if you turn on quality reporting, you are indirectly telling our engineering department what is important to you.

If you want to manually enable or disable quality reporting after completing a capture, you can edit the package.ini option “QualityReportingEnabled=1” to enable and delete or set “QualityReportingEnabled=0” to disable.

Journaling of Virtual file system meta data and virtual registry 
This feature was included in ThinApp 4.0.4, but largely remained a secret. The purpose of journaling is to support the ability to recover gracefully in the event disk writes are incomplete or the disk state becomes inconsistent when sets of disk writes are not flushed atomically. Journaling is used by advanced file systems such as NTFS and most modern database systems but is absent in simpler file systems like FAT32. With previous versions of ThinApp there were cases where sandboxed virtual registry and file system could become corrupted. Some examples include:

– Incomplete disk writes when sandbox is hosted on network share and network dies
– Incomplete disk writes to USB devices if device is not properly ejected
– Incomplete disk writes if application terminates abnormally during write operation
– Incomplete disk writes when power failure occurs

In previous versions of ThinApp, we had a relatively simple method of dealing with such problems – we would create a backup of the registry and file system meta data on startup and check for corruption on subsequent executions. In the event corruption was detected, we would restore the backup of the meta data. This approach worked fairly well, but could miss a few edge cases where corruption occurred and wasn't detected or meta data did not match non meta data. Now, a separate journal file is kept to transact write operations separately from the primary database. On startup, we can easily detect if previous database writes were not committed and flush them from the journal file. This "enterprise class" feature makes ThinApp a very robust way
to deploy applications even when data-stores are not completely reliable.  This feature doesn’t introduce noticeable cpu or disk performance impacts.

Improved support for application white listing (AppLocker for Windows 7) image
Application white listing systems allow desktop administrators to limit the set of applications a user can execute to a specific set included in a "white list." If the user tries to run an application not found in this white list, he/she will get an Access Denied message. This type of policy is used to ensure users cannot run applications downloaded from the Internet or brought in on USB keys. In ThinApp 4.0.4 and below, some "stub" executables for child processes were dynamically generated at runtime making it more labor intensive for Administrators to pre-define a white list which included all the processes the application might execute. ThinApp 4.5 removed the need to generate "stub" executables making it easier to include a ThinApp package and all of it's child processes in a whitelist.  As an example, Office 2007 installs a service called MDM.exe which ThinApp runs as a virtual service when any Office application is first started.   In previous versions of ThinApp it was necessary to include the ThinApp user entry points as well as the dynamically generated “stub” process name for MDM.exe in the white list.   In ThinApp 4.5, white listing systems such as AppLocker will only see a multiple request to execute user entry points for virtual child processes where the child EXE is located inside the package.  Effectively, if you white list a ThinApp package, you are white listing everything inside the package as well. If a virtualized application tries to execute a process not contained in the package, the normal white listing logic will occur.

One by-product of this change is that Task Manager may show different process names from previous version of ThinApp.  In the above MDM.exe example where ThinApp spawns  a virtual service process, Task Manager will shows new behavior for Vista and higher.  In Vista and higher, Task Manager will show that two copies of the user entry point EXE are running.  For XP and below it will show two separate process names are running.  If you have a need to obtain the name of the process from the virtual environment’s perspective in a portable fashion, you can use the ThinApp scripting command GetCurrentProcessName.  As well, if a virtualized application uses an API like GetModuleFileNameEx it will retrieve process names from the virtual environment’s perspective.


For Vista and higher, Task Manager will show multiple copies of the user entry point running for things like virtual services and secondary virtual child processes.

User Interface Improvements
ThinApp 4.5 has a new "Quick Start Video" to walk you through the process of capturing your first application and a some detail on each of the options you see exposed in the Setup Capture wizard. The video is only a few minutes long and If you haven't used ThinApp, it's a great way to get started. We've found that ThinApp is being used by an ever widening audience, it's not just for techie desktop administrators anymore. The ThinApp team also conducted some usability studies and made some changes based on the feedback we've received. Our long term goal is bring application virtualization to the most novice users while retaining the power and functionality expected by power users.


Quality improvements & Wine test
Application compatibility is our #1 goal with ThinApp.  If the applications you need to virtualize don't work then all the other features in the world don't matter. In ThinApp 4.5 we've resolved more than 300 issues and extended our testing in many directions. ThinApp has Quality Assurance teams in Palo Alto, Mumbia, Bangalore, and Beijing who have run through a suite of over seven million API test, 40,000+ automated application test, and 10,000+ manual application and feature test for ThinApp 4.5. These teams run test on a wide array of operating systems including NT4, Windows 2k, XP (32/64), Vista (32/64), Win7 (32/64), Server 2003, Server 2008 (32/64), Server 2008 R2 and a wide array of applications. Additionally the ThinApp engineering team has been working diligently with the Linux Wine team to collaborate on suites of automated test. A significant number of test fixes made by ThinApp engineering were contributed back to the Wine project, especially targeted at reducing the number of test failures on Windows 7. The ThinApp engineering team has also set up ‘WineTestBot’, a service which allows Wine developers to run tests on VMware Virtual Machines which run a large selection of Windows versions. The result of the collaboration is both Wine and ThinApp improve their quality.

ThinApp Community Portal for Applications
In addition to the ThinApp Quality Reporting mechanism, ThinApp users can more actively participate in sharing packaging information with the community via the ThinApp Community Portal. The ThinApp community portal allows users to publish and share their ThinApp project files and packaging tips, and search for information about applications that other users have packaged. http://communities.vmware.com/thinap.jspa


Where can I get ThinApp 4.5?
Visit the ThinApp main product page for downloads, evaluations, and more.