I have wine compiled with win32 and win64 use flags, but I'm having trouble installing a software here. The solution was to create a 32bit prefix and running wine with WINEPREFIX="32bit_prefix" and WINEARCH="win32". But messing around with equery f I've found wine already installs wine and wine64 binaries, that are indeed 32 and 64bit ELF files, inspected by the "file" command. But they both seem to think that my windows "installation" is still 64bits. Even using /usr/bin/wine makes that installer crash, but if I force a new WINEPREFIX and WINEARCH=win32 everything goes alright. I think a wrapper script to export WINEPREFIX and WINEARCH for /usr/bin/wine and /usr/bin/wine64 would be great. I don't like messing with portage packages files, so I guess doing it in the official ebuild/portage tree is required. Reproducible: Always Actual Results: Software installs ok using wine, maybe not with wine64, but definitely ok with usr/bin/wine. Expected Results: The InstallShield Wizard crashes in the initialization phase, before user input.
it should "just work" without need for wrappers
Could you expand that? See, "wine uoml_setup.exe" crashes. If I try setting WINEARCH=win32, wine would complain about having a 64bit prefix. So I end having to create a new prefix folder and forcing WINEARCH=win32. That's basically why a wrapper would be needed. The problem is that wine is creating a 64bit WINEPREFIX, it seems. I could generate some logs, if you wish. But I don't know what exactly. Running those commands, maybe?
I can reproduce but I think this is an upstream issue. Is it also the case when wine is compiled by hand? Or it other distributions?
Hi, i also thought it was this problem, however, it seems, WINEPREFIX must be a full path starting from "/". This somehow did the trick for me it seems...
P.S.: Doing winecfg with the same prefix/arch before as well.
I am also suffering this problem :|
I assumed that WINEARCH=win32 was /the way/ to create a 32-bit prefix, while the "default" is 64-bit. This makes partial sense to me, as it (in principle) runs both 32- and 64-bit executables. The man page doesn't really address the issue of defaults, is there documentation somewhere that the current behaviour is not intended? Does wine behave differently on other distros or in previous releases?
There are three issues: 1. An install executable for some unknown application crashed when some wine version in 2011 was built with 32- and 64-bit support. If this bug still occurs (please test with the latest ~amd64 version of wine, currently 1.5.25), it needs to be reported upstream, because this should "just work". 2. Does our default - win32 and win64 both enabled - make sense? Note that switching to win32-only by default is not a decision to make lightly - it would break ~/.wine for current users, forcing them to reinstall all of their emulated windows software. 3. We probably need some documentation for WINEARCH and WINEPREFIX at https://wiki.gentoo.org/wiki/Wine
Much like eroen stated in comment 7, I, too, used to think that the behaviour makes sense (64-bit default). After reading this bug the first time some months if not weeks ago, I guess I started to really think about it for the first time ever. I might now be of the opinion that 32-bit should be the default for the following reasons: 1. I have never had the need for a 64-bit prefix, except for when I'm testing applications; mostly I /need/ to use a 32-bit prefix due to certain msi and internet explorer bugs (not installing in a 64-bit prefix). 64-bit applications in general are probably quite rare, still, so it really doesn't have much uses currently for the regular user at least, or at least I do not know of them. 2. The 64-bit Wine is still considered experimental (http://wiki.winehq.org/FAQ#head-b89ca9d7cdf2bc2ddfb23b3e5829219df48524f8): WineHQ FAQ - 2.4. Does Wine run on 64-bit? Yes. Normally, installation should be the same as with 32-bit: simply install the Wine package for your distribution. Check the Downloads page. If you need to build Wine from source, see WineOn64bit. Note that Wine for 64-bit actually runs in 32-bit mode. This is necessary, as virtually all Windows applications are 32-bit. Support for 64-bit Windows applications is currently experimental (see Wine64). Wine is currently offered in 32-bit. 16-bit and 32-bit Windows applications work with it. It runs on both 32-bit and 64-bit Linux/Unix installations. Wine is also experimentally offered in 64-bit. 32-bit and 64-bit Windows applications (should) work with it. It runs only on 64-bit Linux installations. ---- Regarding the first comment of the bug, I believe there might have been a bit of the very common confusion going on. For example, the 'bitness' of a prefix can not be changed after its creation, which is why Wine will complain when setting WINEARCH=win32 for a win64 prefix. It's working as intended (as far as I can tell). Changing the default might have less impact than one might think, actually, but I do agree that it should probably not be done lightly, and if it would come to pass, proper notifications should of course be included (obvious, I guess). I have been meaning to see if I can make some wikki editing for a long time, and have been thinking of starting with the Wine article, but simply haven't got to it yet. Maybe soon! :/ Just some thoughts~
After mentioning things in IRC, austin987 pointed out that 64-bit is not really considered experimental any longer, which I have been wondering about, actually. That is, the FAQ was indeed a bit out-of-date on that part, as I had suspected, and the feeling of 64-bits (where available) being the default was more or less correct, I guess. It generally works quite well indeed, and if there is a need for a 32-bit prefix for certain applications, it's easy to set up once a user learns of them environment variables a bit. New link to the updated FAQ: http://wiki.winehq.org/FAQ#head-53474b6887d5ea543ddba8331734bf54a8cbe60d I think I am leaning back towards the “It's fine as it is now”. That is, 32-bit and 64-bit Wine being built by default (where possible) is good. I had a small chat with austin987 about it, who would not recommend getting rid of it either. Just some (more) thoughts.
After a very long time I'm back at this problem. I don't care about the uoml_setup.exe program (installer for Ultima Online Mondain's Legacy) anymore, that was just related to installed a 32bit program into a 64bit prefix. What was at stake here was that on amd64 Gentoo, the wine binary, the one that runs programs as a 32bit version of Windows, created by default a 64bit prefix. Isn't that kind of strange? I understand that 64bit prefixes are somewhat stable by now, but I find that funny. I now understand fully that we should use WINEARCH to force a 32bit prefix, but I find that a bit odd still. Anyway, since I don't care to test uoml_installer.exe again, I think it's time to close this bug as invalid.
