unable to find an interpreter when running a Windows executable

Question

I uninstalled my wine, and installed a higher version of wine by compiling source.

However when I run an exe executable (whose path is in $PATH), it doesn't work as it used to:

$  PDFXCview.exe   

run-detectors: unable to find an interpreter for /home/tim/program_files/document/pdfxchange_portable/PDFXCview.exe

I am not sure why I was able to run this executable directly before I uninstalled my old wine and installed the new one. How can I make $ PDFXCview.exe work now?

Note:

$ wine /home/tim/program_files/document/pdfxchange_portable/PDFXCview.exe

will work.

$ wine PDFXCview.exe 

wine: cannot find L"C:\\windows\\system32\\PDFXCview.exe"

doesn't work. Note that the path of PDFXCview.exe is still in $PATH

Thanks.

Answer 1

I uninstalled my wine, and installed a higher version of wine by compiling source. However when I run an exe executable (whose path is in $PATH), it doesn't work as it used to.

As you have obviously seen the following works correctly

wine file.exe

---

but the following does not

# for a file in the current directory
./file.exe              

# for a file that is included your path             
file.exe

---

My version of wine is v1.8.3 from debian/jessie-backports and
should be valid back to, at least, v1.6.2 (which is the default in debian/jessie).

You must do the following:

sudo apt-get install wine-binfmt
sudo update-binfmts --import /usr/share/binfmts/wine

Now you should be able to execute the binary file as shown above,
without having to call it using wine.

The exe file must also be marked as executable:

chmod a+x file.exe

Answer 2

Linux has a mechanism that allows plug-ins to be registered so that the kernel calls an interpreter program when instructed to execute a file: binfmt_misc. See How does chroot's use of qemu for cross compile environments work? for a more detailed overview.

Your Wine package registered /usr/bin/wine as an interpreter for Windows executables as part of its installation script or via a startup script contained in the package. You can do the same for your home-built wine. Some distributions have a mechanism where packages can register interpreters which will then be registered into the kernel at boot time, for example update-binfmts on Debian and derivatives. Alternatively, an interpreter can be registered into the kernel during startup by writing to /proc/sys/fs/binfmt_misc/register. I recommend that you look at the package you used to have and adapt the method that was working before.

Answer 3

It should be caused by the conflict with systemd.

Please check the file /etc/wsl.conf and see if the systemd = true flag was added under [boot] settings as shown below. If so, please switch it to false.

For more info, please refer to https://learn.microsoft.com/en-us/windows/wsl/wsl-config#per-distribution-configuration-options-with-wslconf

Answer 4

Okay, listen carefully. This is what you do.

Place this in /usr/bin/pdfxcview.exe

#!/bin/bash
# Call up a command;
wine /home/tim/program_files/document/pdfxchange_portable/PDFXCview.exe

Then, invoke from Terminal:

$ chmod +x /usr/bin/pdfxcview.exe

^ Sets executable bit to on.

$ pdfxcview.exe

Source Code Differential

Isn't Freedom of Software Great? It seems there is commentary about path. If you print your environment by typing "env" you may see your Program Files directory.

Launchpad Librarian is where Ubuntu Developers keep documentation about their work keeping your system up to date and secure.