Wine binaries & Wineprefix

[keybreak]

For now this is biggest problem i have with LinVst, and it have been brought up not once before in different forms:
#28
#4
#130

Forced to use system Wine is a big problem, because for example recent builds of Wine binaries 5.4, 5.4-staging, 5.5, 5.5-staging doesn't work at all on Arch, with any program - it can't even load winecfg...
So loosing stability of your prefix this way is pretty bad.

Therefore it is a very good idea to give user ability to go fully independent from system Wine by doing something like PlayOnLinux does by having fully independent Wine builds.

I'm by no means an expert of Wine, so if i missed something please guide me, but now i can't make LinVst work through environment variables...

The way i see it should be done:

1. Optional config file where custom path to non-system Wine build for LinVst can be easily set, for example such config can be located here (since linvstmanager already use this folder):

~/.config/linvst

2. Maybe some working & tested alias with environment variables described in manual, that can be easily used/prefixed with any program through .desktop files...

I've been struggling to formulate it right way, hope that makes sense.

[osxmidi]

if a (renamed) linvst.so file is located withing a wineprefix then it will use that wineprefix.

If I have a vst plugin in a (any wineprefix) wineprefixes "Program Files/VstPlugins" folder called delay.dll and I also have a renamed delay.so located there as well, then when delay.so is loaded by the DAW that wineprefix will be used.

So a user can have multiple wineprefixes containing various vst plugins and the wineprefix that gets used depends on the wineprefix that the vst plugin is in.

Symbolic links can be used outside of a wineprefix to point to a wineprefixes renamed linvst.so file.

Also, a folder outside of a wineprefix can point to a folder containing vst plugins and (renamed) linvst.so files in any wineprefix via a symbolic link.

WineHQ uses a wine symbolic link in /usr/bin and often it points to a Wine version installed in /usr/opt or wherever and there are other Wine symbolic links in /usr/bin as well.

The /usr/binwine symbolic links can point to any installed Wine.

I've changed Wine versions from a WineHQ version to another Wine version just by changing the wine symbolic links in /usr/bin

ls -la /usr/bin/wine* will show the symbolic links.

[osxmidi]

The Wine version I changed to from the usual WineHQ Wine-Staging one was Wine Esync in ~/Downloads/wine-4.11-staging-improved-amd64

I set up the symbolic links like this using this script

sudo rm /usr/bin/wine*

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/wine /usr/bin/wine

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/wine64 /usr/bin/wine64

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/wine64-preloader /usr/bin/wine64-preloader

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/wineboot /usr/bin/wineboot

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winebuild /usr/bin/winebuild

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winecfg /usr/bin/winecfg

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/wineconsole /usr/bin/wineconsole

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winecpp /usr/bin/winecpp

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winedbg /usr/bin/winedbg

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winedump /usr/bin/winedump

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winefile /usr/bin/winefile

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/wineg++ /usr/bin/wineg++

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winegcc /usr/bin/winegcc

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winemaker /usr/bin/winemaker

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winemine /usr/bin/winemine

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/winepath /usr/bin/winepath

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/wine-preloader /usr/bin/wine-preloader

sudo ln -s ~/Downloads/wine-4.11-staging-improved-amd64/bin/wineserver /usr/bin/wineserver

[osxmidi]

And then to go back to the WineHQ Wine-Staging version

sudo rm /usr/bin/wine*

sudo ln -s /opt/wine-staging/bin/wine /usr/bin/wine

sudo ln -s /opt/wine-staging/bin/wine64 /usr/bin/wine64

sudo ln -s /opt/wine-staging/bin/wine64-preloader /usr/bin/wine64-preloader

sudo ln -s /opt/wine-staging/bin/wineboot /usr/bin/wineboot

sudo ln -s /opt/wine-staging/bin/winebuild /usr/bin/winebuild

sudo ln -s /opt/wine-staging/bin/winecfg /usr/bin/winecfg

sudo ln -s /opt/wine-staging/bin/wineconsole /usr/bin/wineconsole

sudo ln -s /opt/wine-staging/bin/winecpp /usr/bin/winecpp

sudo ln -s /opt/wine-staging/bin/winedbg /usr/bin/winedbg

sudo ln -s /opt/wine-staging/bin/winedump /usr/bin/winedump

sudo ln -s /opt/wine-staging/bin/winefile /usr/bin/winefile

sudo ln -s /opt/wine-staging/bin/wineg++ /usr/bin/wineg++

sudo ln -s /opt/wine-staging/bin/winegcc /usr/bin/winegcc

sudo ln -s /opt/wine-staging/bin/winemaker /usr/bin/winemaker

sudo ln -s /opt/wine-staging/bin/winemine /usr/bin/winemine

sudo ln -s /opt/wine-staging/bin/winepath /usr/bin/winepath

sudo ln -s /opt/wine-staging/bin/wine-preloader /usr/bin/wine-preloader

sudo ln -s /opt/wine-staging/bin/wineserver /usr/bin/wineserver

[osxmidi]

Just by using symbolic links, LinVst can use any wineprefix and Wine can be any version of Wine.

[keybreak]

@osxmidi
Yes, technically you're right it's possible - but not very flexible / non-destructive...
Sorry i might not formulate that best way.

Prefixes are not problem really, but wine builds..

Let's say there's common situation like that:

1. User have wine / wine-staging system version (and doesn't want to change it anyhow, relink, maintain when update come etc), let's say it's version 5.5 for example.

2. User have PlayOnLinux / Lutris or whatever like that with multiple prefixes fully portable and independent from system, and ability to manage binaries:

prefixes

~/.PlayOnLinux/wineprefix/VST
~/.PlayOnLinux/wineprefix/TestVST1
~/.PlayOnLinux/wineprefix/TestVST2
~/.PlayOnLinux/wineprefix/Games
...etc

wine builds (have no links to system wine version)

~/.PlayOnLinux/wine/linux-amd64/5.1-staging
~/.PlayOnLinux/wine/linux-amd64/5.2-staging

3. Let's say user have a VST wineprefix with 5.2-staging version in POL fully stuffed with LinVst .so which have been perfectly working and loads a plugin in DAW considering current situation, what would happen by default:
   1. While loading plugin in DAW LinVst will trigger prefix update (effectively it will update working 5.2-staging prefix with system 5.5 which doesn't work)
   2. Therefore we have a situation where any software you install with POL can be fully independent of system Wine versions and be portable, while LinVst not and will keep fallback to some mixed version of wineprefix created and used with custom binaries + system Wine version.

---

What i'm saying, is that using symlinks is probably not ideal / very straightforward solution in case user would want to keep system wine version untouched because not only LinVst is in use (there might be plenty of reasons for that).

Best way would be to have config file for default wine build location to be used with LinVst / working env, so specifically LinVst could be fully independent.

Hope that makes sense

[osxmidi]

A few things.

Why don't the Wine-Staging versions work on Arch?

I'm using Manjaro with Arch Wine-Staging 5.5 and it works ok.

Only 1 Wine version should be run for all plugins and therfore the symbolic links in /usr/bin can point to that Wine version.

Are you trying to run different vst plugins that use different versions of Wine at the same time?

[keybreak]

Why don't the Wine-Staging versions work on Arch?
I'm using Manjaro with Arch Wine-Staging 5.5 and it works ok.

Good question - i have no idea to be honest, i've tested Manjaro Deepin / Gnome on my main system since 5.4 / 5.5 both original and staging version doesn't work for any software and even winecfg, as well as POL builds of same versions.

I even install fresh Manjaro KDE VirtualBox VM to test - results were the same...

So for now only POL 5.2 / 5.2-staging works for me...
Maybe if there's some advanced ways of debug that you're aware of, i could tell you more

I'm using Manjaro with Arch Wine-Staging 5.5 and it works ok.

By saying Arch wine-staging, you mean AUR git version?
I'm using ones from main repo..

Only 1 Wine version should be run for all plugins and therfore the symbolic links in /usr/bin can point to that Wine version.

Yep i know that.

Are you trying to run different vst plugins that use different versions of Wine at the same time?

No, nothing like that - only plugins from single wineprefix / wine build for DAW session.
I test separate prefixes sometimes, but never mix sessions as you've mentioned before it ain't gonna work anyway for the reasons above.

[osxmidi]

I'm using Wine-Staging from the Manjaro/Arch setup, no problems.

sudo pacman -Sy wine-staging

I'll think about what you have suggested.

[keybreak]

Thank you!

Really wonder why you got it working, i double checked one of my friends - he also says his wine-staging 5.5 on Manjaro doesn't work at all now...Go figure

[keybreak]

@osxmidi
I'd appreciate if that would be re-opened and hopefully solved one day, coz it's very important one