Forums

I have the Problem, that a Program I wish to install has x64 and x86 components. And I'm not able to install a x86 only. But in x64 I'm not able to run x86 .exe Files and vice versa. Is there a Hack to run both in the same prefix?

64bit builds should run most 32bit programs fine (the 64bit Wine packages are roughly twice as big because they actually embed both 32bit and 64bit support).
That said, many components only install in 32bit prefixes, so there may or may not be a solution to your problem.

This question requires more details, OS version and hardware.

To fix a similar problem in my Debian 7.2/wheezy install on AMD64 kernel, the "fix" was to go multi-architecture and install the i386 version of every instance of ligGL 64bitlibraries possible(not conflicting with 64bit version.

My video card is an AMD HD 7790 which has a special driver for it. Search lead to a post on devgurus.amd.com from someone who claimed to have the 64 & 32 bits working on his version, plus he outlined the steps he undertook.

Basically, it was install the driver, remove the driver, then install the driver again.
Shrug, that fixed my setup for POL.

You can also use the 64 & 32 bit versions of glxinfo to see if direct rendering is working. In debian, glxinfo is in mesa-utils and by shuffling one or the other in, I could see which libraries were recognised. Hint, install 32 bit version, then rename it to glxinfo32 and install the 6 bit version back and you have both.

So, firstly web/? search and see if someone has a fix.

64 bit wineprefix are not supported. They have many issues, and all of them are directly related to Wine. Wine 64 bit is VERY experimental. Do not expect it work correctly, but for sure test and find bugs and report to Winehq.org. It really makes a difference.

90% of what is available on here is 32-bit, and thats just because 64 bit is not at the point where its stable enough to support efficiently. Unless you have a specific reason to run 64-bit, then run 32-bit. If its a driver install issue, that is a distro issue, not a wine/POL issue, and your distros support forums should be consulted.

Be that as it may, I run 32 bit stuff all day, and I dont run into any issues. A regular 32-bit prefix works great, for most applications. If its 64 bit only or you specifically need it, consider it test, unsupported, and Wine would be the project to submit bugs to, as they have the resources and the community to add patches and fixes.

Your 64 AND 32 bit libs are supposed to replace the regular libGL.so files. AMD and Nvidia use proprietary versions of these files, hence the reason you cannot run the open source drivers and the closed source ones at the same time. Let it conflict and replace what its asking for, as its supposed to replace the mesa and lib32-mesa drivers.

My understanding (but I didn't use 64bit Wine much so far) is that 64bit Wine is rather stable now (it exists since Wine 1.1.15 or so, so it's not that new anymore), but many "components" only install and work well in 32bit virtual drives, so by the time you need any of them you have to use a 32bit Wine.
So, whereas the 32bit versions are kind of a safe bet, Wine 64bit can only be used for a much smaller set of programs, and for little benefit (support for more memory, potentially a small performance gain).
The drawback is that you need to install lots of 32bit libraries, often for this only purpose.

Really? Thats good to know. I was experimenting with 64 bit prefixes the other day (Ableton, for instance, its good to have LOT of RAM accessible because of loading multiple built-in virtual instruments that take up a lot of head room), but it just was not making the cut.

With this in mind, this gives me a little incentive to start testing 64 bit prefixes and seeing if 64-bit functionality can be built from existing 32 bit functions.

I stand corrected. lol. That notwithstanding, you are right; there is very little reason to use 64 bit besides memory, and multi-core CPU usage, but Im not sure if 32 bit supports multiple cores or some sort of faux hyperthreading. I never really bothered to check. I do know that Ableton and Reason act grumpy and molest the CPU real bad if there is multicore support options active.