This post describes an unsuccessful effort to virtualize Office 2003 using Cameyo. The details are here for anyone making a similar attempt, and also to invite suggestions.
As part of my project to transition from Windows 7 to Linux, I was looking for an office suite to take the place of the Microsoft Office suite I had been using in Windows. Linux came with various free alternatives, including the estimable LibreOffice. Nonetheless, I wanted some version of MS Office on hand.
As I reviewed my present and previous Office programs, I recalled that I had preferred the relatively austere menu of Office 2003 over the ribbon that Microsoft implemented beginning in Office 2007. The latter was more suited to mouse users, whereas I preferred to use the keyboard for my word processing to the extent possible.
I also believed that Wine, the Linux tool used to run Windows programs on Linux, was at its best with simpler programs. Office 2003 did seem to be quite a bit simpler and smaller than more recent versions. I did not put too much stock in this belief. After all, the WineHQ Applications Database reported successes and failures with all versions of MS Office. But many of those tests went only to the point of installation, without extensive testing of features.
It was clear, of course, that in 2016, not many potential readers were going to be interested in using Office 2003. But it appeared that the program was still for sale. Besides, I was intrigued by the thought that, if I could create a portable version of Office, I might be able to continue to use it, on native Windows installations or in virtual machines (VMs), without ever again going through the hassles of installation. I was not sure precisely how Microsoft’s licensing or activation was going to work; that was one of the unknowns that would have to be resolved as I proceeded.
A portable version would have another advantage, if it worked. As detailed below, my Office 2003 installation was complicated. Compared to running in Wine, Cameyo would have the advantage of capturing all the various tweaks and updates in a single convenient package.
At this point, I had used Cameyo to make portable versions of a number of Windows programs. As described in another post, those Cameyo packages had generally run well in Windows but not in Linux via Wine. I knew it would probably turn out that Cameyo would give me a portable version of Office 2003 that would work only in Windows. I accepted the possibility that a Windows VM would be the only place where I could run any version of MS Office on a Linux system.
I had already created a quick-and-dirty Cameyo capture of Office 2003. I did this in a very basic Windows XP SP3 VM with essentially nothing installed, including no Internet connection, no firewall, and no antivirus software. (I was using VirtualBox to create and run my VMs.)
Cameyo advised that a minimal WinXP SP3 system would provide the optimal environment for packaging a portable version of an installed program. The idea seemed to be that Cameyo operated by taking before-and-after snapshots of the operating system, so as to capture the differences that the installer had made, and it was easier for Cameyo to do this on a system that didn’t have much going on. The VM provided a superior environment for this sort of thing: I could do my tinkering in a clone of my simple WinXP VM, easily discard that clone and start over with a new one if things went wrong, and keep snapshots of that clone as I progressed if things were going well.
My quick-and-dirty Cameyo capture of Office 2003 did look like it wanted to run. But it had some issues. When I ran it in a native (i.e., non-virtual, real hardware) Windows 7 system, Word started up without issues, but Excel produced an error:
One of your object libraries (stdole2.tlb) is missing or damaged. Please run Setup to install it.
When I clicked OK on that error, Excel proceeded to run without further complaint — though, at this point, I did not test it beyond a few menu clicks. I assumed that the reference to Setup, in that error message, was a reference to the Office 2003 installer. A search for information on that error led to various troubleshooting possibilities and also to the suggestion that this error might result from having several versions of stdole2.tlb on my computer. I did have copies of stdole2.tlb on that native Windows 7 system, possibly because I already had another version of MS Office installed there. The moral of this particular story might be that, if I wanted to run a portable version of MS Office in a Windows system (whether native or VM), I might need to run only portable versions in that system — that is, to refrain from installing any version of MS Office there.
That was the situation when I tried running that Cameyo package in a native Win7 system. When I tried running its Word program in a Windows XP VM, I got a different error:
Microsoft Office Word has not been installed for the current user. Please run setup to install the application.
This was presumably a reference to the fact that I had installed it from the Administrator account in a WinXP VM and was now trying to run it in the ray account in another VM. This outcome enhanced my awareness that, when setting up native and virtual installations in Linux or Windows, I would want to insure that I was using one consistent user account name (in my case, ray) to configure the system and create things like these Cameyo packages.
When I tried to run Excel from that Cameyo package in that WinXP VM, I got a different error, much like the one quoted above:
One of your object libraries (vbe6.dll) is missing or damaged. Please run Setup to install it.
Here, again, Excel was willing to run after I clicked OK on that, but then it collided with the foregoing “has not been installed for the current user,” and terminated. A search led to a suggestion that the vbe6.dll error might be best addressed by reinstalling the program in the proper user account.
I got the same results when I tried opening the Cameyo package in a Linux Mint VM with Wine. Here, again, it did look like Linux was going to be able to run the Cameyo package: Word and Excel were opening up, with a spreadsheet grid visible in the latter, before they closed down with the foregoing errors.
In short, the errors in this section seemed to suggest that I should create the Cameyo package under the correct username and run it in a system where Microsoft Office was not already installed. The latter would be no problem in a Linux VM.
Trying for a Basic Cameyo Package
In my basic Windows XP VM, I turned on Cameyo > Capture an Installation, so that it could take its initial snapshot of the system. (As described in my post on creating a VM, I used the Shared Folders setting in VirtualBox to create an avenue through which I could get the portable Cameyo.exe program and the Microsoft Office installation files onto the VM’s desktop.)
Once Cameyo had its snapshot, I proceeded with the Office 2003 installation. I chose Custom Install, and opted to install everything except InfoPath. In this VM, the network connection was not enabled, so I did not opt to check for updates. I also did not opt to delete installation files. I clicked Finish, and then (without turning off Cameyo) went to Start > Turn Off Computer. For some reason, these WinXP VMs were restarting automatically after a turn-off message, so I had to tell VirtualBox to power down the VM. In VirtualBox, I made a snapshot of this VM. Then I restarted the VM and told Cameyo the installation was done.
Cameyo told me that it had placed its .cameyo.exe output in its C:\Documents and Settings\Administrator\My Documents\Cameyo Apps folder. (Of course, this was the virtual drive C, not the computer’s actual drive C — which didn’t exist at this point, as I was running VirtualBox in Linux.) In that package, I tried running Excel. I got the vbe6.dll and “not installed for current user” errors (above). This was the VM in which I had created the Cameyo package. I confirmed that ray was still the only active account.
It appeared I was mistaken in believing that those errors arose solely from the creation of the Cameyo package under a different username. A search led to several suggestions:
- Advice to replace C:\Program Files\Common Files\Microsoft Shared\Office11\MSO.DLL with an older MSO.DLL from elsewhere on your computer or from other sources. “Other sources” included the installation CD for Office 2003 (but not for Office XP or 2007); reinstallation (which would apparently restore the proper MSO.DLL, at least in some cases); or download. (Windows Explorer’s Tools > Folder Options > View settings should not be hiding anything.) In my installer, seemingly identical copies of MSO.DLL were found in O1561403.CAB and ACCESSRT.CAB. The installed MSO.DLL was dated August 8, 2003; the downloaded one was dated June 20, 2003. This replacement did not fix either of the foregoing errors. Later, I gathered that this fix was intended to address a situation where a downloaded update had installed a defective MSO.DLL. That would not apply here; this VM was not connected to the Internet, and there were no downloads.
- Advice to go to C:\Documents and Settings\All Users\Application Data\Microsoft\Office\Data\OPA11.DAT > Properties > Security tab > Advanced > Permissions > give Full Control to Everyone (alternately, just delete that file). Unfortunately, my installation had no OPA11.DAT file, at that location or anywhere else.
- A question as to whether the software was pirated and/or the license key had been revoked by Microsoft. This software was not pirated; I had used it for several years, circa 2004, with the usual registration/activation process. The license could have been revoked, but this VM was not connected to the Internet, I was using an old Windows XP SP3 CD without updates, and I hadn’t yet tried to activate or register this Office installation, so I doubted that this was the explanation.
- A suggestion that perhaps there was more to the MSO.DLL option (above). The advice in this case was to run Setup.exe in the Office 2003 installation files and choose the repair/reinstall option. This option seemed plausible: after all, the error message did advise me to run Setup; I just hadn’t been sure what it meant. I went back and deleted the newly downloaded MSO.DLL replacement and then ran Setup’s Reinstall or Repair > Detect and Repair Errors option.
Only now did it occur to me to try running the actual Office 2003 installation that I had just installed into the VM, as distinct from Cameyo’s packaging of that installation. In that installed version, Excel ran fine, but I didn’t know whether that was because of this fix or because it had been running fine previously.
I started over with a new cloned VM, redid the Cameyo capture, but this time terminated it as soon as the installer was done, without bothering to try to save a snapshot of the VM. This time, I noticed that the completed Cameyo package had a nice Microsoft flag icon; last time, it had had only a generic icon. When I ran Cameyo’s capture of Excel, however, I got the same errors. The Excel actually installed on the computer ran fine, however.
I moved the Cameyo package out of the VM, closed down and deleted the VM, created another clone VM, moved the Cameyo package back into the VM (just in case that mattered), and tried running the Cameyo package there. I got the same errors. That seemed to rule out the possibility that the problem stemmed solely from a conflicting Office 2003 installation on the virtual computer.
I tried running the Cameyo package on the underlying Linux machine (since that was, after all, the ultimate goal of these efforts). Again, I ran it from an ext4 partition, not an NTFS partition, because I had seen somewhere that this could make a difference. I got the same errors there.
By this point, I had begun to realize that the foregoing fixes should have been applied within the Cameyo package, not to the Office 2003 installation in the VM. Cameyo was a Windows program, so I moved the Cameyo package back into the WinXP VM and attempted surgery there. I ran Cameyo.exe and chose Edit a Package > Open existing virtual app > navigate to Desktop, where I had put the .cameyo.exe package. I opened that package in Cameyo’s Package Editor > Files tab. This seemed to contain a partial copy of the Windows XP drive C. I went looking, there, for the fixes suggested above:
- I did find an MSO.DLL file there, at approximately the location specified above (in this case, it was under FileSystem > %Program Files% > Common Files > Microsoft Shared > OFFICE11). I couldn’t tell what date it had: its right-click Properties didn’t give me that kind of information. I could have replaced it; but in light of everything said above, I didn’t see how that made sense, and it could bring the risk of replacing the right file with the wrong one.
- As in the VM, I found only an OPA11.BAK file, not a .DAT file. (The location in this case was FileSystem > %Common AppData% > Microsoft > OFFICE > DATA.)
There seemed to be a problem with the creation of the OPA11.DAT file that everyone said was supposed to be there, but wasn’t. I found that just starting Excel was enough: now I had C:\Documents and Settings\All Users\Application Data\Microsoft\Office\Data\opa11.dat in the VM.
I suspected that the mere existence of this file was going to solve the problem; but just in case, I tried to take the advice to give it full permissions (above) — but there was no security tab in the Properties dialog for that file in my VM. I reopened Cameyo’s Package Editor > Files tab > FileSystem > %Common AppData% > Microsoft > OFFICE > DATA. I copied the opa11.dat file into that folder in the Package Editor by using the Add File icon at the left edge of the Package Editor toolbar. I exited Package Editor, saving changes. I tried the Cameyo package again. It still failed.
It seemed, then, that the software was being installed successfully on the VM, and the installation was being captured by Cameyo, but for some reason the installation was running whereas the Cameyo package was not. I verified that I was still getting the same errors when I tried to run the Cameyo package on a native Linux installation via Wine.
Since I had been consistently getting that same error about not being installed for the current user, it seemed that the seemingly imaginary user problem must be within the Cameyo package, not in these Windows or Linux operating system installations, nor within the regular Office 2013 installations that I had been successfully achieving in the WinXP VM. At the same time, it seemed to be a problem unique to Office 2003; I had not had such problems when using Cameyo to package other software.
I decided to try once more. This time, after installing Office 2003, I kept Cameyo running while I opened Excel, so as to generate that opa11.dat file, and then I went into Add or Remove Programs > Change > Reinstall or Repair > Detect and Repair Errors > Install. When that was done, I clicked on Cameyo’s “Installation Done” button. Unfortunately, that didn’t do it; same errors as before. I was out of ideas. That concluded this effort. As in my previous attempt six years earlier, it still seemed infeasible to make a portable version of Office 2003 using Cameyo.