Status of wow64 in wine?

Hi there,

I was wondering what the status of wow64 for wine in FreeBSD is? Does the actual wine-4.0.1_2,1 or wine-devel-4.13_1,1 already support this?
 
Hello, @cabriofahrer

It's possible to use 64bit applications with "wine-devel" but you are not able to use a 32bit application.

In theory you must install your application with "i386-wine-devel" in a 32bit prefix then move the application to a 64bit prefix.
 
In theory you must install your application with "i386-wine-devel" in a 32bit prefix then move the application to a 64bit prefix.

Does "move the application" really work? Is the application just installed to one folder, not rather several files also into some "windows system folders" spread within wine?

Not implemented at this time on FreeBSD plateform, and I wonder if it will happen one day.
It seems to work on most Linux distros.... we simply install the Wine 64 bit and Wine 32 bit packages side by side, but this is not possible today on FreeBSD.

But is there anybody working on that or not? Any project website that provides information on that matter? I mean the real problem is actually windows programs for 64 bit but with a 32 bit installer??? What sense does that make?

See the first result in google for "freebsd wine wow64"

Dates from 2017. This is why am asking.
 
Does "move the application" really work? Is the application just installed to one folder, not rather several files also into some "windows system folders" spread within wine?

Yeah it works for the most applications but some may saying "please install me again" because there is no entry in the registry.
But is there anybody working on that or not? Any project website that provides information on that matter? I mean the real problem is actually windows programs for 64 bit but with a 32 bit installer??? What sense does that make?



Dates from 2017. This is why am asking.

Here is something from 2018 https://reviews.freebsd.org/D14721
 
Dates from 2017. This is why am asking.

I'm pretty sure D14721 dates from Mar 17 2018. Anyway, D14721 is superseded by D16830, which is also not being worked on. Presumably, dbn (original author) is just too busy or something like that. I have a somewhat more elaborate version of the patch from the latter proposal hosted on GitHub, mostly useful for scaring port committers demonstrating the approach.
 
The short of it seems to be that

* You can't cross compile ports
* You can't chroot without root
* The latest idea requires a lot of politics involving how to structure ports

Unblocking any of those might get the problem solved
 
That is a bit counterintuitive, cross-compilation is not directly related to multilib packaging (an actual issue here). For example, Fedora and Debian "simply" reuse i386 packages, it doesn't matter if they were cross-compiled, or built directly on i386 host, or built on x86_64 host in i386 chroot. On other hand, Arch Linux provides separate lib32- packages with their own building instructions, no distinct cross-compilation step involved.
 
It's not complicated. Fedora and Debian provide binaries. That's not how ports works. Hence, the cross compiling being a bullet point.
 
It's not complicated. Fedora and Debian provide binaries. That's not how ports works. Hence, the cross compiling being a bullet point.

And what would you do with the cross-compiled i386 Wine package? It's still an i386 package, you can't install it on amd64 FreeBSD.
 

Historically, i386 Fedora installs libraries into /usr/lib and x86_64 Fedora installs libraries into /usr/lib64. Thus, i386 packages can be installed into x86_64 system without overwriting 64-bit libraries. Of course, RPM provides some support for installing i386 and x86_64 packages side by side. Debian has a more advanced version of this, it is very elaborate and took them several years to implement.
 
Now we've wrapped around to the "latest idea" which is 32-bit "coinstalled packages."

Anyway, the answer to the original poster is that the problems are hard than it seems and nobody wants to tackle them. (Presumably because they're all large architectural changes that require buy-in)
 
I don't really think any of these approaches are hard to implement. It all boils down to the complete lack of interest from existing committers. Which is quite bizarre considering there is already full multilib support in the base system.
 
Back
Top