Just not sure "32" in /usr/local/lib/wine/x86_64-unix/ws2_32.so really means "32bit compat version" or version32 (or something like 3.2, and more, meaning ws 2.32 or not). Because if I'm forced to design the directory structure for both 64bit and 32bit, and if wine/x86_64-unix for 64bit is forced, I'll create wine/i386-unix for 32bit to sanely divide them not to be confused.
If I remember correctly, currently only base, system related libraries are there. No xorg/wayland/pulseaudio etc things here. Posts above explained nicely where Wine is looking for 32-bit libraries.
wine on FreeBSD is a script to run 32-bit version of wine. But, i think, if you start 64-bit program with it, it will switch to 64-bit version of wine.Yet, it still beats normal/development version of wine on FreeBSD in case of performance and compatibility. Mostly due to use PulseAudio instead of Alsa/OSS plus patches.
Yes, it is called WoW64 (Windows on Windows 64).
If I remember correctly, I mistakenly got it from wine compilation flags, where you can enable wine even on arm.
I believe WoW64 was a feature added starting form wine 9.0 ?
wine-devel and 32-bit prefixes. Mainly everything I play runs easy on Wine though and most things have native OpenGL or Vulkan.
). It might benefit from Esync which iirc requires Staging/patches (above devel is plain Wine, no Staging patch set).
(rough notes)If I remember correctly, yes, and was "a bit" buggy, so even wine developers discouraged to use it on Linux. But I think it should works a lot better with wine 10.0. I will check it when wine-proton 10.0 arrive.
Well, wine from Valve (wine-proton) has several layers of patches. It contains some patches from wine-staging plus additional fixes made by Valve. And yes, DXVK should work better with wine-proton too. In my opinion, these days it is always better to use wine from Valve (either Linux or FreeBSD) than the base version.
Do you know when wine-proton 10.0 will be released ?If I remember correctly, yes, and was "a bit" buggy, so even wine developers discouraged to use it on Linux. But I think it should works a lot better with wine 10.0. I will check it when wine-proton 10.0 arrive.
Well, wine from Valve (wine-proton) has several layers of patches. It contains some patches from wine-staging plus additional fixes made by Valve. And yes, DXVK should work better with wine-proton too. In my opinion, these days it is always better to use wine from Valve (either Linux or FreeBSD) than the base version.
That knows only Valve.Do you know when wine-proton 10.0 will be released ?
We usually wait on a stable release of it and then a couple of people is trying to port it to FreeBSD. There is no hard date like 2 weeks after official release, etc. It depends on many factors, from amount of work needed to make it work on FreeBSD to amount of time needed to add the new version to the ports tree.
Unfortunately, Valve provides wine-proton only for Linux. Sometimes with patches which break compatibility with FreeBSD.
Perhaps no one has been interested in doing this yet. Plus it means a lot of more work, these patches also created with Linux in mind and can cause issues on FreeBSD.
Correct.As I understand it proton-ge patches are proton + glorious eggrolls patches, right ?
I'm running it all time. Previously on "a bit" older hardware, now with "a bit" newer. Just usually I'm running older games, so, not too much to show.
I wrote a post some time ago, about some configuration's suggestions for FreeBSD, Nvidia and games: https://www.laeran.pl.eu.org/blog/articles/playing-with-beastie
I will take that guide into consideration while configuring wine-proton.Playing with Beastie | Laeran
www.laeran.pl.eu.org
As you can see the output you posted, ABI string used by pkg contains only topmost 2 digits of OSVERSION.
Exactly, if you want i386 version of the pkgs.
Well, I would say soYou, too, a Japanese?
Souka, are ha zannen desukedo, Makefile no naiou wo mada kakunin suru koto ga dekimasen deshita.
if I remember correctly, you will get it even when you will try to install standard wine package. You can silence it, by setting environment variable: IGNORE_OSVERSION=yes. I think last time I "fixed" it in that way. LD_LIBRARY_PATH and PATH environment variables. That's very simple script.