Can't get wine to run 64-bit .exe programs
 

I am running Ubuntu 10.04 LTS and have wine-1.4 installed using aptitude. When I try to run a 64-bit application (specifically, the Houdini_15a_x64.exe chess engine within Arena 3.0), I get error messages stating that my wine installation is 32-bit. The error message is:

I've searched the Web extensively and found various highly complicated instructions for enabling 64-bit support in wine (e.g. install a new version of gcc, run a convoluted script, etc.). I've tried some of this without success, but this should not be necessary; wine should support 64-bit programs by default. I've tried running winecfg, and I've tried

but then running "wine program.exe" produces the error message:

I also tried "sudo apt-get remove wine" and then installing wine-1.5.4 from source. This didn't help, so I did "make uninstall" and reinstalled wine from aptitude.

Surely there is some simple way to install wine in Ubuntu 10.04 so that it will run both 32-bit and 64-bit Windows programs. Can anybody enlighten me as to what that simple way is? (Instructions for other versions of Ubuntu as well, while not helpful to me, would be helpful for others.)

wine has to be specially compiled and then packaged (see this page to get an idea) to support both 32 and 64 bit executables at the same time. Given that the majority of Windows programs is still 32 bits, the package you installed probably only contains the 32 bit runtime for wine.
This only means that the WINEPREFIX which got previously created by your first tries contains a 32 bit "installation". You only need to remove it
for that error to disappear. If the WINEARCH variable is still set to win64 the next time you launch wine, that WINEPREFIX will be hopefully be recreated from scratch and it will contain a 64 bit "installation".
Your 64 bit Windows program should now at least start if the package of wine you installed contains the required 64 bit support for wine.

You don't need to delete the old wine configuration, you can just create a new one, named differently, for example withThis will create a new wine installation named .wine64 in your users home-directory. Keep in mind that you have to set WINEARCH and WINEPREFIX every-time you want to run a program in that installation, do it may be more convenient to use an alias or a script to start your 64 bit application.

Yes, I am aware of the wine wiki "Win64 Support for Wine"; it was that page I was alluding to when I spoke of highly complicated instructions for enabling 64-bit support in wine including compiling a new version of gcc, which in turn requires resolving a huge number of unmet dependencies, etc. I'm not willing to try this on my main computer, since destroying gcc would be a major problem for me. (I have gcc version 4.4.3, the latest version for Ubuntu 10.04.) I tried compiling gcc 4.5.1 on a spare computer using the script provided on the "Win64 Support for Wine" page but eventually gave up on it when it required new installations of a great number of packages.

By the way, about the majority of Windows programs being 32-bit -- given that everyone on earth today is running 64-bit hardware, I have no idea why anyone would be writing 32-bit software, or why the standard installation of wine that you get on Debian/Ubuntu with "sudo apt-get install wine" can only accommodate 32-bit software. Perhaps developers would care to offer some explanation of this ridiculous state of affairs?

In any event, following TobiSGD's advice, I tried

from the command line, and got the error:

What else might I try?

And one more thing: on Wine64 - The Official Wine Wiki one is instructed to run the commands

Apparently this assumes you've compiled wine from source rather than installing it with "sudo apt-get install wine" (as I have). Otherwise, in which directory are you supposed to run "./configure"? (It certainly doesn't work in $HOME/.wine or $HOME/wine64.) Running the second set of commands quoted above produces the error

(exactly as one would have expected).

Of course. As I said before, the package you installed probably contains only the 32 bit wine runtime environment. You'd have to compile wine from source to obtain 64 bit compatibility or find someone who already did that and packaged it for the masses.

Maybe you are hitting yourself against a wall here.

Do you have a 64 bits OS at all? Can you post the output for "uname -a" here?

Wine is not an emulator, in the traditional sense. I am no specialist in wine, but it works by translating windows calls into their linux/xlibs and a few other libs conterparts. The translation is straight enough that I highly doubt that you can translate win64 syscalls to linux32 syscalls. In other words, you can run wine 32 in linux 32, you can run wine 32 in linux 64 (because linux 64 with ia32 enabled in the kernel can natively run 32 bits code), you can run wine 64 in linux 64, but you CAN'T run wine 64 in linux 32. That is, unless I am terribly wrong here.

In any case, as said above, you definitely can't just magically changed the wine bitness by setting a variable. You need to recompile it. But you need a 64 bits OS to be able to do that. I am obviating the obvious: of course, you also need an x86_64 capable cpu.

If your OS is a 32 bits OS, you will need to install the 64 bits version (if there's one, I guess there is, but have no experience with *buntu).

You don't have much choice. You need a 64 bits OS for this.

Well, that's not true, there's a world beyond x86 and x86_64, you know... You probably have an arm cpu somewhere, in your pocket, in the form or a table, a video console or a mobile phone. But in any case you don't write software for 32 bits, you just write software, and then you compile it for a given cpu, that can work in 32 bits, 64, 128, or in many of these modes at once. That's up to the compiler, not the developer (unless you are using assembler of course).

In any case, note that the wine case is special. The last time I checked, and because of the low-levelness of this concrete software, wine cannot run 32 bits exe files if its been compiled for 64 bits. That's (or was) the reason why, even 64 bits distros, usually offer the 32 bits version of wine, which is what most users will want because most windows software is still compiled for x86 (not x86_64). Or better said, in most cases, you can always find a 32 bits compilation of a given program, but you can't always find a 64 bits build of it. Some windows programs might not even compile easily for 64 bits, because windows programmers are not the kind of programmer who care about portability of the code, and do lots of assumptions. I don't like to generalize, but this disease is more common in windows than in any other OS, that's a fact.

Message is clear. You need a 64 bits wine build, and for that, you need a 64 bits OS. If your OS is 64 bits-able, then you are one step nearer.

You need to get the sources first. The configure script is in the wine sources. So, pick the latest from here:

http://www.winehq.org/announce/1.5.5

It seems it's in tar.bz2 format, so you should be able to download and unpack it using these:

From here, you will need to use ls and cd to check what's in there and change to the proper directory, the configure script should be in there, and follow the instructions in the wiki to compile it in 64 bits mode.

As said above, this will only work if you have a 64 bits OS, and all the needed devel packages installed.

Thank you for your reply, i92guboj. The output of "uname -a" is:

So there should be no problem, right?

Okay, I'll try compiling wine-1.5.5 from source on my spare computer, although I'm uneasy about what might break if there are problems with gcc version 4.4.3. I don't suppose "sudo add-apt-repository ppa:ubuntu-wine/ppa ; sudo apt-get update ; sudo apt-get install wine1.5" is a viable alternative?

Sorry, but I disagree with the statement that you don't write software for 32-bit or for 64-bit machines but rather that you just write software. For instance, a C program containing

is certainly written for a 64-bit system, and the program will not work as intended on a 32-bit system. In any event, some Windows programs are written to make full use of 64-bit computers, and wine "out of the box" really ought to be able to accommodate those.

Right, as long as your kernel has IA32_EMULATION turned on in your kernel. You can easily check that as long as /proc/config.gz is enabled also.

I don't know if ubuntu enables any or both of these, though.

gcc in a binary distro like ubuntu shouldn't be a core piece of your system (breaking it in a source distro like Gentoo IS indeed problematic, though). In ubuntu you don't need it to install packages, so you can always revert if something goes wrong. However, don't install it by hand outside your package manager (if you are going to install it at all), because that can live behind leftovers that can, indeed, produce unexpected side effects later.

About the apt-get and repos stuff, sorry, I'm afraid I have no idea about *buntu specifics. Someone else will have to answer that.

I politely disagree with you, in turn :)

Note that the range that the c99 standard fixates for unsigned long ints is 2^32-1, if you are trying to set an unsigned long int variable to a value that's bigger than 2^32-1, relying on a specific platform "feature" (to call it something) then the problem is yours. The bitness of a program, in any case, is never defined by the constants you write on the source code. You are simply using the wrong data type for that variable, nothing else. The compiler behavior in this case will be undefined, and each compiler you try might do a different thing... It might even work in some compilers, and it might produce unexpected results, but this is a human error and has nothing to do with your program being specific to 64 bits.

Otherwise, you could just set that number higher than 2^128-1 and claim that you are using a 256 bits program, it truly doesn't work that way ;)

That's a side effect of the power that C gives us to control everything without putting too much boundaries to what we can do. One of the problems of this is that the programmer is the one to take care about the correctness of the input data, it doesn't really matter if you are putting it into a program as a textual string or if you are reading it via some function or syscall (though admittedly, in the later case the number of things that could go wrong is higher).

It's true that you *can* program for 64 bits or 32 bits (or something else), but platform specific code is some other thing. It has nothing to do with your assigning one number or a slightly bigger one to a given variable.

About the wine internals, I won't argue because I never looked into them and I lack the background to do so. In any case, even if wine supported this feature, the distributions would still need to ship 32 and 64 bits versions of xlib, libpng, alsa, sdl, openal, libmp3, the opengl stack including the drivers, which might be proprietary making it even funnier... All that, along with the 64 bits native ones, and provided the needed mechanisms to handle then at fs level without ones colliding with the others (i.e. be careful with what /lib and /usr/lib points to to effectively separate lib32 and lib64, besides a couple other things).

In fact, if distros really cared about running 64 bits windows binaries they could perfectly pack to packages called "wine" and "wine64" and install them in different prefixes with their respective subset of libraries compiled for the correct bitness. So, there's nothing stopping them from doing so, besides the lack of interest. It would be nicer to get the same wine binary to run both kind of builds, but that's not a show-stopper at all.

I personally used wine for a while on Arch Linux 64 bit and it installed automatically necessary 32 bit libraries and also used by default 64 bit prefixes (which in fact meant that for some older programs I had to specifically create 32 bit prefixes).
I would be surprised if that wouldn't be the case on Ubuntu also.