For More details be sure to visit our release notes located here:
Thinapp 4.6.2 is a maintenance release and primarily consist of bug fixes and application compatibility improvements. As usual, you can use the relink utility to automatically upgrade any of your older packages to use the ThinApp 4.6.2 runtime.
Beyond compatibility enhancements, there are also a number of new items to highlight in this release.
Today we posted a free version of the vSphere Client packaged with ThinApp.
ThinApp 4.6.1 is a maintenance release and includes fixes for more than 160 known issues.
VMware is pleased to announce the availability of the NEW ThinApp ROI/TCO Calculator.
Full support for Internet Explorer 6 running on Windows 7.
ThinApp has been successfully used to help customers virtualize and isolate many browser related issues such as ActiveX controls and various versions of Java.
Two years ago today, VMware released ThinApp to the world. The ThinApp product was originally released under the product name "Thinstall" in March of 2001 by a little company named Jitit. VMware acquired Thinstall in January of 2008, and after obtaining the trademark "ThinApp", it re-released the product as ThinApp 4.0.
The first version of Thinstall only supported the ability to bind DLL files with EXE files to eliminate the need to ship multiple-file applications for things like vb6 applications. Soon after it's initial release, Thinstall introduced the concept of a virtual registry which allowed vb6 developers to use COM components embedded in their application without system registry changes. Because developers needed to ship components that were compressed or contained checksum validation code, Thinstall added support for a compressed virtual filesystem. Over time, the ThinApp became a general purpose means of packaging and distributing custom and off-the-shelf applications. Thinstall 3.0 was a big milestone because it introduced the ability to use full machine snapshots to automatically create packages from existing installers.
Below is a screen shot from an early version of Thinstall (2.0).
The Thinstall/ThinApp virtualization solution has been used by a combination of end-users, independent software vendors, and corporate IT Administrators to deploy hundreds of millions of application instances around the world to every Intel based version since Windows 95.
ThinApp has come a long way since it's inception in 2001 and first VMware debut in 2008, Happy Birthday ThinApp!
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
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.