VMware Communities : All Content - All Communities

VMware ThinApp Podcasts

Corey_R — Thu, 30 Apr 2009 20:31:38 GMT

1. ThinApp for VI admins - Communities Roundtable
2. Technical Track: Virtualize Your Applications with VMware ThinApp

New Schedule

IamTHEvilONE — Wed, 21 Jan 2009 14:19:02 GMT

I'm going to see if I can attend the February 3th webex

New ThinApp Blog

Opunui25 — Thu, 09 Oct 2008 15:51:20 GMT

Fixed. Thanks.

Travis Sales
travis@vmware.com
VMware, Inc. | SE Specialist, Enterprise Desktop Solutions

Thinstall Lounge Ideas!

mohankc — Wed, 16 Jul 2008 14:37:27 GMT

ThinAPP best practicies in an enterprise environment

Performance impact on Terminal servers due to running virtual apps. I know that from a conceptual standpoint you shouldn't notice any significant difference. But what I am interested to know is that built-in memory management features are we sacrificing by running apps in a virtual environment.

AppSync Request

Opunui25 — Thu, 01 May 2008 18:04:09 GMT

HOST O/S: All

GUEST O/S: All

SEVERITY: High

BRIEF SUMMARY: AppSync needs an option make Updates Mandatory or Optional.

DETAILED DESCRIPTION:

When you use AppSync, the application forces the user to update if a new .exe is available. Considering the size of some updates and the need for users to use the app, I suggest that there be an additional Package.ini entry top allow an admin to select if the update is Mandatory or Optional. If Mandatory, the update would apply and the user would have no choice. But if set to Optional, a dialog would pop-up asking the user if he wanted to download the update now or upon next launch.

ADDITIONAL COMMENTS:

Travis Sales
travis@vmware.com
VMware, Inc. | SE Specialist, Enterprise Desktop Solutions

Creating Links to Non-Exe objects using Thinreg.exe

Opunui25 — Thu, 01 May 2008 15:24:28 GMT

This may not be the most elegant solution and the product team is aware of this but in the meantime, here a solution that you can use if needed.

1. You will need to download the ShellExecute.exe
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.

Using mutilple versions of Thinstall to build with.

Opunui25 — Tue, 29 Apr 2008 22:10:23 GMT

This is a quick guide on how to quickly switch between different version of Thinstall. You may find it necessary to keep multiple versions of the Thinstall software available to test with your applications. As such, the following directions will assist you in what is required to allow you to use multiple copies of Thinstall to build your .exe's with.

Every Thinstall project has a build.bat which, when run, will look for the Thinstall build utilities using the following search order:

Look at the environment variable THINSTALL_BIN
Depending on the version you downloaded
- Look at
  - c:\Program files\Thinstall.VS
  - c:\program files\VMWare\Northstar

Collecting the Thinstall Build Utilities

The Thinstall build utilities are the files vregtool.exe, vftool.exe, and tlink.exe. These files require SetupCapture.exe to be located in the same directory in order to run. All of these files will be installed by the original .msi installer to c:\program files. You can save a copy of c:\program files\Thinstall.VS to something like c:\thinstall_version_3.335 (or a directory of your choice). Over time, you can build a library of versions to test with by storing off the contents in a separate directory after installing.

Change the Environment Variable

All that is required to cause build.bat to use a different version is to change the environment variable THINSTALL_BIN

For example:

c:\myproject>

set THINSTALL_BIN= c:\thinstall_version_3.335

c:\myproject> build.bat

Thinstall Lounge Tip of the Week #1

Opunui25 — Tue, 29 Apr 2008 21:59:46 GMT

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.

Running explorer.exe on Windows 2003

Opunui25 — Mon, 31 Mar 2008 22:54:35 GMT

As most of you are aware, in order to run explorer.exe on a Windows 2000 or XP system, you have to make a registry entry in order to have a virtual explorer window open. With the latest version of Thinstall, that is no longer a problem (I tested with 3.350). However, if you try to do this with a Windows 2003 Server, you will get an error just prior to the window opening. It will say, "failed to create process default activation context". To work around this problem, just copy the explorer.exe to your %SystemRoot% folder. There you go.

PS: Be sure to set your folder options under Windows to "Launch folder windows in a seperate process".

Calling all Scripts!!!

BEEW — Thu, 13 Mar 2008 21:30:51 GMT

Put the date you want the application to expire at, in the VBS and place the VBS in the same dir the package.ini is in. Next step is to build the application.

Every time the Thinstalled application runs, the VBS is being started and the system date compaired to the date in the script. When the application has expired the user sees a messagebox and no application.

MSI Generation

Opunui25 — Wed, 12 Mar 2008 17:32:08 GMT

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 are 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.

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.
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.

Thinstall Lounge

Opunui25 — Wed, 12 Mar 2008 12:34:26 GMT

We cover topics of the week which are kind of like mini-training sessions. Outside of that, folks can ask anything they want, just like the forums.

Travis Sales
travis@vmware.com
VMware, Inc. | SE Specialist, Enterprise Desktop Solutions

Thinstall and WINE

Opunui25 — Wed, 27 Feb 2008 02:24:54 GMT

-----This is the Original Blog post by Jonathan Clark-----

For people who see Thinstall for the first time, it seems like magic and they wonder how it works. But Thinstall isn't new - most of the concepts for Thinstall are a decade old and have been implemented by various open source projects such as Wine and UML. Thinstall was first released in 2001 but wine was available many years before this and can rightfully claim many "first" boasting rights.

Wine (Wine is not an emulator, well actually it is....)

Although Thinstall and Wine do not share any code internally and they are targeting different operating systems the underlying designs have many similarities. Both systems use a combinations of API translation and API emulation to achieve their goals.

Thinstall's primary goal is to allow Windows applications to run on the Windows operating system without installation and with limited changes to the host PC. The primary goal of Wine is to allow Windows applications to run on unix operating systems.

Wine works by emulating vast portions of the Win32 layer and translating Win32 API calls such as CreateFile (Windows) into open (Linux). When a call to CreateFile is made by the applicaion, part of the translation process is to convert paths from Windows format into unix format. For example, Windows has the concept of drive letters which unix does not have so the path "c:\windows\win.ini" is converted into something like "/home/username/.wine/drive_c/Windows/win.ini". Applications running on top of the Wine emulation layer are accessing a virtualized file system that mirrors what they would expect on a real windows system. If the application tries to create new files or modifies data in the virtualized file system, the host PC is unaffected outside of changes to the directory "/home/username/.wine". In this fashion, wine serves as a "protection layer" that prevents the application from modifying the real host file system. A wine virtual environment can be completely removedfrom the host PC by recursively deleting /home/username/.wine.

Wine runs in user mode so it relies on the security policies of the host machine to prevent the emulated application from doing dangerous operations. For example, even if there are bugs in wine the applications would not be able to access other user's files, format the hard drive, or execute privileged instructions.

Windows has a number of concepts that are not present on Unix systems, for example a registry. In order to allow windows applications to run on unix systems, Wine emulates a fake ("virtualized" in today's marketing lingo) registry. Wine's registry emulation loads registry values into memory from a disk file on startup and periodically saves any changes made back to the disk file. WineHQ keeps source code revisions back to 1999 so you can go back and browse Wine's early virtual registry code.

When an application is installed into a wine's virtual environment, all of it's modifications are stored under a single data directory (default is /home/username/.wine).

Wine can be configured to use multiple different "virtual" environments on startup using an environment variable called WINEPREFIX. This enables applications to be fully separated from each other and registry or file system modifications from one application cannot effect other applications.

Wine's data directory also serves as a "snapshot" of the installed state of an individual application. For example, after installing Microsoft Office inside of a virtual environment, the persistent state of the application can be copied to other machines or users and run directly without installation.

Wine was originally designed for Linux but was quickly ported to FreeBSD and today supports many other operating systems. While it never came to fruition, cygwin and Wine developers have contemplated porting wine to the Windows operating system using cygwin.

How Thinstall works

Design-wise, Thinstall has many similarities wtih Wine. Thinstall emulates and translates the Win32 API on a more selective basis to achieve its stated goals. With Thinstall the vast majority of the Win32 API passes directly to Windows with no emulation or translation. For example, when an application calls BitBlt, a function used to draw a bitmap to the screen, the call passes directly to Windows. Because Thinstall only replaces about 600 of the 10,000+ or so Win32 APIs it can achieve much higher levels of compatibility than are possible with Wine and generally it automatically supports newer operating systems and kernel updates. Because Thinstall is already running on top of Windows, we can use the existing operating system where possible rather than needing to reimplement everything.

For API functions that have the ability to make persistent machine changes or affect other running applications, the APIs are either emulated or translated. For an example of how translation is used, when an application tries to write to the file "c:\windows\win.ini" using the CreateFile API Thinstall will translate this call into CreateFile "c:\documents and settings\username\application data\thinstall\appname\%SystemRoot%\win.ini". In this case, most of the functionality for a file system is being provided by Windows. Thinstall also provides a fully functional read-only compressed filesystem and registry that is embedded with an application and can search multiple locations for a file. The read-only file system is probed first, then the "sandbox", and then the real file system. Various isolation rules can be used to control what parts of each of these 3 systems are visible and writable.

Thinstall also uses emulation to achieve it's goals, for example it completely emulates the Windows Loader, Windows registry, Services, COM/DCOM, and about 30 other subsystems, rather than passing API calls on to Windows. When an application tries to write to the registry using RegSetValue Thinstall emulates the behavior of the Windows registry and writes the updated registry data to a disk file under %AppData%\Thinstall\registry.rw.tvr.

Like wine, Thinstall can support multiple data directories so that applications can be separated from each other and the changes made by one application do not affect another application. In Thinstall, the default model is to give each application it's own private data directory. In Wine, the default model is to use one virtual environment for all Windows application. Also like wine, this data directory can be copied to other machines or users and used as "snapshot" and thus eliminating some or all installation steps normally needed to use the application. Thinstall takes this a bit further by implementing a compressed read-only file system that can be directly embedded in the original EXE file so distributions can occur via a single file.

Thinstall uses another concept called Copy on Write (COW) which is not present in Wine. COW has been a key concept in operating system design and CPU design over the years.

Thinstall uses COW to allow read-only access to parts of the file system and registry such that any operations that would cause modifications will copy the data to a private sandbox area where modifications occur without affecting the rest of the PC. The first implementations for COW occurred in microprocessor and OS design in the 1980's and soon after it was adopted by virtualization/emulation solutions such as Bochs, QEMU, and UML for virtual disk storage. As well, numerous older file systems implemented the concept of snapshots and COW at the file granularity level. For example, WAFL, fossil for Plan 9 from Bell Labs, and ODS-5 would track older versions of files and make snapshots available through a special name space.

Thinstall's Sandbox merge utility allows you to take runtime changes that occured via COW and merge them back into a single EXE for easier redistribute to end-users.

Summary

Thinstall and wine share a lot of common design ancestry that goes back more than a decade. This design commonality evolved naturally and independently because both projects were targeting the same standard which was defined by Microsoft - otherwise known as the Win32 API. Thinstall and wine are not unique in targeting this platform, IBM's OS/2, ReactOS, Windows 9X, and Windows NT also implement the Win32 API as a standard.

Build.bat for North Star

Opunui25 — Tue, 26 Feb 2008 20:48:37 GMT