This post primarily deals with the use of Cameyo to produce portable (sometimes called “virtualized”) versions of Windows programs for use in Linux. A companion post discusses the use of VMware ThinApp for similar purposes. Another post updates some of the information provided below.
Portable Apps in Windows and Linux
Virtualization and Virtualized Software
Others’ Experiences with Cameyo
Preparing a System for Use with Cameyo
Using Cameyo to Virtualize Olympus Digital Wave Player
Using Cameyo to Virtualize IrfanView
Trying Cameyo with Other Programs:
- Adobe Acrobat 9 Pro
- Adobe Premiere Elements 12
- Adobe Reader
- Cool Edit 2000
- Cyberlink PowerDirector Ultimate 12
- Microsoft Office 2010
Portable Apps in Windows and Linux
In Windows, a portable program would not have to be installed. The user could just click on its icon, and it would run.
Portable apps had several advantages in Windows:
- They didn’t have to be reinstalled, on the existing system or on a new one. The user could just copy over the file or folder containing the portable app, and it would run the same on a new or restored system.
- Their current settings didn’t get lost if the system crashed or if drive C had to be restored. With the non-portable version of Google Chrome, for instance, the tabs I had opened would be gone if I did a System Restore, or restored my Windows system from a backup image. With a portable program running from another drive, that would not be the case. (In Windows, I used a customized Start menu, located on another drive, and I put my portable programs there.)
- Portable programs did not have to be uninstalled. They were not tied into the operating system. They could be directly zipped, relocated, or deleted without any impact on the Windows operating system.
- Portable programs could be carried around on USB thumb drives, and some could be used on computers at the library or workplace, even without the adminstrator permission needed to install programs.
- Some users found it convenient to bring together large numbers of portable programs in one place, and carry them around on USB drives like digital Swiss Army knives (e.g., LiberKey, winPenPack, Lupo PenSuite).
Generally, Windows programs would not run in Linux, unless they had a Linux version. But some Windows programs could be persuaded to run in Linux. Making that happen would typically require use of the Linux program known as Wine. In the worst cases, the Wine process could be complicated and/or the Windows program would not run.
I was interested in this because I was transitioning from Windows to Linux. As described in another post, I had assembled a list of my favorite Windows programs, and I was searching for Linux programs that would do the same things. Where I couldn’t find a good Linux counterpart, I was using Wine.
My experience so far suggested that, at least in some cases, the Wine process could be much easier with a portable program. Instead of working through the many things that could go wrong while attempting the Windows program installation process on the alien Linux operating system, I had seen that some Windows portable programs would run almost immediately: just right-click on them in the Linux file manager and select Open with Wine.
Aside from the Swiss Army knife type of tool mentioned above, there were lists and websites offering collections of portable Windows programs. The best-known was PortableApps.com, boasting more than 300 titles. Users could download individual apps or, like those USB tools, could have them installed and updated automatically through the PortableApps.com Platform. I was not interested in exploring mountains of programs, however. I was looking for a few specific items on my list of Windows favorites.
Virtualization and Virtualized Software
In some cases, the program I was looking for was not on any of those lists. That would most often be because the program was not freely shared, but rather had to be purchased and came with installation codes and/or licensing provisions limiting their use to the purchaser. For example, a search suggested that there might be potentially illegal portable versions of Microsoft Office floating around, but Microsoft itself did not offer any such product.
In those cases, there was no option of simply downloading the program in portable form. To get a portable form that might work in Linux, I would have to create it myself. That was a possibility. To do that, I would use an application virtualization program. Among the many listed in a previous post, it appeared that the best free virtualizer might be Cameyo, with Evalaze and Enigma Virtual Box as alternatives. Probably the best-known commercial alternative was VMware’s ThinApp, listed at $5,000 by one merchant but otherwise reportedly no longer available as a standalone product (see VMware). The current version of Cameyo did offer Linux Wine support, with caveats.
Another post has the full list of Windows programs that I was hoping to run in Linux. I had already found Linux counterparts or alternatives for most of those programs. There were only a few programs left that I still hadn’t figured out how to run on Linux. Those programs were as follows:
- Adobe Acrobat
- Adobe Premiere Elements
- Adobe Reader
- Cool Edit 2000
- Microsoft Office
- Olympus Digital Wave Player
I had already looked at the PortableApps list. They had none of these items. Now I saw that Cameyo, too, offered a list of public (i.e., typically free) programs, as well as a somewhat outdated list of virtualized apps. For each such item, Cameyo provided a “virtualization score.” I did not find a convenient explanation of what this was. It appeared to be just the percentage of users who clicked Like rather than Dislike. The existence of scores in or below the 80% range suggested a fair amount of user dissatisfaction. But there was no way of knowing whether users were registering dissatisfaction with Cameyo’s virtualization of the program or, rather, with the functionality of the program itself.
The only other item on my list for which Softpedia offered a portable version was Recuva. That version ran in Windows, but not in Linux; the latter folded with a message: “The application Recuva has quit unexpectedly.” Again, I wasn’t sure my efforts to create a portable version would fare any better. But for Recuva and the other remaining programs on my list, it seemed I needed to go ahead with Cameyo.
Others’ Experiences with Cameyo
My first step was to see what others had tried, and what results they had achieved, when attempting to use Cameyo to virtualize the programs on my list. Here’s what I found:
Adobe Acrobat and Premiere Elements. A search yielded only a few plainly relevant hits. In one, on what appeared to be a Cameyo forum, a couple of users asked about problems they were having with packaging Acrobat. Nobody responded. In another, also on that forum, a Cameyo support person did reply, but seemed to confuse the question: s/he provided a link to a download of Adobe Reader (not Acrobat). When I tried that link, my AVG Antivirus reported that this download contained a Trojan Horse virus. It was possible that this was a false positive (i.e., no actual virus). At any rate, it seemed that I was pretty much on my own: I would have to cook up my own Cameyo versions of these programs, and would have to figure out how to do it.
Adobe Reader. See below.
Cool Edit 2000. A search turned up no obviously relevant results.
Microsoft Office. Although my scans and searches of Cameyo’s App Library and list of public apps (above) turned up no results, a Google search led to a Cameyo webpage offering a download of Microsoft Office version 12.0.4518. That appeared to mean Office 2007. Cameyo’s page reported that the download (730MB) had a virtualization score of only 66%. AVG Antivirus reported that this download contained two Trojan Horse viruses (but, again, those may have been false positives). In a different effort, a forum participant reported failure with both Office 2007 and Office 2010, to which a Cameyo support person replied with a question (which Cameyo people had also asked others): did you build your package in a clean machine? The support person also said,
Unfortunately, there is a known issue in getting a package of Office 2010 to work. There should be no problem in building it if you are using a clean VM, but I’ve had to resort to an unvirtualized installation of a deployment kit to get the package to function.
That didn’t sound like something that would be simple to match in Linux. In another forum exchange, a Cameyo support person said that “virtualizing Microsoft Office 2013 is not supported at this time.” One of the participants reporting success with Office 2003 in another forum sagely remarked, “Cameyo is very effective, but its effectiveness is proportional to the complexity of the software you want to package.” My own previous exploration suggested that the complexity might be reduced by proceeding one at a time with Microsoft Office programs (e.g., Excel, Word), and perhaps not including updates.
In a different vein, a video presented the use of Microsoft’s App-V to virtualize various editions of Microsoft Office. Microsoft Technet explained that App-V was part of the Microsoft Desktop Optimization Pack. Based on Microsoft’s Desktop Virtualization page, App-V appeared to be part of the Enterprise Mobility Suite. But Brian Madden had recently reported that App-V was going to be built into the summer 2016 update of Windows 10. So that was a possibility for the future, though I somewhat doubted it would ultimately be designed in a way that would help people run old copies of Microsoft Office in Linux.
Olympus Digital Wave Player. A search turned up no obviously relevant results.
Recuva. A search led to no obviously relevant results.
Preparing a System for Use with Cameyo
By this point, I had encountered a number of sites offering advice on the proper use of Cameyo. I began with Cameyo’s own User Guide.
The first step, according to the User Guide, was to prepare a clean virtual machine. For some reason, the User Guide did not explain this in detail, nor refer the user to Cameyo’s own Resources page on this point. The reader could fairly infer, as I did, that Cameyo was not going to explain that. I found this inference was mistaken only when I ran a search and began reading through a How-To Geek explanation. That pointed back to Cameyo’s Virtual Application Packaging Best-Practice Guide (BPG). The BPG said this:
Prepare a clean, basic virtual machine. Make sure no unnecessary programs run on it. Turn off all possible updates, including Windows Updates or anti-virus updates. Avoid using other programs on your machine. In general, anything that can modify files or registry keys, will interfere with the packaging process.
For simple applications, the BPG added this: “We recommend using [Windows] XP SP3 32-bit, unless your software requires some higher systems to install & function.” The BPG thus seemed to imply that, for Cameyo, any software requiring 64-bit or post-XP Windows would automatically qualify as complex. It seemed that reliably capturing Windows 7+ and/or 64-bit installations would often require a major virtualizing tool like VMware ThinApp or something (e.g., App-V) from Microsoft itself. Regardless, I felt that the BPG’s next advice applied to any such operation, not just the complex ones: take a snapshot of that clean VM, so you don’t have to recreate it if you need to try again (or if you want to virtualize something else after this task is done).
I wasn’t sure which programs on my list would run in 32-bit WinXP. I would have to try them and see. I had no problem with the idea of using Windows XP as the base. I had noticed that WineCFG defaulted to using XP. It seemed likely that Linux people had had more time to work through the many complexities of that operating system (OS). In other words, a 32-bit WinXP portable might not run as fast as a 64-bit Windows 7 portable — but at least it would run.
So now the task was to set up a clean, basic Windows XP VM. There seemed to be two routes to this objective: find one already built, or build one myself. A search for a prebuilt Windows XP VM led to Microsoft’s own VM download page where, unfortunately, Windows XP VMs were no longer available. I planned to run this VM on Windows 7, so while I was there I downloaded the “IE8 on Win7” VM, reasoning that this likely represented the oldest and simplest of the available Windows 7 options. That page said:
Please note that these virtual machines expire after 90 days. We recommend setting a snapshot when you first install the virtual machine which you can roll back to later.
I thought about using the XP Mode built into Windows 7, but I noticed that Cameyo hadn’t mentioned that option, and I wasn’t sure that — even if Cameyo would work with it — XP Mode would provide a fully isolated VM. PCWorld provided some other arguments against XP Mode.
So while I could try my luck with the Win7 IE8 VM that I had just downloaded from Microsoft, it seemed likely that I would have to build my own XP VM. For this purpose, it did not appear that it would be helpful to explore the experimental possibility of building a portable or “live” Windows XP installation, suitable for running from a USB thumb drive. To the contrary, it seemed I should try to give Cameyo the most standard, “stock” kind of XP environment possible, and should do it from within the VM environment as specified.
In another post, I had already worked through the questions of which virtualization program to use — I had settled on VirtualBox — and how to use it. Part of the solution, there, had involved downloading preconfigured VMs containing my preferred Linux distribution from VirtualBoxImages, OSBoxes, or VirtualBoxes. As anticipated, those sources had no preconfigured Windows XP VMs. It seemed I had to set up my own 32-bit Windows XP SP3 VM from scratch. Another post describes the steps I took to accomplish that.
Using Cameyo to Virtualize
Olympus Digital Wave Player
So now I had a Windows XP VM running in VirtualBox. This VM shared a folder with the underlying Windows 7 machine. I would use that shared folder to hold the Windows installation programs that I wanted to virtualize. The answer to a question I posted in the Cameyo user forum confirmed that this shared folder needed to be a place that would remain inactive while Cameyo was active. Otherwise, Cameyo would think that activity was part of the process it was trying to virtualize, and I might have to redo the Cameyo process or undo my mistakes within the resulting Cameyo package. Another post discusses that in more detail.
At this point, in the VM, I went to Start > My Computer to open Windows Explorer, and pointed it at that shared folder. Cameyo itself was a portable program. I put a copy of it on the desktop in the VM, and ran it from there.
I decided to start by virtualizing my simplest programs, saving for later the ones that might require me to tweak the VM or that might not even run on a 32-bit system. Olympus Digital Wave Player (DWP.exe) was probably the simplest, although possibly also the most frustrating and/or poorly designed, of the foregoing programs, so it was first on the list.
When I started Cameyo, it presented me with a choice of modules to launch. I chose Capture an Installation. It said, “Taking initial snapshot before installation.” Then it said, “Install the software you wish to package. When installation is done, click ‘Install done’. If installation requires reboot, simply reboot.” So, OK, I double-clicked on DWP.exe. But DWP.exe was not cooperative. It flashed through a couple of introductory messages and then said what it had said to me in Linux, when I had tried to run it via Wine:
The Digital Wave Player is not installed.
Please install the Digital Wave Player and reopen this application.
I went out to the Windows 7 system and tried running DWP.exe there. It started the install process and paused for my input. So the problem was not with the DWP.exe file. It seemed to be running OK. (Later, I would realize that this might have been because I already had DWP.exe installed on the Win7 system.)
Back in the VM, I tried running DWP.exe from the Windows XP command line: Start > Run > cmd > navigate to the shared folder with “cd,” using the drive letter assigned in the VM > just enter “DWP.exe” as a command. Same result, and no visible output on the command line that might tell me what was going wrong.
I knew that DWP.exe could run in Windows XP, because I had run it in XP for years. So was it that, for some reason — access to USB ports or other hardware, perhaps — DWP.exe was incapable of being installed in a VM? If so, maybe I could virtualize it in a native Windows installation — on bare metal, as they called it: on an actual computer, not merely in a VM — and then maybe that portabilized version would run in a VM?
Another post presents the steps I took in pursuit of that unknown, to achieve essentially the same thing as in my VirtualBox VM: a clean, basic Windows XP installation, but this time on an actual computer. Once I had that bare-metal Windows XP installation, I put Cameyo.exe and DWP.exe on that computer’s WinXP desktop. I ran Cameyo and told it to capture the installation, and then I tried again to install DWP.exe. This produced the same “Severe” message (above).
I recalled that, when I used to install DWP in WinXP, I would start with an earlier version of the program. That probably wasn’t just superstition; it was probably born of long experience. So now, instead of starting with DWP 2.1.4, I started with the original CD that came with the Olympus VN-960PC digital voice recorder (DVR), containing DWP version 2.0.1. I was pretty sure that all Olympus DVRs in this series came with some version of DWP. I didn’t actually have the original CD anymore, but I had kept a copy of its files, and they were also available online. So now I tried again with Cameyo, letting it take its starting snapshot and then installing DWP with that original CD’s Setup file. I went with all the default settings. It installed. I clicked on Cameyo’s “Install Done” button. After a moment, it said, “Package successfully built.” It put it in C:\Documents and Settings\Administrator\My Documents\Cameyo apps. I renamed the file “Olympus Digital Wave Player 2.0.1.cameyo.exe.”
I decided to try again. This time, I installed the original version 2.0.1, but then kept Cameyo running while I continued installing other software that I had accumulated. I did this to see whether version 2.1.4 could be made to install on this old Dell laptop using this approach, and also to create another Cameyo virtualization in case Linux didn’t like the Basic one that I had just finished.
To start this second attempt, I went into Control Panel > Add or Remove Programs > Olympus Digital Wave Player > Change/Remove. Then I double-clicked on the Cameyo icon that I had placed on the desktop and selected Capture an Installation, as before. But I got a weird message: “Already running.” Why was it running? It had finished the previous job. I went into Start > Run > taskmgr.exe > Processes tab. Well, yes, Packager.exe was indeed running. I clicked End Process and then ran Cameyo again.
In this second attempt, after installing 2.0.1, I proceeded on with some Olympus DWP files that I had gotten from somewhere. These were named VNUSB.dll, VNUSB.INF, and VNUSB.sys. My instructions were to right-click on VNUSB.INF and choose Install. I did that. (Later, it would occur to me to run DoubleKiller to examine these files. Sure enough, they were duplicates of those contained in DWP versions 2.0.1 or 2.1.4.)
It seemed that the prior installation of version 2.0.1 made a difference, because this time I was able to proceed with the installation of version 2.1.4 without getting that “Severe” error. I told Cameyo that was it, and in a moment it came back with another “successfully built” message. I renamed this Cameyo package to be DWP 2.1.4.
Finally, I made a third try. This time, after installing DWP 2.1.4, I took the additional step of connecting the Olympus VN-960 DVR to the computer via USB cable. That produced a noise indicating that a device had been connected, but unfortunately the DWP software did not pop up in recognition. I gave that a minute and then concluded the Cameyo recording session. I named this one “DWP with USB.”
I uninstalled the DWP software from the computer, looked in Task Manager to make sure that neither Cameyo (Packager) nor DWP was running, and then tried all three of these Cameyo packages. Trying them involved clicking on them and then selecting the Digital Wave Player option when the Cameyo window opened. The first two ran. The one with the incomplete USB connection did not. Cameyo may have successfully packaged what it saw, but what it saw evidently did not compute. My impression was that the hardware connection impaired — perhaps even a successful USB hardware connection would have impaired — the functioning of the Cameyo package.
This effort would simplify the use of the Olympus DWP software in the future. It appeared that I would not need to install DWP anymore, much less go through the process of installing two separate versions; I could just run it as a portable.
Now that I had DWP in portable packages that could run on Windows, the remaining question was whether they could run in Wine on Linux. To find out, I started VirtualBox and powered up a Linux Mint VM. In the Linux file manager, I browsed to the shared folder where I had put these DWP packages. I selected the version 2.0.1 package > right-click > Open With > Wine Windows Program Loader. That failed with a message: “Error: DW90USB.dll ????????????” (I may not have gotten quite the right number of question marks, but it was something like that.) I tried again with the two other DWP packages that Cameyo and I had just created. Same thing.
So now, it seemed, I had two options. I could try installing version 2.0.1 by itself in Linux, now that I had discovered that version 2.1.4 (which I had been trying in Linux previously) did not work in Windows by itself either; or I could troubleshoot this DW90USB.dll message. I decided to do both, in that order.
Still inside the Linux VM, I navigated, in that shared folder, to the Setup.exe file for DWP version 2.0.1. It did open successfully with right-click > Open With > Wine, and proceeded to install. The installation appeared to finish successfully. I found the installed program files in the hidden folder at /home/osboxes/.wine/drive_c/Program Files/Olympus/Digital Wave Player, and I found the folders that DWP used for messages (i.e., FolderA, FolderB, FolderC, Recording, and Schedule) at /home/osboxes/.wine/dosdevices/c:/users/osboxes/My Documents/Digital Wave Player/Message/. I put a .wav file in FolderA, used the Wine right-click startup on the DWP.exe file in the program folder, and I was able to play that .wav file. So the installation of the older version of the Olympus DWP program did work in Linux via Wine.
(Inside the Linux VM, I was not able to test the USB connection with the actual Olympus DVR device. This computer was already set up to upload from the DVR. When I connected the DVR to this computer, Windows 7 stepped in and ran DWP. I had already found a way to get Linux to recognize the DVR. Further work with the combination of the DVR hardware and the DWP software would have to wait.)
One conclusion, then, was that Cameyo had made things worse: it had converted a version 2.0.1 installer that would work in Linux into a portable package that would not. Another conclusion was that it may not have been necessary to run Cameyo on a native Windows XP installation. The problem appeared to be, not with the Windows setup, but just with the version of Olympus DWP that I was trying to install.
So that answered the first question: the old DWP software could be installed and run in Linux. Turning to the second question, what was the reason for that DW90USB.dll error? A search generated the impression that the multiple question marks just meant, Where is the DW90USB.dll file? A number of sites (e.g., FixErrorHelps) offered a variety of general suggestions, but none seemed quite on target. A search confirmed that the file was included in the Olympus installation folder, but for some reason Cameyo had evidently not incorporated it. It was possible that I could have gotten the installer to work with Winetricks, but I was content to use the older 2.0.1 version, so I suspended the inquiry at this point.
To sum up, it seemed that Cameyo could serve to combine a multi-stage software installation process into a single portable file, and that this file could run in Windows. But the Olympus DWP trial had not demonstrated that this single portable file would run in Linux via Wine. Pending additional troubleshooting, it appeared that the only way I could run DWP in Wine was to skip Cameyo and just use an older version of the Olympus software.
Using Cameyo to Virtualize IrfanView
IrfanView was another Windows program like Olympus DWP, in the sense that it could be installed as a portable, in a one-pass installation process; but it also had a second installer containing various plugins that would enhance IrfanView’s capabilities. Like Olympus DWP, in a previous effort I had seen that the basic IrfanView installer would work in Wine. The question here was whether Cameyo would be more successful (from a Wine perspective) in packaging the two installers required for IrfanView plus its plugins.
I decided to try, first, to execute this Cameyo process in the Windows XP VM. As above, I started Cameyo, let it take its preliminary snapshot, and then installed the installer and the plugins for IrfanView 4.42 (32-bit). I got an error message because I had opted to create no shortcuts, so I aborted, killed Packager.exe in Windows Task Manager (as above), and did it over again, this time letting the installer create Start Menu shortcuts. That worked: as before, I got a confirmation: “Package successfully built in C:\Documents and Settings\Administrator\My Documents\Cameyo apps.” I went there, moved the IrfanView.cameyo.exe file to the folder that my VMs were sharing with the underlying Windows 7 system, and ran the Cameyo package for IrfanView 4.42 from the options that Cameyo gave me. That worked: it ran. So there didn’t seem to be any need to use the native Windows XP installation to create the Cameyo package: it could be created just as well in a WinXP VM.
Now I powered down the Windows XP VM, powered up my Linux VM, and tried running IrfanView.cameyo.exe in Linux via the right-click > Open in Wine option (see above). That worked too: IrfanView ran. I tested it with a .jpg image and a .wav audio file. It was able to view the .jpg, but the attempt to play the .wav produced an error:
Error: Windows can’t play this file!
Windows error text: The driver cannot recognise the specified command.
You can try to install additional video/audio codecs from this site: http://www.fourcc.org/indexcod.htm
or try the Direct Show option in ‘Properties->Video’
There are several nice codec packs, like: K-Lite Codec Pack etc.
I had recently downloaded K-Lite Mega Codec Pack 12.1.0, so I put a copy in the shared folder and tried again, this time making sure to uninstall IrfanView in the Windows XP VM first. As before, I installed IrfanView and then its plugins, but this time I went on to include the K-Lite pack as well. I probably should have ended the Cameyo process before clicking the Finish button on the K-Lite installation, because it went ahead to open Internet Explorer, and Cameyo probably assumed that program had to be included too. The resulting IrfanView K-Lite Mega Codec Pack.cameyo.exe was 75MB.
I tested both the previous and this present Cameyo attempt in the Windows XP VM. Both were able to play the .wav file and view the .jpg. Turning back to the Linux VM, the results for this IrfanView K-Lite Cameyo package were as before: it could view the image but could not play the sound file. The error message was the same as before. These results suggested that a simple attempt to include needed codecs in an installation would not necessarily work.
I had not tested the IrfanView plugins, to see whether that step of the installation had been captured in Cameyo. The plugins download page said that, among other things, the plugins enabled IrfanView to view XCF files. I downloaded an XCF file. IrfanView on the Windows 7 system was not able to view that file, even after reinstallation. So something was wrong there. But I did not pursue the plugins issue further at this point.
To sum up: as with the Olympus DWP program (above), Cameyo produced a portable program that seemed to have good functionality in Windows XP and/or Windows 7, but limited if any functionality in Linux. No doubt further tweaking and experimenting would make me more familiar with the use of Winetricks and other means to help these Cameyo packages function as desired. But while such efforts might be instructive, I could not say whether they would be entirely successful in the end.
Trying Cameyo with Other Programs
The foregoing results suggested that Cameyo would probably not help much, at this point, in the effort to make Windows programs run on Linux. Of course, results could vary according to the versions of Cameyo (or alternatives to Cameyo), of Wine, of Windows, and of the programs being virtualized. That raised a question: in trying Cameyo with other programs, should I use the latest and presumably best version of those programs? Or should I try, instead, to make a portable copy of an older version?
Normally, of course, one would seek to use the latest version. But the situation seemed a little different in Linux. My browsing in the WineHQ database and elsewhere had suggested that the older versions would sometimes work better in Wine. I guessed that this was because Linux programmers had had more time to study and experiment with the older versions, or because the older versions were less complicated.
On balance, I decided to try using Cameyo to virtualize the most recent versions of the programs available to me. It seemed that the Cameyo people might be most attuned to success with the most recent versions of popular programs. Besides, if the Wine approach failed, I would want to be running the more recent versions in a Windows 7 VM in Linux: this way, at least I would not have to reinstall those programs in that VM.
I virtualized these programs in the Windows XP VM, with no network connection available. This meant that, although I entered serial numbers during installation, these programs were not yet activated. In some but not all cases, I reverted the Windows XP VM to a previous snapshot before starting a new install, and also before testing the Cameyo packages. Where I did not revert, at least I went into Control Panel > Add or Remove Programs and removed the programs that I had just installed. This seemed advisable to keep the previous installation from interfering with the next one, and also to reduce the size of the Windows installation that Cameyo would have to examine: sources said it took longer for Cameyo to take its snapshots if there were more programs installed on the machine.
Here, then, were the results I achieved, when I attempted to use Cameyo with the remaining Windows programs I was trying to get to work in Linux. Important note: when I wrote these materials, I did not realize that — at least according to VMware — Windows XP could not handle .exe files larger than 512MB. There was a Cameyo feature allowing program data exceeding that (or any other specified) limit to be stored in an external .dat file that would accompany the .exe file. At this writing, I had not yet revisited the following writeups to correct for this discovery, for those programs where it might make a difference.
Adobe Acrobat 9 Pro. During installation of Acrobat, with Cameyo running, I chose the Custom installation and unselected various items, including support for multiple languages and the tools to create PDFs inside Microsoft Office and other programs. (I preferred to create PDFs by printing them.) In the first try, I did not activate or configure Acrobat; I just wanted to see if it would work. Cameyo reported that the package was successfully built. It ran successfully in the WinXP VM, and the few changes I made (e.g., rearranging toolbars) were remembered. Interestingly, when I ran the Cameyo package in a VM with no enabled Network connector, Adobe’s demand for a serial number was not immediately triggered. That was unlike the situation when that same Cameyo package was executed in the underlying Windows 7 native machine. In my second try, after installing Acrobat, I proceeded to configure the program more thoroughly before telling Cameyo I was done. The Cameyo package ran in the WinXP VM, in Windows 7, and also in the Linux VM. But I don’t think I tried any of its menu picks. Later, when I tried to use it in via Wine in a native Linux Mint installation, I found that none of its menu picks did anything. In another subsequent use of the Cameyo package in a Windows 7 VM not connected with the Internet, I received an error message:
Licensing for this product has stopped working.
You cannot use this product at this time. You must repair the problem by uninstalling and then reinstalling this product or contacting your IT administrator or Adobe customer support for help.
Although my notes weren’t precise on the point, I believed I had activated Acrobat during the Cameyo capture. That would explain why this was not a simple call for activation. It seemed possible that Acrobat was designed not to function as a portable, or within a VM environment. But a comment following another post suggests the problem may have been simply that FlexNet Licensing Service was not activated in msconfig and services.msc.
Adobe Premiere Elements (APE) 12. I made several tries at this program, and had multiple issues, as follows:
- The first time, I let Cameyo record everything. I was working on other things in the VM’s shared folder while Cameyo was running, and only belatedly realized that (according to a chat with Cameyo tech support) my changes to various files in that folder (or its subfolders) were probably being captured in the huge (1.7GB) resulting Cameyo package. I was not sure whether that contributed to the nonworking result of the first Cameyo effort. On my subsequent tries, I included in the shared folder only those materials that I would need during this virtualization effort.
- I made the likely mistake of not starting Cameyo until the APE setup program had already turned on Microsoft .NET Framework 2.0 SP2 within the VM, which APE would evidently need in Windows XP. (After installation, in Control Panel > Add or Remove Programs, I was able to see the programs added during this installation process.)
- I learned that APE was going to need QuickTime to play MPEG4 video. I downloaded QuickTime 7.7.9, but I was not able to install it in the Windows XP VM. Instead, I got an error: “QuickTime 7 requires that your computer is running Windows Vista or Windows 7.” It developed that that statement was not accurate: elsewhere, Apple reported that QuickTime 7.7.6 was fine with Windows XP SP2 or later. I tried version 7.7.6, and that worked. (On my third try, in Windows 7 x32, I was able to use version 7.7.9.) Then I started the installer, but did not start Cameyo until I came to a dialog saying this:
Welcome to the InstallShield Wizard for Adobe Premiere Elements 12
The InstallShield(R) Wizard will install Adobe Premiere Elements 12 on your computer. To continue, click Next.
- The installer said that some components would require activation online, the first time they were used. This appeared to relate especially to the MPEG2 and MPEG4 formats, but also to unspecified others. (Someone said that it was possible to avoid going online by copying over the C:\ProgramData\Adobe\Common\Adobe\ARA\10.0\Repository2_0.db file from a computer that already had gone through that activation process, but Windows XP did not appear to have a Repository 2_0.db file.)
- Then the installer wanted to reboot the VM, and I said OK. After rebooting, the final step in this installation was, optionally, to include the Lagarith lossless codec, as described in another post. After that, I rebooted again.
- I started APE and got the welcome screen, offering to let me run either the video editor or the organizer. I clicked on the settings (gear) icon and changed that so that I would always start in the video editor. I closed that and then restarted APE.
- Now it wanted me to sign in with Adobe. Unfortunately, the VM was unable to go online. Rather than build my Windows XP networking struggles into the Cameyo package, I canceled Cameyo and made yet another try, this time using a Windows 7 x32 VM. Along with the other steps just described, I made sure it could go online before I started (using ping 188.8.131.52). But then I got an indication that the serial number was invalid. In that case, I said, let’s just do the trial installation. The installer got partway through the process but then began rolling it back. But on a retry, the serial number worked and the installation completed. But for some reason Cameyo did not survive the reboot after installing: whatever it had captured was apparently gone.
- I had heard that WinXP was the ideal operating system for Cameyo’s purposes, so I went back to that. Unfortunately, the APE installer was still unable to go online to register. A search led to no solution. But now a “Sign in Later” option appeared, where before there was only one choice: Sign in Now. So at least I could complete the installation and see whether this Cameyo package of APE was going to work, and then perhaps try the offline method of registering. (It did not help to install on a physical WinXP machine (i.e., not in a VM) on another computer: the outcome there was the same.) On a later try, when I pursued activation further, I found advice: (1) The link for offline activation would only work if the Internet connection was disabled — and even then it ended up with a “Response code entered is invalid” message that I could not get past. (These problems seemed to affect multiple Adobe products.) (2) I was advised, in effect, to comment out any Adobe-specific lines in the hosts file (located in Windows XP at C:\WINDOWS\system32\drivers\etc) by putting hash marks (i.e., # pound signs) in front of them. (3) That same source advised me to rename the SLStore folder (in WinXP, located at C:\Documents and Settings\All Users\Application Data\Adobe) to be SLStoreOld, and to rename the SLCache folder (in WinXP, found at C:\Program Files\Common Files\Adobe) to be SLCacheOld. Unfortunately, these steps did not help, even after a reboot. In short, APE appeared resistant to registration in a VM. It appeared that a permanent capture would have to be done using Cameyo in a clean physical WinXP installation.
- The resulting Cameyo package was not very much smaller this time around: about 1.5GB. More to the point, it did not run — not even in my native Windows 7 installation, much less in a VM.
- I wondered whether perhaps I had erred in starting Cameyo too late in the installation process. I went back to the original approach, of starting Cameyo before I started running any installers. So this time, the Cameyo package would probably have more of Microsoft .NET 2.0 and QuickTime. Then it occurred to me: what if QuickTime was part of the problem? I decided to skip that. The resulting package was 1.4GB — and it did not run.
- Given the failure rate of efforts to run it in Wine, as noted in another post, it seemed that I would have to use a Windows VM to run APE in Linux.
Adobe Reader. I started by trying to run the Cameyo package of Adobe Acrobat Reader. That effort produced a “Fatal Error: Acrobat failed to load its Core DLL.” A search led to a forum discussion and another page on that issue, but I did not attempt to troubleshoot that error at this point. The package did start to run in my Linux VM, but then I found myself stalled at a screen that said, “Press the Accept button to agree to the License Agreement and continue,” where the Accept button was grayed out. At Softpedia, I saw there were other versions available. Among those, I downloaded Portable Adobe Reader Lite 9.0. That it did run via Wine in my Linux VM. According to OldVersion.com, Adobe Reader version 9.0 dated to 2008. But at least I had it, now, as a fallback. I turned, instead, to other versions of Reader. Adobe’s website seemed to be intent on installing Adobe Acrobat Reader DC immediately. But another page notified me that there was a separate download webpage. There, I specified Windows XP SP3. In that case, the only version available was Reader 11.0.08. I unchecked the offers of unwanted additional (McAfee and True Key) software and clicked Download Now. This gave me a file called reader11xp_en_xa_install.exe. I killed the download webpage, rather than proceed to installation, and renamed the download Adobe Reader 11.0.08.exe. I saved a copy in a separate folder, because I had encountered some Adobe software that would delete the installer during the installation process, and I didn’t want to have to re-download. In the WinXP VM, I started to install it with Cameyo watching, as usual. Unfortunately, I got an error: Connection failed. I enabled the VM’s network connection and tried again. The installer turned out to be a downloader too. It said it was downloading, then installing. I probably should have finished Cameyo before clicking the Finish button; Internet Explorer opened, but I closed it and then ended the Cameyo session. Saving a backup proved justified: the installer had deleted my Adobe Reader 11.0.08.exe file. The resulting file was named Adobe Reader XI.cameyo.exe. I tested it with a 200MB PDF with multiple bookmarks. It seemed to be performing perfectly in the Windows XP VM and in native Windows 7. But when I opened it in Linux Mint, it crashed immediately.
Cool Edit 2000. In this installation, I had to run the primary installation CD, enter a registration key, install two plugins, and also copy some settings files to a couple of folders on drive C in the Windows XP VM. Then, with Cameyo still running, I rebooted the VM, ran Cool Edit, and changed some other settings. Cameyo seemed to capture all that. Upon playback in the Linux VM, only the primary installation CD and perhaps the settings files seemed to be recognized: the registration and other tweaks did not take. Moreover, in the Linux VM, the program was not able to open a sample .wav file. There were no such problems when running the Cameyo package in Windows 7.
Cyberlink PowerDirector Ultimate 12. In this installation, I started with AutoRun.exe on the first DVD. Unlike the Adobe Premiere Elements installation, this one came with its own copy of QuickTime, as well as SmartSound, which I also installed. When that installer was finished, I followed up with the setup.exe file for WVEditor, also on the first DVD. I also had previously downloaded PowerDirector_2930_GM6_Patch_Patch_VDE140423-01.exe, so I installed that. I had forgotten to uninstall Premiere Elements first, and this CyberLink thing was a hog: there wasn’t enough space left on the 10GB VM to accommodate the patch. So I uninstalled APE now, Cameyo still watching, and then reran the patch, as well as a previously downloaded copy of the PowerDirector Updater. Absent an Internet connection, the latter aborted. I told Cameyo this installation was done. It struggled for a while but then gave up, at the Building phase, with an error: “Could not finalize package: APIRET=9.” I suspected it had just run out of space. I was not optimistic about the functionality of any Cameyo package capturing an installation taking well over 3GB, as PowerDirector did on my Windows 7 computer — the largest by far of any program there — but I resized the VM to try again anyway. Resizing gave me a warning that the VM’s copy of WinXP would have to be reactivated within three days, but I blew that off: this VM would be dead within three days, and death was a status that no activation sequence could overcome. In XP’s Control Panel > Add or Remove Programs, I removed everything except VitualBox Guest Additions. Then I repeated the foregoing installation steps. This time, Cameyo finished. It produced a 1.7MB .cameyo.exe file and a 2.3GB .dat file, both with the same name. In the native Windows 7 installation, I tried running that .exe file. It took a minute or two — not sure how long; I was working on something else — but it did eventually open up the Cameyo window, asking me what I wanted to do. I chose CyberLink. The system — a relatively fast system, with an Intel Core i7-4790 CPU, running Windows 7 x64 on an SSD with 16GB of RAM — had still not loaded the Cameyo package 15 minutes later. The HDD was the bottleneck; I could see its light running hard during much of that time. I moved the Cameyo files to an SSD and tried again there. The difference was too dramatic: I must have done something wrong, because PowerDirector came up almost immediately. It looked like it was going to work. I imported and began to work on a video. Within a minute or so, PowerDirector crashed. I didn’t recall ever seeing it crash before. This did not seem like a winning project. Here, again, I concluded that a Windows VM was the only option.
Microsoft Office 2010. As noted above, there were indications that, at least as of 2013, Cameyo was not doing well with Office 2010 or later. A different search provided no reason to think the situation had improved since then. I decided to try anyway. In the Windows XP VM, I ran the installer for 32-bit Office 2010 Professional. It did not give me an option of installing just some of its components (e.g., Excel, PowerPoint), as I had thought or assumed it would. When it was done, I kept Cameyo running while I installed an old version of the Microsoft Office Compatibility Pack. (I could have downloaded a newer version, but I was concerned that Microsoft might tweak that software to push for purchase of an updated version of Windows.) I also ran the old AutoCorrect macro that I had used to add my saved list of word abbreviations to Office 2010. That started Word, triggering an invitation to go online and activate (which I deferred for now) and an option to choose what to do about updates (I chose “Don’t make changes”). Then I remembered the newer approach: using MSO1033.acl instead of that old AutoCorrect macro. I did a search, using Windows Search inside the VM, for the location of that MSO1033.acl file in Windows XP; but then I thought to run a Google search, and located the MSO1033.acl file at %userprofile%\Application Data\Microsoft\Office. Next, I installed the Office Tabs and ASAP Utilities add-ons. I rearranged some files. There was some other screwing around. I figured I had probably generated a lot of extraneous confusion for Cameyo. And yet, to my surprise and delight, when Cameyo was finished, the thing ran. I mean, the Cameyo package worked, with all this stuff built into it. It produced an error message when I tried using it to run Excel 2010 inside the VM, but a brief search suggested that that error had to do with a problem in the VM, not in the Cameyo package. It also produced an error and terminated when I ran Excel 2010 in the Linux VM and in Windows 7, but this error had to do with product activation.
Recuva. Since the portable version hadn’t worked in Wine (above), I tried the installer version of Recuva 1.5.2. The capture process took just a few moments. The resulting package ran in Windows 7, but in the Linux VM it terminated with the same “quit unexpectedly” error as above.
It seemed, in summary, that Cameyo did a much better job of producing useful packages than I had expected at the start. The main problem, for me, was that some of my most needed and troublesome programs were no more willing to run in Linux via Cameyo than they were willing to run via Wine. Cameyo had not eliminated the need for a Windows VM in Linux. It was nonetheless one more tool to keep in mind.