Trying to Run Adobe Acrobat 9.5 in Linux via Wine

This post describes my attempt to install Adobe Acrobat Professional 9.5 (i.e., not Adobe Reader) in Linux Mint 17.3 via Wine. This attempt reflects at least some improvement in my understanding of Wine, following long and sometimes frustrating earlier attempts to use Wine to install IrfanView (successful) and Olympus Digital Wave Player (unsuccessful).

As usual, this post includes discussion of the barriers I encountered. The Conclusion distills key lessons from the effort. At present, this was a second instance where others seemed to have gotten the Windows program to work in Wine, whereas my efforts failed. (Note a possible solution for those who know how to compile their own Wine.) Note also the results reported in a later post.

Installing Wine

My first step was to install Wine. I was using a fresh Mint installation in a virtual machine (VM) downloaded from OSBoxes, as described in another post. In my previous exploration of Wine, I had tried versions ranging from the old 1.6 to the unstable 1.9.9. This time around, I wanted the latest stable version, which WineHQ reported as 1.8.2. I proceeded, as described in the next paragraph, taking steps that seemed consistent with instructions offered by Ubuntu-specific sources, such as UbuntuHandbook. My approach was less oriented toward the command line and more toward the GUI interactions that would be more familiar to a Windows user.

In the VM, I went into Start > Computer > Synaptic Package Manager. A name search in Synaptic showed 1.6 as the latest available version. This was apparently because the software repositories had not been updated. In Synaptic, I went to Settings > Repositories. This opened Software Sources. Then, in Software Sources, I went to the Official Repositories tab > click on the URL shown for Main > let the time test run a bit > choose one of the fastest ones > Apply > repeat for the URL shown for Base. In Software Sources, I then went to PPAs > Add a new PPA > type “ppa:ubuntu-wine/ppa” > OK. This added the Sources PPA, even though I had not checked the “Enable source code repositories” option. I unchecked the Sources PPA, keeping only ubuntu-wine. Note that this Ubuntu-specific repository was not the one recommended by WineHQ. Next, in Software Sources, I clicked the “Update the cache” button at the upper right corner. This produced an error message — “Another synaptic is already running” — apparently because Synaptic was still open. But having opened Software Sources this way, I was unable to close Synaptic. I had to close both and then restart Software Sources from the Linux Mint KDE Start menu > System Settings. The “Update the cache” button had gotten shut off even though the update had not proceeded. I turned it back on by temporarily choosing a different repository. Clicking “Update the cache” yielded a “Downloading Package Information” message. That finished much more quickly than it had in my previous usage, but without any concluding explanation of what had happened. This would apparently be one advantage of running the commands suggested by sources like UbuntuHandbook, instead of taking this Synaptic route: I would see the results my commands had achieved. I didn’t trust the grayed-out “No action required” button that had replaced the “Update the cache” button, having just seen that it would appear even when there was still work to be done; but on the other hand I couldn’t think of anything else I needed to do in Software Sources right now. So I closed Software Sources, restarted Synaptic, clicked Reload, and re-ran that name search for Wine. This time I had several wine1.8 versions. I selected for installation just the plain “wine1.8” entry. That brought a couple of the other wine1.8 versions along with it. I clicked Mark, added Winetricks to the list, and clicked Apply. That ran for a while and then concluded with a reassuring “Changes applied” message. I closed Synaptic.

That gave me most of what UbuntuHandbook had told me to do. The remaining thing was to run the winecfg command to initialize my Wine configuration. This brought up some error messages, but my previous explorations had led to assurances that I could probably ignore these. It also gave me a series of several messages about installing Mono and Gecko. I had seen advice both ways, but the easy way had worked ultimately, so I clicked Install on each of those message boxes. Eventually the Wine Configuration dialog appeared. The About tab confirmed that I had Wine 1.8 installed. I closed that.

Making It 32-Bit

Now we had a different concern. I had seen indications (e.g., Reddit) that 32-bit Wine was able to run most if not all of the things that 64-bit Wine would run, with fewer problems. A search led to advice on how to make sure I was running 32-bit Wine. Some of this advice was pretty complicated. A revised search led to an AskUbuntu discussion containing these statements:

The version of Wine you install on a 64bit computer these days is capable of running in both a 64bit and 32bit capacity. This is decided by the prefix (the local bundle of files, traditionally at ~/.wine/). Once you’ve set up a 32bit prefix, everything will run in 32bit mode in that prefix. Conversely, if you don’t do anything and run anything with wine (or its ancillary commands), you’ll create a Wine64 environment… And these are buggy as all hell still. If you’re upgrading an old prefix (and I think this is why I hadn’t appreciated this before today), it will carry on using the same architecture. My ~2010 prefix just kept working. . . . [To set up a new prefix, you will run certain commands, including WINEARCH. But then] you shouldn’t need to set WINEARCH again. And ultimately, as Wine64 matures, this should be something that’s less and less relevant. Wine64 should be able to run 32bit applications.

For clarification on some aspects of that statement, I ran another search, leading to these remarks from an Arch Linux wiki:

By default, Wine stores its configuration files and installed Windows programs in ~/.wine. This directory is commonly called a “Wine prefix” or “Wine bottle”. It is created/updated automatically whenever you run a Windows program or one of Wine’s bundled programs such as winecfg. The prefix directory also contains a tree which your Windows programs will see as C: (the C-drive). . . . The first time a program is run with a new Wine prefix, Wine will automatically create a directory with a bare C-drive and registry. . . . If you have a 64-bit system, Wine will start an 64-bit environment by default. You can change this behavior using the WINEARCH environment variable.

So now I went back to that AskUbuntu discussion, with a somewhat improved understanding of its suggestions. First, it said, I had to remove the ~/.wine (that is, user Home folder: hidden .wine) subfolder. (There appeared to be different ways to unhide, depending on the file manager being used. Possibilities included looking for the Show Hidden Files button or using Ctrl-H.) I was able to delete .wine in the Dolphin file manager by using right-click > Delete. Another possibility was apparently to run a command like “mv ~/.wine/ ~/oldwine/.” (Note: this post uses standard English punctuation. In other words, that ending period and those quotation marks would not be included in the command.) An AskUbuntu remark notified me that deleting .wine would remove everything I had installed under Wine to this point, which was fine with me because I had not installed anything. I had to remove that .wine prefix because it was the default 64-bit prefix created at some stage of the setup process I had just gone through. There was probably a way to intercept that, so that this step would not be necessary, but I didn’t presently know how to do that.

Then, to create a 32-bit prefix in place of the .wine folder I had just deleted, the primary AskUbuntu discussion advised me to enter a simple command: “WINEARCH=win32,” followed by the words quoted above: “And that’s it. . . . [Y]ou shouldn’t need to set WINEARCH again.” This was something that had confused me in one of my previous tries with Wine. In the other AskUbuntu discussion, there was talk about the need to add “export WINEARCH=win32” to the .bashrc file, so that this reassignment (or whatever it was) would happen every time the Bash shell (i.e., the command-line Terminal) was started. I wasn’t sure if that was not good advice in the first place, or if things had changed since then. At any rate, it sounded like that was no longer necessary. So I just entered the “WINEARCH=win32” command and left it at that. The last step in the advice given by the primary AskUbuntu was to run winecfg. I didn’t get asked again about the Mono and Gecko installation.

Testing It

Now I wanted to test my Wine installation by using it to run, on Linux, a Windows program that I had already run successfully on Linux in a previous Wine installation. The program in question was IrfanView. Its executable was called iview442_setup.exe. So now, in the Linux file manager, I navigated to the folder where that executable was stored, right-clicked on that executable, and chose Open With > Wine Windows Program Loader. That achieved nothing except to open, temporarily a session of Wine Windows Program Loader in the taskbar. I tried again, this time navigating to the appropriate folder and using the command suggested by WineHQ: “wine iview442_setup.exe.” This produced an error:

Library MFC42.DLL (which is needed by L”Z:\media\sf_Current\iview442_setup.exe”) not found

Of course. I had forgotten about that mfc42.dll file. Reviewing my notes from the previous attempt, I saw that I had to run winetricks. But this gave me a disturbing notice:

You are using a 64-bit WINETRICKS. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.

What? I had just taken the recommended steps to create a 32-bit WINEPREFIX. A search led to advice to see what was reported in PlayOnLinux > Configure, or look in /home/[username]/.wine/drive_c/windows to see if there was a syswow64 folder. (PlayOnLinux was a GUI for Wine.) There was indeed a syswow64 folder. Apparently this would be found only on a 64-bit WINEPREFIX.

Reviewing previous steps in light of an UbuntuForums discussion, I believed I saw what had gone wrong. The instructions had been to type this command: “WINEARCH=win32 winecfg.” I had interpreted that as being two separate commands. That was probably a mistake. I had done that because I didn’t understand the command. I tried again now, putting the whole thing on one line, after making sure winetricks was closed. This gave me this message:

wine: WINEARCH set to win32 but ‘/home/osboxes/.wine’ is a 64-bit installation.

Right. I had to back up one step, delete the previous .wine first, and then issue the command. That seemed to work. I was back at the Wine Configuration dialog. I verified version 1.8 and closed that. Then I tried again with “wine iview442_setup.exe.” That put me back to that mfc42.dll error. I ran winetricks. This time, I got no warning about using a 64-bit version. In Winetricks, I used Select the default wineprefix (which would presumably be the 32-bit one) > Install a Windows DLL or component > mfc42 > VCRedist Installation dialog > Ja > Close. Another try with “wine iview442_setup.exe.” This time it worked: I was in IrfanView setup. I proceeded through that, mostly going with the defaults, and IrfanView ran.

While I was testing, I tried the Olympus Digital Wave Player installer that had failed in my previous try. Nope. It still didn’t work.

Trying Adobe Acrobat Pro 9.5

Now that I had a working Wine installation, it seemed I should be able to run the same Wine command on the Acrobat executable. I tried that: “wine Setup.exe.” It ran: it opened the Setup dialog and went through several steps, before halting with an “Invalid serial number” error. I verified that I was entering the correct number. A search led to an Adobe webpage offering advice on installing Acrobat in “a simplified mode” on Windows XP. This reminded me that it might be wise to consult the WineHQ database, to see what others had done.

The CrossOver database provided only one rating, of one star, for Acrobat 9 Pro. But the WineHQ database page for Acrobat linked to a page focusing on Acrobat 9, and that page expressed results ranging from Garbage to Gold, depending on the Linux distribution, its vintage, the Wine version, and perhaps also the Acrobat subversion. Notes for a recent Gold result suggested using Winetricks to install IE6. I canceled the Acrobat installation and entered winetricks on the command line > Select the default wineprefix > Install a Windows DLL or component > ie6. That opened up Firefox (presumably it was the default web browser in this prepackaged OSBoxes VM) and sent it to an page focused on Internet Explorer 6.0. Meanwhile, Winetricks was displaying a message saying,

Please download msie60.exe from, place it in /home/osboxes/.cache/winetricks/ie6, then re-run this script.

That wasn’t quite the webpage that Firefox was opened to, but clicking the link in the center of the page (as distinct from the several others offering crapware with which evidently paid its bills) did bring me a copy of msie60.exe, deposited in the Linux VM’s /home/[username]/Downloads folder. I saved a copy to a shared folder, in case the VM hit the skids, and then put the downloaded msie60.exe into the folder dictated by that message, and then again ran winetricks and so forth, as just described. That triggered a Windows Update: Internet Explorer and Internet Tools dialog. I went through its default options. It finished, but then I was left with another Winetricks error:

sha1sum mismatch! Rename /home/osboxes/.cache/winetricks/pngfilt/IE5.01sp4-KB871260-Windows2000sp4-x86-ENU.exe and try again.

This seemed to be telling me that there was corruption in one of the files involved in that msie60.exe process. The corruption seemed to be limited to that IE5 file, not extending to the whole msie60.exe download. Anyway, I proceeded as advised: I assumed the advice to “rename” that file meant that it was not going to work but that, being cautious, we weren’t going to just throw it away; we would keep it as a backup. So I just changed its extension from .exe to .old.

Then I ran winetricks and the related steps (above) again. But this time, the Winetricks screen asking “Which package(s) would you like to install?” had checkmarks for several files already: comctl32, ie6, mfc42, msls31, vcrun6, and vcrun6sp6. I guessed this meant that Winetricks was keeping track of everything that had been installed so far, and this was the total list: it included the ie6 package that I was trying to install now, as well as the mfc42 package that I had installed previously, when fiddling with IrfanView (above). Apparently these others (e.g., msls31) were installed along the way with ie6. Anyway, I left that screen unchanged and just clicked OK. That seemed to finish without problem.

There didn’t seem to be anything else to do in Winetricks, so I canceled out, returned to Terminal, and re-ran the “wine Setup.exe” command. But I still didn’t get past the “Invalid Serial Number” message. The IE6 addition may or may not have been helpful, but now I found myself looking again at the Adobe webpage suggesting that I try installing Acrobat in a simplified mode on Windows XP. A revised search led to a variety of pages, such as an Adobe Forums discussion in which people who had spent hundreds of dollars on Acrobat were receiving no technical support to help them past “invalid serial number” errors despite entering the correct serial number. An Adobe help page for Creative Suite (which I was not installing) suggested that one solution (among several suggested there) would be to click “Install the trial version,” for now, instead of trying to enter the serial number. I clicked the Back button in the dialog and did that. I was then able to proceed to the Custom Setup dialog, where I opted out of various unneeded languages, as well as Create Adobe PDF and Adobe LiveCycle Designer. The installation went ahead for several minutes. I stepped away. When I came back, I saw this message:

Setup Interrupted

The wizard was interrupted before Adobe Acrobat 9 Pro – English, Français, Deutsch (9.3.0) could be completely installed.

Your system has not been modified. To complete installation at another time, please run setup again.

A search on that message led to just a few results. These included several suggestions:

  • Take steps that would be more applicable to a native Windows installation (e.g., make sure you are logged in as the administrator; temporarily disable antivirus). This advice did not seem to help anyone, in the posts I saw.
  • Run the Adobe Reader and Acrobat Cleaner Tool. I did see one indication that this advice helped someone, but several indications that it did not. The Tool’s instructions indicated that, at least for Acrobat 9, it was intended only for a standalone version, not for software that was part of Creative Suite. The instructions also said, “The tool should only be used when a regular uninstalls fails or when an install fails on a machine where an earlier version of the product was installed.” The concept appeared to be that a previous failed install might not be cleaned up by the installer itself. I did have a previous failed installation attempt (above), but I wondered whether the more effective step would be just to start over with a fresh VM.
  • For a Creative Suite installation, one user did find a solution in the advice to review log files and troubleshoot issues highlighted there. Log files were apparently .log.gz files located in something like Program FilesCommon FilesAdobeInstallers. This VM had no Installers folder at /home/[username]/.wine/drive_c/Program Files/Common Files/Adobe. There were also no folders that could contain logs at drive_c/users/[username]/AppData or Local Settings.
  • There was a suggestion to kill the installer as soon as it started to roll back (a phase I had not been present to witness), and then look in the installation folder for an executable file to run Acrobat. On my Windows machine, that folder would probably be C:Program Files (x86)AdobeAcrobat 9.0Acrobat. This installation did have an Acrobat.exe file in /home/[username]/.wine/drive_c/Program Files/Adobe/Acrobat 9.0/Acrobat. Possibly there had been no rollback; possibly it had not gotten deleted as it would in a native Windows installation. I tried right-click > Open With > Wine Windows Program Loader. That produced a dialog with an unreadable line that turned out to be a choice of language. I chose and clicked OK. Next, I got a message:

Licensing for this product has [unreadable]

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.

That suggested that the problem I was encountering might have been created during the first installation attempt, when I was attempting to install with a serial number and was running into licensing issues. (Later, I found the solution suggested in the comment following another post: essentially, enable FlexNet Licensing in msconfig and then enable it in services.msc.) It did appear, in other words, that a clean start might make the difference. I killed the installer, and saw at that point, in Dolphin file manager, that the Acrobat.exe file was gone and that icons for others (notably Acrobat.dll) had turned into yellow warning triangles with exclamation marks inside them.

Finally, I looked at the Terminal session where I had run the “wine Setup.exe” command. It contained a few dozen error messages. It was hard to know which one might be important. None were obviously critical. When I killed the installer, a last line appeared in Terminal:

err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.

A search for that error led to the interpretation that this meant I should install winbind. I did that, in Synaptic. It also occurred to me, belatedly, that perhaps I should have set wincfg to emulate Windows 7 rather than Windows XP for this purpose.

The Adobe help page for Creative Suite (above) offered one other suggestion: create a new user account and reinstall the product. That was consistent with the idea of starting over with a new VM.

Starting Over

I started again from the beginning, realizing belatedly that I should have made a copy or snapshot of my VirtualBox VM, so that I would not have to redo all of the Wine installation and configuration steps. Summarizing and in some instances reorganizing the steps detailed above, I proceeded as follows:

  • Shut down the Linux VM. (These virtual machine steps would not apply to someone installing Linux on bare metal; they would just have to go through the process of reinstalling the system.)
  • As described in another post, I was using VirtualBox Portable. This seemed to reduce some errors arising from incorrect deletion of old VMs. In this case, in VirtualBox, I selected the confused VM > Machine > Remove > Delete all files. Then I created and configured a new Linux VM. (Later, I would realize I had forgotten to enter this command: “sudo adduser $USER vboxsf” and then reboot the VM so that I could access the shared folder I had configured in the VM setup.)
  • I started up the Linux VM > Software Sources > choose official repositories > add “ppa:ubuntu-wine/ppa” to the PPAs tab > uncheck the Sources PPA > Update the cache > close Software Sources.
  • In Synaptic, I selected and installed wine1.8 and winetricks, and then closed Synaptic.
  • There was not yet any /home/[username]/.wine folder, so I did not need to delete it. Instead, in Terminal I entered “WINEARCH=win32 winecfg,” and then approved the dialogs offering to install Mono and Gecko. When the Wine Configuration dialog opened, I went into its Applications tab and specified Windows 7 > OK.
  • Among the messages that command generated in Terminal, I noticed the winbind error mentioned above, so I went back into Synaptic and installed that.
  • I went to /home/[username]/.wine/drive_c/windows to see if there was a syswow64 folder. There wasn’t. At the command line, I entered winetricks. I got no warning about using a 64-bit version. Apparently I was running 32-bit Wine, as desired.

That really took only a few minutes, now that I had some concept of what I was supposed to be doing. At this point, I shut down the VM and made backups, both by using the Snapshot tool in VirtualBox and by creating a zipped copy of the folder containing the Linux Mint .vdi file as well as the VirtualBox Portable subfolder pertaining to that .vdi file (in data.VirtualBoxMachines). Then I restarted the VM and continued catching up with the remaining steps described above, as follows:

  • So far, my explorations with Wine had taught me that I needed to install several things via Winetricks. So I entered winetricks on the command line > Select the default wineprefix > Install a Windows DLL or component. I tried selecting both ie6 and mfc42, reasoning that I was going to need them both sooner or later. I had already downloaded the msie60.exe file for ie6, so I killed Firefox when it opened the page. But Winetricks gave me an error message. Oops. I had forgotten to put a copy of msie60.exe into /home/osboxes/.cache/winetricks/ie6. I did that now, and then re-ran winetricks and again clicked both ie6 and mfc42. This gave me the “sha1sum mismatch” error again. Apparently that was a normal part of installing IE6. As requested, I renamed IE5.01sp4-KB871260-Windows2000sp4-x86-ENU.exe to .old and re-ran winetricks again, this time just going with whatever was selected. Winetricks finished. I took a look at what was installed, and saw that mfc42 was not included. Apparently the user was to proceed one item at a time in Winetricks. I added mfc42 now, but did not yet proceed to test IrfanView.
  • The hypothesis from the previous Acrobat installation attempt was that I had screwed things up by fighting with the system about my serial number — that, instead, I should have selected “Install the trial version” for starters, adding my serial number later. So now I typed “wine Setup.exe” in the folder where the Acrobat installer was located.

That process terminated again with the “Setup interrupted” error (above). This time, from watching messages appear in Terminal while the Acrobat installer ran, it looked like this was the crucial error message:

err:msi:ITERATE_WriteRegistryValues Could not create key L”Interface\{34A715A0-6587-11D0-924A-0020AFC7AC4D}”

A search for that exact message produced nothing, but a more general search led to (1 2 3) indications that this might be the result of a bug in Wine. There was a separate suggestion that this problem, or something like it, could result from a conflict between Microsoft’s .NET and the Linux Mono package.


In another post, I discussed alternatives to Adobe Acrobat. The present inquiry yielded what was, to me, the surprising information that people were spending large amounts of money to buy Adobe’s expensive Acrobat software, and yet were being denied technical support to such a point that their purchase was useless. I took this as a strong argument that, whenever I next needed to buy Adobe software, I should take its competitors seriously.

On the question of why I could not get Acrobat to work in Wine, when others had succeeded, one possible answer was that the bug at issue here (if a Wine bug was indeed responsible) might have been introduced in a relatively recent version of Wine. A possible solution in that case would involve using an older version of Wine. I was not presently inclined to do that because I assumed that the newer versions fixed more things than they broke. There were other Windows programs that I wanted to run, and I believed that the newer Wine would be helpful on balance for that purpose. But it presumably remained possible to install a different wineprefix, for an older Wine, and use that to run Acrobat and perhaps other programs.

I hoped those quandaries would be resolved. In the meantime, it appeared I would have to run Acrobat in a Windows VM if I wanted to run it at all. For at least the short term, the primary benefit of this post, to me, was that it provided the boiled-down summary of how to use Wine provided in the Starting Over section (above).


It occurred to me, later, that some of the people who reported success in getting Adobe Acrobat to work might actually have been referring to the confusingly named Adobe Acrobat Reader. I was able to get Reader to work. I noticed, by contrast, that PlayOnLinux reported virtually no success with Acrobat Professional.

There was a suggestion that a newer version of Winetricks might make the difference. When I was installing PlayOnLinux to run Reader DC, I saw that it installed a newer version of Wine. I wasn’t sure whether it would also install a newer version of Winetricks, if the need arose. I tried: in the PlayOnLinux GUI, I went to Install > Install a non-listed program > Install a program in a new virtual drive > 32 bits windows installation. With that information, PlayOnLinux created a virtual drive for Acrobat.

Next, I had to browse to the Acrobat installer. Having learned from the Reader effort, I made sure a copy of that installer was on the Linux desktop, not on an NTFS drive. I tried the Cameyo package first. That package was huge (1.8GB), but it contained the desired updates and settings and, as always, I hoped it might ultimately be simpler for Wine to handle. Acrobat opened immediately, though it looked like PlayOnLinux was still struggling to wrap its head around that massive installer. In Acrobat, unfortunately, the menus were not responsive; for example, Edit > Preferences did not open the Preferences dialog.

I allowed PlayOnLinux to struggle for maybe ten minutes — a period far longer than I would be willing to wait for ordinary Acrobat functionality — and then tried again with the regular Acrobat installation program. The installer claimed that my serial number was invalid, so I told it to install the trial version. I chose a Custom installation and set seemingly unnecessary features to Install on Demand. This gave me the usual “Setup was interrupted” message. That seemed to terminate the process.

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

One Response to Trying to Run Adobe Acrobat 9.5 in Linux via Wine

  1. xChris says:

    Acrobat 8.1.0 (pro not ‘reader’) can be installed and works using wine-staging ( , tested with ubuntu 16.04

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.