Using VMware’s ThinApp Trial Version to Virtualize Windows 7 Programs

As detailed in another post, I had made efforts to produce portable versions of a handful of Windows programs using Cameyo. There were some successes, among those programs, when I ran the Cameyo packages in Windows, but virtually no successes when I tried to run those packages in Linux using Wine. Separately, I was unsuccessful in an effort, using Cameyo, to produce a portable version of Microsoft Office 2003 that would run at all, even in Windows.

Note: another post updates this one in some important regards.

ThinApp Advantages and Alternatives

VMware’s ThinApp was listed second in popularity by AlternativeTo, after Cameyo. It was not clear whether this ranking was due to quality or just to price: Cameyo was free, whereas ThinApp was offered for $5,000 by one merchant and apparently more than that from VMware itself. (For that kind of expense, the buyer would get 50 client licenses.) ThinApp was reportedly no longer available as a standalone product. ThinApp claimed to be “extremely lightweight,” presumably implying that its packaged applications would perform nearly as quickly as if they were installed directly on the system.

While Cameyo claimed a fair degree of Linux compatibility, ThinApp did not. Its current Reviewer’s Guide (p. 6) listed only Windows versions among its supported platforms. Moreover, its White Paper said 64-bit applications were not supported. These documents made essentially no meaningful references to Linux. Even back in 2010 (when there seemed to be more corporate enthusiasm about the Linux desktop), someone claiming to be a VMware engineer implied that the direction was away from Linux compatibility — that packages produced by ThinApp versions up to 4.0.4 worked “OK” with Wine, but packages produced by later versions did not.

That was discouraging, for someone who was now trying to create Linux-compatible packages of Windows programs. But even if I was doomed to use certain Windows programs only in a Windows VM running on Linux, a portable version of those programs could still be useful: it could save the time and effort of reinstallation on any new Windows VMs and, as a related point, it could make those programs portable among different systems and across various media (e.g., USB drives); it could reduce the risk that software activation processes or other developments would eventually render a working program unusable; and it could facilitate the use of more than one version of the same program (e.g., Microsoft Office) without conflicts.

TechTarget (Laverick, 2010) explained how to use ThinApp to package a program, using Adobe Reader 9 as an example. The process seemed virtually identical to that of Cameyo: take a pre-installation snapshot on a clean machine; run the program’s installer; take a post-installation snapshot; and produce an editable package. It appeared that ThinApp might have some options that Cameyo lacked. I thought some of those options would probably be more useful in a multiuser corporate settings than in a standalone machine, and some could complicate the core mission of producing a virtualized program.

Another TechTarget article (Wood, 2013) offered a comparison of ThinApp against Citrix XenApp and Microsoft App-V. At this writing, Microsoft App-V was reportedly only available as part of the App-V for Desktops or App-V for RDS license. XenApp was available in a free 90-day trial but — in a sure sign of considerable expense — the webpage offering that freebie did not seem to link directly to a straightforward statement of product price; would-be buyers not interested in the trial version seemed to be compelled to call the sales department. After a bit of searching, though, I was able to find prices: $375 for Advanced edition, $485 for Enterprise edition, $645 for Platinum. The TechTarget article concluded that XenApp offered “difficult” licensing and running constraints and also “has a lot of management overhead,” presumably implying poor performance.

Docker appeared to be another much-talked-about virtualization option of sorts. The problem here was that the relevance of Docker to my present situation was not clear, and seemed to be somewhat disputed. I visited the Docker tutorials for Linux and Windows. Both led to nearly identical pages on images and containers. These did not clarify much, at my level of understanding, but they did introduce me to the Docker Image Library, which they also seemed to call Docker Hub. It offered a few dozen repositories. Linux distributions seemed to account for a good number of them. I didn’t see one for Microsoft. I looked at the one for Ubuntu. The idea appeared to be that you could get a Docker container to run Ubuntu on any system. I was happy to hear that news, but did not know if it would be relevant to my own purpose here.

Setting Up ThinApp

I downloaded the free trial, version 5.2, last updated Nov. 24, 2015, rated 4.3 stars out of 5 at Softpedia. Unlike Cameyo, this was an installed program. Having downloaded from Softpedia instead of VMware, I didn’t have a license key. But I had seen that offered about a dozen license keys, and that made me curious: were those real? Why would they work? A search suggested that virtually nobody else was offering those particular keys. Another search yielded no obvious red flags about AppNee. A Reddit discussion conveyed a few indications that AppNee might be safe.

I didn’t really need a permanent ThinApp installation on this VM. I was going to give it this one-time effort; I wanted to be spending my time with the genuine article; so I did not explore the AppNee option. Instead, I tried proceeding through the installer without entering a license key. That didn’t work. So I went back to VMware, downloaded from them, and got 60-day trial license keys for VMware ThinApp Client and ThinApp Virtualization Packager. Their page also gave me a third download, which they referred to as “Product installation including VMware Tools” but which, upon download, turned out to be VMware Workstation.

Next, I needed to know which operating system I should install ThinApp in. SysAdmin Tutorials used “a baseline or SOE desktop image of Windows 7,” where I guessed that SOE meant Standard Operating Environment. I thought I had read somewhere that ThinApp, like Cameyo, was actually at its best in a minimal Windows XP environment. But now that I looked, the primary advice from VMware was just to use a clean installation of the earliest operating system (OS) needed: Windows XP, if any users were using that. TechTarget (Laverick, 2010) noted that a 64-bit application would need to run in a 64-bit OS. Otherwise, though, VMAdmin advised using a 32-bit operating system “unless you have a very specific need for a 64-bit application and you know all the client’s that will use it are only 64-bit.” Having encountered difficulties with 64-bit software in other settings — most recently, in Wine — I assumed this advice was focused on using the kind of operating system that would be most likely to produce a successful ThinApp package. I concluded that it was reasonable to work in the minimal Windows XP VM that I had developed, except where the effort to virtualize 64-bit applications would require a minimal Windows 7 x64 VM.

Among the several files I had downloaded, I wasn’t sure where to begin with installation. SysAdmin Tutorials told me to start with the the Enterprise file, not the Workstation file. Mine was named VMware-ThinApp-Enterprise-5.2.0-3231342.exe. When the installer asked for my license key, I was not sure which number to enter. VMware’s download page had given me keys for ThinApp Client and ThinApp Virtualization Packager. As just indicated, neither of these was named “Enterprise.” SysAdmin Tutorials said that I should use the Packager license key. The other box on the screen was asking for “License Display Name.” VMAdmin said this name would be displayed every time a user ran the application that was about to be packaged. I wasn’t sure I wanted anything to be displayed. I tried leaving it blank, but it wouldn’t accept that. A space wouldn’t work, but a period would. After that, the installer completed quickly.

I did not want to have to go back through the ThinApp setup process, so at this point I shut down the VM and made a snapshot. That way, I would be able to revert to this clean machine for each program that I wanted to virtualize, without any of the clutter that might have been added by previous virtualization attempts. My VMs were stored on a solid state drive (SSD), giving me much better VM speed than if they had been on a hard disk drive (HDD).

Packaging Microsoft Office 2003

In my Windows XP Start menu, I now had a VMware folder containing icons for ThinApp Help, Log Monitor, and Setup Capture. I clicked on the last. That brought up a wizard, with explanations at each step along the way.

I had previously tried to virtualize Microsoft Office 2003 using Cameyo. Another post elaborates on my reasons for doing so and the difficulties I encountered. My full Office 2003 installation would be a convoluted affair. Thus I believed Office 2003 would provide a good test subject for ThinApp. So I brought a copy of the Office 2003 installation folder to the VM’s desktop, via the shared folder that I had configured in the VM’s settings.

VMware’s ThinApp User’s Guide said that, using the Advanced Scan Locations button in the “Setup Capture – Ready to Prescan” window, I could specify which drives and registry hives I wanted to scan. I took a look, but didn’t change anything. Cameyo offered a somewhat comparable capability, but it required editing a configuration file. It was much more convenient to be able to use this GUI to see that, unlike the situation in Cameyo, the VM’s shared folder was excluded by default.

So then it was time to install Office 2003 in the VM. As I say, the full installation would be convoluted. I wanted to start with just the basics. So I ran the setup program, taking the same steps as in the previous post. When the installer finished, I clicked ThinApp’s Postscan button. ThinApp then showed what it was scanning, and in a moment it concluded with what it described as “the list of executable files created when installing the application.” At that point, ThinApp said, my task was to “Select which [of those executable files] should be available as entry points.” The User’s Guide explained:

Entry points are the executable files that act as shortcuts into the virtual environment and start the virtual application. . . . For example, if you install Microsoft Office, you can select entry points for Microsoft Word, Microsoft Excel, and other applications that are installed during a Microsoft Office installation.

I clicked the Select None button, to uncheck everything in that long list, because I wouldn’t want Start menu icons for most of them. I just wanted entry points for the main Office programs — Excel, Word, etc., plus a few others (namely, Document Imaging and Scanning, and the Save My Settings Wizard). I guessed that this would not be editable once my 60-day ThinApp trial expired.

The next screen gave me an option to Manage with VMware Workstation. The description sounded pretty corporate — referring, for instance, to “enterprise SaaS” — so I took a PaaS on that. Having run into a weird problem with Cameyo across different operating systems where the wrong user (me) was trying to use a package created by another user (me, as Administrator), I made sure to select the option to authorize Everyone to run this package.

Now I was looking at the Setup Capture – Isolation screen. To get a good handle on what this screen was asking me, I consulted a VMware knowledgebase document. It seemed to be describing a somewhat different ThinApp version, where there was a Full isolation mode. All I saw onscreen was the Merged and WriteCopy modes. About those, the document said this:

Isolation modes allow you to control the degree to which a virtualized application can read from and write to the local, physical PC where the virtual application resides. . . .

Merged isolation of the virtual application means that the user can read from and write to the physical system. WriteCopy isolation mode means that the user can read from the physical system, but cannot write to the physical system. Instead, the user writes to a copy of the physical system in the Sandbox. . . .

The Sandbox . . . [provides] a place to write user application data if the isolation mode forbids writing to the physical system.

Well, of course I wanted Microsoft Office to be able to interact with files on my computer. It seemed that Merged isolation — what the ThinApp screen also described as “Full write access to non-system directories” — was the choice for me, and that was the default choice anyway.

Next, ThinApp was asking me about the Sandbox. Again, the User’s Guide did not seem to be saying exactly what that knowledgebase document had said. A University of Utah page clarified that the Sandbox was a place where personalized user settings were saved. So when the foregoing block quote described the Sandbox as a place for “user application data,” apparently it meant data about the program in question, such as spellchecker settings in Microsoft Word — not data generated by the application (e.g., revisions to a Word document).

This was still not too clear. A search led to (1 2) posts demonstrating that, actually, it was even more complicated than I had realized. Another VMware document said this:

If the application is isolated from the host system, any changes, deletions, or additions made by the application to the file system or registry are recorded in the sandbox instead of to the host operating system. . . .

[Merged] isolation mode causes all modifications made by the application to be made to the host operating system. . . . [WriteCopy] isolation mode causes all modifications made by the application to be made to the application’s sandbox.

Those words did seem to confirm that we were talking about changes to the Windows file system and/or registry, not to data files. In that case, I would want changes to be saved within the virtualized package, not written to the host operating system. For example, I might run two different virtualized versions of Microsoft Office in the same VM. I would not want their settings to confuse each other. Let them save their settings, instead, to their own internal sandboxes — and hope that the sandboxes were large or expandable enough to keep capturing and storing changes as I continued to use the virtualized packages. The User’s Guide said,

The sandbox is the directory where all changes that the captured application makes are stored. The sandbox is runtime modification storage and is not a cache. The next time you open the application, those changes are incorporated from the sandbox.

When you delete the sandbox directory, the application reverts to its captured state. You might delete a sandbox when an application has a problem and you want to revert the application back to the working original state.

With this understanding, I went back to the preceding screen and changed my choice. I wanted WriteCopy mode. Then, in the following screen, when it asked for the Sandbox location, I chose “Same directory as the application (use with USB and portable media),” because I wanted changes in configuration to travel along with the virtualized program.

Finally, ThinApp indicated that, by default, it would be putting the finished package into C:\Program Files\VMware\VMware ThinApp\Captures\Microsoft Office Professional Edition 2003. That folder did not exist yet, but it soon would. But first, ThinApp wanted me to make some more decisions:

  • Primary data container. Here, again, the User’s Guide was unclear. The VMware ThinApp Blog (Flaming, 2010) encouraged users to keep their executable (.exe) files small because of (a) Windows limits on .exe file system sizes (above) and (b) slower loading of larger .exe files. A small executable would be especially important on a VM with limited RAM. So for an application that was not small, the correct answer here would be the default option: “Use separate .DAT file.”
  • MSI package generation. According to the User’s Guide,

You can capture an application and deploy it as an MSI Windows installation package. . . . MSI generation requires you to install the MSI on the target device before you can use the application package. MSI packages automate the process of registering file-type associations, registering desktop and Start menu shortcuts, and displaying control panel extensions.

I was not planning to install my virtualized programs. Indeed, I was using ThinApp partly to avoid having to install programs. Moreover, I was hoping they might run on Linux, where the idea of a Windows installation would make no sense. Here, again, I went with the default, which was to leave the MSI box unchecked.

  • Compression. ThinApp said, “VMware does not recommend compression for test builds because it increases the build time.” Fine, but what about final builds? The User’s Guide said, “Compression can reduce the on-disk storage requirement by 50 percent but slows the application performance when ThinApp uncompresses initial blocks that start the application.” I did not know whether compression would also reduce the chances that Wine could run a ThinApp package on Linux. I decided to go with the default (no compression) on this test run. I thought the decision with final builds might be taken on a case-by-case basis: compress large packages that I would not be running often, don’t compress smaller packages that I would be opening and closing more frequently.

That was it. I clicked Save. ThinApp began saving its project files. This only took a minute or so. Then I had another screen: Setup Capture – Ready to Build. I had options to Edit Package.ini or Open Project Folder. I knew of no reason to do either, so I clicked Build. That, too, ran for only a minute or so, and then I was looking at Setup Capture – Build Project. It offered a default checkbox: “Open folder containing project executables after clicking Finish.” That sounded like a good idea. But in the output, I also saw this:

WARNING: The package you just created will expire on 2016-08-12.

That would be the end of my 60-day trial period. In other words, this was only a trial build. Evidently it was going to self-destruct in two months. I had been hoping that wouldn’t be the case.

I clicked Finish. That did open a Windows Explorer session at C:\Program Files\VMware\VMware ThinApp\Captures\Microsoft Office Professional Edition 2003\bin. This appeared to be a subfolder within the ThinApp installation in the VM. In that bin folder, I saw a list of very small .exe files, most less than 500KB, comprising the entry points for Excel and Word and the rest. I also saw the large 924MB .dat file for Microsoft Office Professional Edition 2003. It looked like the process had run well and had completed successfully.

Testing the Office 2003 Package

I put a copy of that bin folder on the VM’s desktop and renamed it as Microsoft Office Professional 2003 (ThinApp).

The Cameyo attempt had died at this point: there seemed to be no solution to certain error messages that arose every time I tried to run the Cameyo package of Office 2003. So I wanted to see whether this ThinApp package would run at all and, if it did, whether it would run when it was in this desktop location, which was not where ThinApp had put it.

I began with the Excel.exe file in that desktop folder. It started with a little message in the lower right-hand corner of the VM window: “Licensed to .” So that explained what would happen with the period that I had entered in the License Display Name field during setup. That little message disappeared after a second or two, and I saw no other mention of it while running Excel.

Excel opened right up, without any error messages. I played with it a bit. It seemed to be doing calculations correctly. I went into its Tools > Options > General tab > check all boxes. I shut down Excel and tried Word. It worked without problems too. I went into its Tools > Autocorrect and added a new dictionary entry: “ti” becomes “there is.” Out in the blank document, that change worked. I exited Word.

I just opened and closed several of the other entry points: Access, Outlook, PowerPoint, Publisher. They all opened without problems. So this made clear that the package would run even if it was not located in the bin folder on the VM’s drive C. Moreover, it was clear that ThinApp had reached first base with Microsoft Office 2003, where Cameyo just didn’t: this package actually worked.

I rebooted the VM and tested whether those changes that I had made in the settings for Excel and Word had survived the restart. They had. For convenience, I would probably want to make as many desired configuration changes as possible before finishing the ThinApp package, but it seemed that would not be essential: I could still make such changes afterwards, and apparently they would be saved in the package’s sandbox.

I renamed that Office 2003 ThinApp folder to be Office 2003 (ThinApp) Tweaked, and then I copied it from the VM to the shared folder, where it would be accessible to Linux and to other VMs. I closed the WinXP VM, made a snapshot of it, and started a Windows 7 x64 VM. In that VM, I ran the Excel and Word entry points, within the Tweaked folder that I had copied to the computer’s shared folder. Excel and Word started up. The changes that I had just made to them, in the WinXP VM, were still there. Everything seemed to work. So a Win7 x64 VM could run that package created in WinXP.

I closed that Win7 VM and went to the underlying Linux Mint system. I had already installed Wine there. In the Linux file manager, I right-clicked on the Excel entry point in the shared folder and told it to open that program in Wine. It did not open. I tried again. Same result. I tried Word as well. No joy. Given the seeming lack of Linux support in ThinApp, I did not think the outcome would have been different if I had made one .exe package instead of having a separate .dat file, but that was a possibility.

It seemed that ThinApp could succeed with at least one Windows program — Microsoft Office 2003 — where Cameyo had failed. It probably would succeed with others as well. So those were arguments in favor of ThinApp. On the other hand, Cameyo had succeeded with some programs and, most importantly, the ThinApp package was not running in Linux.

There were still some conveniences in having various Windows programs in ready-to-run portable form. I decided to explore my options a bit further.

About ThinApp’s 60-Day Deadline

ThinApp had notified me (above) that my Microsoft Office package would expire on August 12, 2016. I assumed the ThinApp installation itself would also expire on that date.

It seemed there might be workarounds. For example, it seemed a person might be able to set the VM’s clock back 15 years, and then have a 15-year trial period until August 12, 2016 finally rolled around. Another approach would be to set the system clock ahead several years, install the trial software, and then reset the system to the correct time.

In VirtualBox, unlike a native Windows installation, it appeared that any sort of time tampering would be immediately corrected by the VM’s time synchronization with the host computer. According to the VirtualBox User Manual, it would be necessary to enter this command to disable the VM’s time synchronization:

VBoxManage setextradata "VM name" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1

To test that, I closed VirtualBox and (since I was using VirtualBox in Linux rather than in Windows) ran the foregoing command, substituting the name of the VM. Then I reopened the WinXP VM and tried resetting the date back to January 2016. That date survived a reboot. So that command worked. I found that the Word and Excel entry points still ran, even though that date was prior to their actual creation date.

Such efforts would not be necessary if VMware did not actually shut down this ThinApp trial after 60 days. To test that, I turned the VM’s time forward, past my expiration date, to August 13, 2016. Then I tried running Excel. This time, I got a message:

License problem

Your runtime license has expired

So that resolved that question. There was an actual 60-day expiration. Now that it had expired, I wondered what would happen if I changed the clock back again. With the clock set to January 2016, I tried again with Excel. It was fine. So was Word. It seemed that expiration of the 60-day trial period did not somehow corrupt or permanently damage the ThinApp package. And that made sense. VMware would presumably want people to be able to use their previously created ThinApp packages, once they had paid their $5,000 licensing fee. I did not investigate this further, but I noticed that VMware apparently provided a ReLink tool to help with this.

So the scenario here was, perhaps, that a person would keep a zipped backup of the ThinApp package, and only run it on a VMs whose clocks was incorrect and which, perhaps, was not connected to the Internet and would thus not be at risk of any automatic date correction. Or perhaps the person could just let the 60 days run out and then roll back the VM to a prior snapshot, as Microsoft advised doing with its 90-day trial offerings of certain versions of Windows:

Screenshot from 2016-06-13

Searches (1 2) led to other tools and techniques for keeping ThinApp available after the 60-day trial period. Some sounded easier than what I had just explored:

  • System date tools and tweaks. One discussion named several. Among those, the free RunAsDate was designed to run a program in a specified date and time, although apparently it didn’t work for some programs. Time Stopper was another free utility intended to “eliminate the time limit” in trial software. I was not sure whether such utilities would count as running processes that might somehow interfere with ThinApp’s snapshot processes.
  • System restore tools. There seemed to be a number of ways to restore the computer or VM to its condition just before the trial software was installed or used, so that changes to the system or its registry made by the trial software would be erased, and the user could reinstall it and start over. Of course, restoring a drive image or VM snapshot would achieve the same thing, but some of these tools could be made to reset only the trial software, leaving other system changes in place. For example, Revo Uninstaller and Comodo Programs Manager would watch what was installed by the trial software, and would then know everything that needed to be uninstalled, in order to eliminate all traces of the trial program. Deep Freeze would add a snapshot-like capability to a physical Windows installation, such that a simple reboot could restore a system to its condition just before the first use of the trial software. Trial-Reset and Registry Trash Keys Finder would detect and remove use-tracking entries from the registry.
  • ThinApp tweaks. Ironically, Ganja said that ThinApp could be used to defeat trial periods on other software. Apparently there was what another source called a “time and date spoofing feature” in ThinApp. This, too, would only work if the software did not synchronize its time with the Internet. Someone else said, “If you want to reset a Thinapp application, you simply delete the folder with the applications sandbox, where all changes(registry, files etc.) to the application is stored.” Finally, one source presented a solution that I did not understand.

Compared to the limitations built into some trial software, the ThinApp date-based protection seemed relatively primitive. It appeared that there were some fairly easy responses to the ThinApp protection: use a tool to uninstall it and/or to revert the system when the trial period expired, for example, or use it in a VM not connected to the Internet.

I wondered how VMware felt about these sorts of activities. I did not think VMware believed that individual users were going to pay $5,000 to create portable versions of a handful of their programs. Plainly, the software was for sale mostly to corporate buyers with many employees who would be using ThinApp for major and/or frequent tasks. A VMware ThinApp Blog post (Flaming, 2009) said that the types of customers using ThinApp were generally industries, not consumers: healthcare, for instance, and financial services, and manufacturing. As an example of this sort of customer, a VMware document described how The Bank of Tokyo-Mitsubishi UJF, Ltd. switched 50,000 PCs to a virtual desktop environment based partly on ThinApp.

VMware was certainly not keeping the trial software locked down and available only to those who could actually afford it. There was no requirement that the would-be user contact the VMware sales department or demonstrate any corporate affiliation. To the contrary, the ThinApp trial was available for free mass download from Softpedia and others.

It appeared that VMware wanted to keep on making those $5,000 sales, and to do that it wanted to encourage widespread familiarity with the product. It seemed that the company might be doing whatever it could do to promote large volume sales, and might be simply ignoring the small fry.

The point would not be that VMware would celebrate those private users who figured out how to defeat its ThinApp trial period. The point would be, rather, that VMware might not mind that sort of thing, as long as those relatively skilled users would come to see how good ThinApp was, and would proceed to talk about it, write about it, and encourage adoption of ThinApp at their places of employment. This seemed consistent with VMware’s offer of a free trial copy of Workstation (above), when I had not requested that: they were reserving their rights, but they were also pushing their software into the mass market.

This reading seemed to explain the odd phenomenon of making a $5,000 program available for random individuals to download and use, with fairly weak efforts to prevent them from continuing to use it. Instead of taking this approach, a sensible person might think that VMware would want to sell tens of thousands of copies of this seemingly good software to consumers at an appropriate price. Then again, signs of executive chaos at VMware could suggest that sensible people were not in the decision loop. The situation brought to mind (1 2) other instances where companies incompetently (or, in some cases, deliberately) suppressed good software and innovation.

Cameyo and ThinApp Together?

Regardless of the situation with the ThinApp trial period, I still had my fundamental problem. I was seeking a ThinApp package that would run on Linux. And that was not going to happen, because as far as I could tell, ThinApp packages did not run on Linux. Neither did Cameyo packages, not yet and/or not for me, anyway, but at least Cameyo claimed that they did, or would.

This raised the question of whether I could combine the two virtualizers to produce an Office 2003 package that would run on Linux. The scenario would be that I would repeat what I had just done — use ThinApp to capture the Office 2003 installation — while simultaneously using Cameyo to capture what ThinApp was doing. Ideally, this would give me a Cameyo package that would contain and run what was in the ThinApp package. I didn’t know whether that would resolve the issues of getting it to run on Linux and avoiding the ThinApp 60-day expiration.

To try that combined approach, I rolled the VM back to the snapshot I had taken after installing ThinApp. I didn’t need Cameyo to capture that installation, just what came after. I verified, in Add or Remove Programs, that only VirtualBox Guest Additions and ThinApp were installed on this VM. I brought a copy of the Office 2003 installation folder to the VM’s desktop, along with a copy of Cameyo.exe. I started Cameyo and also ThinApp.

Now, the question was, in what sequence should I do this? It seemed that I should let Cameyo take its initial snapshot first, so that it would capture everything that ThinApp did. The hope here was that ThinApp wouldn’t keep a lot of extra junk — that whatever it figured out about the Office 2003 installation would be distilled into its resulting package of that program. So I let Cameyo take its snapshot; then I let ThinApp do its Prescan phase; then I installed Office 2003 as above; then it was time for ThinApp’s Postscan and Build phases; and finally, when ThinApp was done and closed down, I let Cameyo take its post-installation snapshot.

Cameyo informed me that it had successfully built its package. But the package was huge: 2GB, which was even larger than in previous attempts described in the other post. That wasn’t going to run well on a machine with 1GB of RAM. It tried, but died in a hail of errors. I could conceivably have edited it and tried to make it work. But I was discouraged. The contrasts between ThinApp and Cameyo were just too great.


This little exploration yielded the impression that ThinApp was a well-put-together package that produced relatively lean, working virtualizations of programs that Cameyo could not effectively virtualize. For my purposes, it was unfortunate that ThinApp did not seem to be at all Linux-compatible. For the ordinary person, in any case, ThinApp was essentially unavailable. One could only hope that the good people at Cameyo, or perhaps someone else, would find a way to run these lean ThinApp packages, in Windows and also in Linux, without time restriction.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s