wine wow64 and winetricks at x64 wine

Is wow64-support for wine in the works? Wine supports wow64 since years but many distro's didn't seem to implement this very well or not yet.

Winetricks is also not working for 64-bit wine, since there is more and more applications who drop x86 support i start to need it. There is no workarounds anymore. Would be nice if someone could answer me how to use winetricks on 64-bit wine and if it is possible to get wow64-support any time soon.
 
No, regarding FreeBSD implementation at this moment WOW64 is not supported on Wine64 (even for Wine Staging version)

On the contrary, I have a linux machine where I can install side by side Wine32 and Wine64.
I think WOW64 is working well on Linux, sometimes required when the program has a mix up of 32 bit and 64 bit executable files and dll

If you want to install 32 Bit windows programs on FreeBSD amd64 you must deinstall wine64, and install i386 Wine, which is a special version of Wine 32 for amd64 architecture

The Wine 32 for FreeBSD i386 is handled by the default port Wine

If you want to install both 32 and 64 wine version you will need to play with jails, but it won't solved the problem if the package is a mixup of 32 and 64 bits executables and dll, in such case WOW64 is required.

Also sometimes the windows program is a true 64 bit, but the installer is a 32 bit archive, so you can't install it on Wine64

I have the same problem as you, and waiting impatiently for implementation of WOW64.

In fact reading your post I think you make a misinterpretation

WOW64 = Windows on Windows 64 = 32 bit programs running on Windows 64 bit AND NOT Windows 64 bit programs

So :

- first WOW64 only applies to Wine64. This requires FreeBSD amd64, and this is handled by default ports Wine (or wine staging) which automatically switches between 32 and 64 bit architecture, as opposed to the special package i386 Wine, as quoted before.

- second : if your Windows program is a full 64 bit it should install on Wine64, unless you are blocked by this f... exe archive running old 32 bit
 
So far i found out that compiled winebuilds from winehq have a "wine" link inside the mainfolder that can be used to start programs with this compilation without installing it on your system via pkg or ports. This means you can use any i386 and x64 version of wine on your freebsd-system at same time.
 
While there is no wow64 wine package for FreeBSD, there exists an embarrassingly simple workaround:
1. install i386-wine-$version package;
2. unpack wine-$version package without installation to /opt/wine64-$version (or whatever path you prefer);
3. prepend /opt/wine64-$version/usr/local/bin to $PATH;
4. make sure to use the wine64 command instead of the wine command for launching both 32-bit and 64-bit types of windows executables.

At least that's good enough to run a couple of games on Steam. Note however that wine64 under FreeBSD is a bit flaky: I had to blacklist gameoverlayrenderer.dll (Steam overlay) in winecfg to run 32-bit games that way, there is slightly crackling sound in 64-bit games and there are probably dozens of other issues.
 
second : if your Windows program is a full 64 bit it should install on Wine64, unless you are blocked by this f... exe archive running old 32 bit


While there is no wow64 wine package for FreeBSD, there exists an embarrassingly simple workaround:
1. install i386-wine-$version package;
2. unpack wine-$version package without installation to /opt/wine64-$version (or whatever path you prefer);
3. prepend /opt/wine64-$version/usr/local/bin to $PATH;
4. make sure to use the wine64 command instead of the wine command for launching both 32-bit and 64-bit types of windows executables.

At least that's good enough to run a couple of games on Steam. Note however that wine64 under FreeBSD is a bit flaky: I had to blacklist gameoverlayrenderer.dll (Steam overlay) in winecfg to run 32-bit games that way, there is slightly crackling sound in 64-bit games and there are probably dozens of other issues.

I think I need this, I have one 64-bit game with a stupid 32-bit installer, also I would like to try the doom4-demo from Steam, but Steam itself is 32-bit, while the demo is 64-bit.

So could you please explain better steps 1 - 4, I mean with exact commands, please? I do not understand everything very well expressed like that. Step 1 is pretty clear to me, it would be pkg install i386-wine or pkg install i386-wine-devel, but the rest???
 
Step 1 and 2 mean something along the lines of
Code:
sudo pkg install i386-wine
sudo pkg fetch wine
sudo mkdir /opt/wine-3.0
cd /opt/wine-3.0
sudo tar -xf /var/cache/pkg/wine-3.0,1.txz

And for steps 3 and 4 make a run_steam.sh script with contents:
Code:
#!/bin/sh
WINEPREFIX=~/.wine-wow64
PATH=/opt/wine-3.0/usr/local/bin:$PATH
wine64 $WINEPREFIX/drive_c/Program\ Files\ \(x86\)/Steam/Steam.exe -no-cef-sandbox
 
Code:
sudo pkg install i386-wine
sudo pkg fetch wine
sudo mkdir /opt/wine-3.0
cd /opt/wine-3.0
sudo tar -xf /var/cache/pkg/wine-3.0,1.txz

This is a really nice simple solution, and I thought I could adapt it a bit to avoid installing either of the wine packages into my base system (and keeping wine contained to a "wine" user/group) by doing the following;

1) Created a "wine" user and group
2) Fetched both "i386-wine" and "wine" packages using pkg fetch
3) Extracted both packages from /var/pkg/cache into /home/wine/wine32 and /home/wine/wine64 respectively
4) Created a shell script explorer.sh to set the prefix, paths, etc, for running explorer.exe (see snippet below)

Code:
#!bin/sh
WINEPREFIX=~/.wine
PATH=~/wine64/usr/local/bin:~/wine32/usr/local/bin:$PATH
wine64 $WINEPREFIX/drive_c/windows/explorer.exe

This seemed to be working ok, so downloaded the game FTL from GOG and installed it without issue through windows explorer using the above script. I then created a new script ftl.sh to run the game as follows;

Code:
#!bin/sh
WINEPREFIX=~/.wine
PATH=~/wine64/usr/local/bin:~/wine32/usr/local/bin:$PATH
wine64 $WINEPREFIX/drive_c/GOG\ Games/FTL\ Advanced\ Edition/FTLGame.exe

However, when I run the script I get the following error;
Failed to load libGL: Shared object "libGL.so.1" not found, required by "wine"

I thought I may also need to set LD_32_LIBRARY_PATH in the ftl.sh script so tried adding the following to no avail;

Code:
LD_32_LIBRARY_PATH=~/wine32/usr/local/lib32:~/wine32/usr/local/lib32/wine:$LD_LIBRARY_PATH:/usr/local/lib32:/usr/lib32

Any ideas what could be the issue and how to fix? It's probably to do with ldconfig and the paths but I can't figure it out! :-(

Thanks,
James
 
Actually, I almost convinced salvadore@ (the new i386-wine maintainer) to build these packages with WoW64 by default. You might want to ask him whether there has been any progress on that front.

Failed to load libGL: Shared object "libGL.so.1" not found, required by "wine"

Intel/AMD GPU? See the /usr/local/lib32/.libGL directory in the i386-wine package.
 
Intel/AMD GPU? See the /usr/local/lib32/.libGL directory in the i386-wine package.

AMD RX580

I went back to installing the emulators/i386-wine package just to see what is different from the normal installation and the unpacking it into the /home/wine/wine32 directory.

With your help, I noticed there were some symlinks missing for libGL and dri in the lib32 directory;

I've added the following symlinks to my /home/wine/wine32 install;
ln -s .libGL/libGL.so.1 ~/wine32/usr/local/lib32/libGL.so.1
ln -s .libGL/dri ~/wine32/usr/local/lib32/dri

I can now run FTL purely from the /home/wine installation (even after removing the emulators/i388-wine
package from my system)!

Now to find a 64-bit game to run! :)
 
I'm positively struggling to find even a single person willing to help me to get these patches (there is more than one alternative WoW64 patch, yes) into the ports tree, seemingly only for you to come out of the woodwork with your general lack of self-awareness and supposed "improvements". Do you understand how offensive this is?
 
Excuse me, I removed my message, I didn't mean to offense you and I appreciate your efforts, I really do. I struggled myself enough with all this to get everything working and I understand how annoyed you must feel right now.
 
With friends like these… :rolleyes: WoW64 Wine is not quite the same thing as two separate Wine installations.

Oh, I was thinking running it in this way, with emulators/i386-wine (32-bit) installed under /home/wine/wine32. emulators/wine (64-bit) installed under /home/wine/wine64 and then putting both in the $PATH, was running WoW64 Wine, is that not actually the case, maybe I've misunderstood?
 

I was talking about Adrien2002's install-wine-devel-in-chroot-and-point-a-script-at-it method. It's not a bad idea per se, but it's a bit involved for a "lazy" method and it's still a (not particularly robust) hack.

with emulators/i386-wine (32-bit) installed under /home/wine/wine32. emulators/wine (64-bit) installed under /home/wine/wine64 and then putting both in the $PATH, was running WoW64 Wine, is that not actually the case, maybe I've misunderstood?

For WoW64 you have to make sure that your contraption actually starts 64-bit wineserver. The instructions above do this implicitly by avoiding starting Wine with the wine wrapper script from the i386-wine package which puts 32-bit wineserver in PATH before 64-bit wineserver. That's obviously not the best way to do this, the objective there was to keep the i386-wine package intact. If you are willing to modify things, you might as well just remove 32-bit wineserver altogether. That way you won't need to explicitly run wine64.
 
I was talking about @Adrien2002's install-wine-devel-in-chroot-and-point-a-script-at-it method. It's not a bad idea per se, but it's a bit involved for a "lazy" method and it's still a (not particularly robust) hack.

Yes, and posting it here wouldn't do any good to the port. I don't want my way to do to be a workaround, leaving the maintainer and people working for the port package struggling all alone, that wasn't my intention and I would prefer a more "official" method to use Wine too so I prefered to simply remove it. Sorry JAW for the misunderstanding that it created 😅
 
There is an example in a comment in the script itself.
Code:
1 #!/usr/bin/env ruby
2 # encoding: UTF-8
3
4 # DIY WoW64 Wine convenience script
5 #
6 # Usage:
7 #   % sudo pkg install wine winetricks
8 #   % w4 pkg install wine mesa-dri
9 #   %setenv WINEPREFIX ~/.wine-steam                  # export WINEPREFIX=~/.wine-steam
10 #   % setenv WINEDLLOVERRIDES "gameoverlayrenderer64=" # export WINEDLLOVERRIDES="gameoverlayrenderer64="
11 #   % w4 winetricks vd=1920x1080 steam
12 #   % w4 wine $WINEPREFIX/drive_c/Program\ Files\ \(x86\)/Steam/Steam.exe -no-cef-sandbox


OK thanks, but some things are still unclear to me:

First, as root, I do a pkg install wine winetricks (line 7). So far so good.

But then, as user, I do a w4 pkg install wine mesa-dri (line 8)? I don't get it. "w4" is the script itself, right? And I thought that a script is run either like sh script or ./script? So then, in the same line, as user comes a pkg install wine mesa-dri? Same question with lines 11 and 12. I suppose that line 11 refers to the maximum resolution of your monitor? So is line 11 really necessary?

Line 9 and 10: Is it either the setenv or export command, depending on the terminal you use?
 
But then, as user, I do a w4 pkg install wine mesa-dri (line 8)? I don't get it.
Well, thankfully, even if you don't get it, it still works.

"w4" is the script itself, right? And I thought that a script is run either like sh script or ./script?
First, this is not a shell script. Second, it's a usage example, not a complete guide to the filesystem on your machine. Save the script somewhere, chmod +x it, type a path to it.

I suppose that line 11 refers to the maximum resolution of your monitor? So is line 11 really necessary?
All lines are necessary (for Steam.exe).

Line 9 and 10: Is it either the setenv or export command, depending on the terminal you use?
Depending on the type of your shell.
 
shkhln let me necrobump this a little. I will try again later. Let's say I have one directory with a 32bit game and another directory with a 64bit game. Should I use w4 wine to both?
 
Let's say I have one directory with a 32bit game and another directory with a 64bit game. Should I use w4 wine to both?
Yes. Wine actually doesn't care whether you run a 32-bit (w4 wine) or 64-bit loader (w4 x wine64), it will always start a wineserver instance (or connect to an existing instance). Wineserver will test the type of executable and invoke the proper loader. The only time you need to care about this distinction is when you want to run a specific version of the joystick testing applet (wine[64] control joy.cpl).
 
Should I do any special chimichanga to 32-bit wine works with nvidia? It seems it doesn't work, I've copied some of the 32bit libs from nvidia-drivers to .i386-wine-pkg/usr/local/lib and it seems I'm still missing something. The error doesn't help much.
The gw.sh that I've executed is just a shell script with WINEPREFIX=path_of_wine_prefix w4 wine Gw.exe.

Screenshot-20210318-1935.png
 
Is that a legacy nvidia-driver? Generally no, you don't need to do anything special. You might want to run truss -f <cmd> |& grep libGL to verify that the correct OpenGL library is getting loaded.
 
Back
Top