# wine wow64 and winetricks at x64 wine



## Yelphos (Sep 29, 2017)

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.


----------



## Wozzeck.Live (Sep 30, 2017)

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


----------



## Yelphos (Oct 5, 2017)

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.


----------



## shkhln (Dec 31, 2017)

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.


----------



## cabriofahrer (Jun 14, 2018)

Wozzeck.Live said:


> 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






shkhln said:


> 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;
> ...



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???


----------



## shkhln (Jun 14, 2018)

Step 1 and 2 mean something along the lines of

```
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:

```
#!/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
```


----------



## JAW (Jun 20, 2020)

shkhln said:


> ```
> sudo pkg install i386-wine
> sudo pkg fetch wine
> sudo mkdir /opt/wine-3.0
> ...



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)


```
#!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;


```
#!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;


```
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


----------



## shkhln (Jun 20, 2020)

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.



JAW said:


> *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.


----------



## JAW (Jun 20, 2020)

shkhln said:


> 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!


----------



## shkhln (Jun 21, 2020)

With friends like these…  WoW64 Wine is not quite the same thing as two separate Wine installations.


----------



## shkhln (Jun 21, 2020)

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?


----------



## Adrien2002 (Jun 21, 2020)

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.


----------



## JAW (Jun 21, 2020)

shkhln said:


> With friends like these…  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?


----------



## shkhln (Jun 21, 2020)

JAW said:


> Oh



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.



JAW said:


> 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_.


----------



## shkhln (Jun 21, 2020)

shkhln said:


> 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.



I'm starting to think this port is cursed.


----------



## Adrien2002 (Jun 22, 2020)

shkhln said:


> 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


----------



## shkhln (Oct 8, 2020)

shkhln said:


> workaround



Superseded by https://gist.github.com/shkhln/3d0856683e1fc029d64cdaa6ba3e9393.


----------



## cabriofahrer (Nov 29, 2020)

shkhln said:


> Superseded by https://gist.github.com/shkhln/3d0856683e1fc029d64cdaa6ba3e9393.


How do I use this script? And what are the prerequisits for using it? I guess uninstalling i386-wine first? And what would happen with my games already in the .wine directory?


----------



## shkhln (Nov 29, 2020)

cabriofahrer said:


> How do I use this script?


There is an example in a comment in the script itself.


----------



## cabriofahrer (Nov 29, 2020)

shkhln said:


> There is an example in a comment in the script itself.




```
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?


----------



## shkhln (Nov 29, 2020)

cabriofahrer said:


> 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.



cabriofahrer said:


> "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.



cabriofahrer said:


> 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).



cabriofahrer said:


> 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.


----------



## Menelkir (Mar 18, 2021)

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?


----------



## shkhln (Mar 18, 2021)

Menelkir said:


> 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_).


----------



## Menelkir (Mar 18, 2021)

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.


----------



## shkhln (Mar 18, 2021)

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.


----------



## Menelkir (Mar 19, 2021)

shkhln said:


> 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.


I'll do that shortly. Other question, can I use wine-devel instead or isn't recommended?


----------



## shkhln (Mar 19, 2021)

Menelkir said:


> wine-devel


At the moment it's simply broken.


----------



## Menelkir (Mar 19, 2021)

shkhln said:


> At the moment it's simply broken.


I see. I can live with the regular wine, it's because wine 6.x have interesting new features.


----------



## shkhln (Mar 19, 2021)

What features?


----------



## Menelkir (Mar 19, 2021)

Direct3D 12 support for instance. And for some games with those pesky kernel mode protections, there's some workarounds but I'll not talk about it openly here.


----------



## shkhln (Mar 19, 2021)

Menelkir said:


> Direct3D 12 support for instance.


This is nothing new. It's disabled by default for reasons™: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231248#c2, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249869#c1.


----------



## Menelkir (Mar 19, 2021)

shkhln said:


> This is nothing new. It's disabled by default for reasons™: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231248#c2, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=249869#c1.


How about StartThreadpoolIo? Some protections can be executed with this, but It was implemented in wine 5.3.


----------



## shkhln (Mar 19, 2021)

What about it?


----------



## Menelkir (Mar 19, 2021)

shkhln said:


> What about it?


It just doesn't work in wine older than 5.3.


----------



## shkhln (Mar 19, 2021)

Well, I sent gerald@ a patch containing a streamlined version of wow64 hack + necessary workarounds for wine-devel almost 3 weeks ago. You might want to email him directly.


----------



## Menelkir (Mar 19, 2021)

shkhln said:


> Well, I sent gerald@ a patch containing a streamlined version of wow64 hack + necessary workarounds for wine-devel almost 3 weeks ago. You might want to email him directly.


Nice. Did you send the patch directly or you have somewhere else? I'm willing to use in my overlay.


----------



## shkhln (Mar 19, 2021)

Menelkir said:


> Nice. Did you send the patch directly or you have somewhere else? I'm willing to use in my overlay.


It's there: https://gist.github.com/shkhln/e39432d8b5f8d62da9b7d55aad641ddd.


----------



## Menelkir (Mar 19, 2021)

shkhln said:


> It's there: https://gist.github.com/shkhln/e39432d8b5f8d62da9b7d55aad641ddd.


Thanks. 
Another question, since we need both wine being at the same version (or I'm wrong?). Am I supposed to rebuild i386-wine-devel too?


----------



## shkhln (Mar 19, 2021)

Menelkir said:


> Am I supposed to rebuild


Did you expect anything else?


Menelkir said:


> i386-wine-devel too?


It's wine-devel, not i386-wine-devel.


----------



## Menelkir (Mar 19, 2021)

shkhln said:


> Did you expect anything else?
> 
> It's wine-devel, not i386-wine-devel.


Of course I know that I need to rebuild the port after applying a patch, I mean if I need to make an extra build in a 32bit jail to be used with your w4.


----------



## shkhln (Mar 19, 2021)

I'm well aware you are asking about 32-bit Wine, I just don't see were this confusion comes from. How are you supposed to install something you haven't built?


----------



## Menelkir (Mar 19, 2021)

Let me try again: When I finished building the wine-devel port and installing in my system, should I also build a 32bit one to match the version of the installed one, to be used with w4?


----------



## shkhln (Mar 19, 2021)

What exactly are you referring to as w4?


----------



## Menelkir (Mar 19, 2021)

shkhln said:


> What exactly are you referring as w4?


Your ruby script.


----------



## shkhln (Mar 19, 2021)

Menelkir said:


> Your ruby script.


Just install the official repo package ffs.


----------



## Menelkir (Mar 19, 2021)

shkhln said:


> Just install the official repo package ffs.


So this port will provide both 32 and 64 bit version of wine? You didn't say that "ffs". I didn't even know that ports was able to make multilib now. 
I gave up.


----------



## shkhln (Mar 19, 2021)

I also give up.


----------



## zirias@ (Mar 20, 2021)

Menelkir said:


> Another question, since we need both wine being at the same version (or I'm wrong?). Am I supposed to rebuild i386-wine-devel too?


I would assume the same. Had a look at the patch, so it basically installs an i386-wine package in the user's home. I doubt this could work if it isn't the same wine version.


----------



## shkhln (Mar 28, 2021)

Zirias said:


> so it basically installs an i386-wine package in the user's home


It's _not_ i386-wine. It's a wine package from the i386 repository (as opposed to the amd64 repository). The regular one, no prefixes whatsoever.


----------



## zirias@ (Mar 28, 2021)

shkhln said:


> It's _not_ i386-wine. It's a wine package from the i386 repository (as opposed to the amd64 repository).


Ok, when installing in home, this doesn't really matter, but also doesn't change anything about the need for it to be the same version, right?

Anyways, not really the kind of solution that would excite me (which i386-wine isn't either, of course). What I'd like to see is being able to install both 64bit and 32bit binaries and libraries system-wide in /usr/local and have WoW64 work in that setup… and if possible, make the build less cumbersome, although there's probably never a way around using an i386 jail for that…

Still a good thing of course that there _is_ a solution at all!


----------



## shkhln (Mar 28, 2021)

Zirias said:


> Ok, when installing in home, this doesn't really matter, but also doesn't change anything about the need for it to be the same version, right?


Wine components talk to the wineserver instance through a versioned IPC protocol, so they will simply fail the check if there is a mismatch.



Zirias said:


> Anyways, not really the kind of solution that would excite me (which i386-wine isn't either, of course). What I'd like to see is being able to install both 64bit and 32bit binaries and libraries system-wide in /usr/local and have WoW64 work in that setup… and if possible, make the build less cumbersome, although there's probably never a way around using an i386 jail for that…


Like https://github.com/shkhln/freebsd-lib32-companion-ports? Guess why this idea failed? 



Spoiler



We have i386-wine, thus not enough demand for improvements.


----------



## zirias@ (Mar 28, 2021)

Well the thing is: FreeBSD managed to ignore the problem until it became largely irrelevant. Nowadays, some 32bit Windows software is probably the _only_ reason someone could need some sane "multilib" (or how you'd want to call it) support in ports. And that's slowly vanishing as well…
So, I wouldn't expect any development in this direction any more. Still, having updated my i386-wine manually today, I see why this port has a maintenance problem.


----------



## shkhln (Mar 28, 2021)

Well, ironically a lot 64-bit Windows apps come with a 32-bit installer executable (the Steam client is also 32-bit bit, by the way), so ultimately this situation keeps most people from using 64-bit Wine altogether. Also, unexercised ports tend to be a bit wonky, which means users have an even greater initiative to stay away from it.


----------



## zirias@ (Mar 28, 2021)

shkhln said:


> Well, ironically a lot 64-bit Windows apps come with a 32-bit installer executable (the Steam client is also 32-bit bit, by the way)


Yes, on Windows, you still have this issue. But that's what I mean, it's probably nowadays the only usecase for having some i386 support on an amd64 system. And even on Windows, this will come to an end eventually…

Thinking further about it: i386-wine actually _could_ be a somewhat workable approach, if it would be possible to install an automated build pipeline for the temporary i386 package on FreeBSD infrastructure. As it is right now, leaving the maintainer with the burden to build these temporary packages for all supported FreeBSD versions and upload them manually, that's a horrible mess.

Now, I might try to find out how I have to massage this port to enable WoW64 with regular wine installed at the same time…


----------



## shkhln (Mar 28, 2021)

Zirias said:


> Yes, on Windows, you still have this issue. But that's what I mean, it's probably nowadays the only usecase for having some i386 support on an amd64 system. And even on Windows, this will come to an end eventually…


_All I want is a robust 64-bit Wine port_, and that still requires multilib to give people some initiative to actually use it. This might not be an issue in 10 years, but it's also not clear if we would still have a functioning Wine port by that point with all this neglect.



Zirias said:


> Thinking further about it: i386-wine actually _could_ be a somewhat workable approach,


Forget about i386-wine. It's not better than installing an i386 wine package into a location in the home directory. i386-wine is just a messier version of the same trick. i386 wine also has a key advantage of having proper automatic builds, which is why I recommend it in the first place.


----------



## zirias@ (Mar 29, 2021)

shkhln said:


> Forget about i386-wine. It's not better than installing an i386 wine package into a location in the home directory.


I strongly disagree on _that_. It's a workaround and maybe "okayish" on your single user system. For a sane solution, I expect to _just install packages with  pkg_.


shkhln said:


> i386-wine is just a messier version of the same trick. i386 wine also has a key advantage of having proper automatic builds, which is why I recommend it in the first place.


Several things are messy there right now. I'm pretty sure they _can_ be solved (although part of a _good_ solution would IMHO involve a build pipeline…). I'm trying to figure out what has to be done to solve them. Currently, I have both wine and i386-wine installed at the same time, both working, but no WoW64 functionality yet. And it's too late to continue looking into the issue tonight.


----------



## shkhln (Mar 29, 2021)

Zirias said:


> I strongly disagree on _that_. It's a workaround and maybe "okayish" on your single user system. For a sane solution, I expect to _just install packages with  pkg_.


And this somehow doesn't involve pkg?



Zirias said:


> Several things are messy there right now. I'm pretty sure they _can_ be solved (although part of a _good_ solution would IMHO involve a build pipeline…). I'm trying to figure out what has to be done to solve them.


I'm not sure why do you believe this a technical challenge. I can think of dozens of ways to package wow64 (quite literally, yes), but there is simply no demand for better solutions.



Zirias said:


> Currently, I have both wine and i386-wine installed at the same time, both working, but no WoW64 functionality yet.


Already explored there: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242625.


----------



## zirias@ (Mar 29, 2021)

shkhln said:


> And this somehow doesn't involve pkg?


So you pretend not to understand what I mean?


shkhln said:


> I'm not sure why do you believe this a technical challenge. I can think of dozens of ways to package wow64 (quite literally, yes), but there is simply no demand for better solutions.


There certainly is. A solution for WoW64 in the ports tree, in a sane way, would be welcome.


shkhln said:


> Already explored there: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242625.


You lost interest pretty quickly.


----------



## shkhln (Mar 29, 2021)

Zirias said:


> You lost interest pretty quickly.


You are welcome to try to get anything past gerald@.


----------



## zirias@ (Mar 29, 2021)

I played with maintainer-feedback just half an hour ago and got instant response. And reading his comments in your PR, they sound reasonable. Adding WoW64 seems clearly on the "wishlist" according to several comments, but it's not a simple change and there's always a focus on "getting things right", even if it takes a long time and quite some discussion. MakeMKV was on the ports wishlist and still it took me a year to get my port into the tree (because the port has to do pretty unusual things).


----------



## shkhln (Mar 29, 2021)

Zirias said:


> MakeMKV was on the ports wishlist and still it took me a year to get my port into the tree (because the port has to do pretty unusual things).


Hey, I've been quietly working on emulators/libc6-shim for almost 3 years before I proposed a port for it. I have more than enough patience. That i386-wine/wow64 patch has a pretty limited utility and it conflicts with my other ports to boot. You are absolutely unironically welcome to work on it.


----------



## zirias@ (Mar 29, 2021)

JFTR, I didn't count time working on the port _before_ submitting the first revision. But still, that attempt to get WoW64 working with i386-wine would have deserved more time, IMHO. Maybe I'll jump on that, let's see…


----------

