SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
What's the easiest way to install more than one version of Wine? I might want to have both the stable and development versions installed at the same time.
This will be on a 64-bit multilib system.
Is there a better way than installing one via the SBo SlackBuild as is, then hacking the SlackBuild to install the other one into /opt and not into /usr, then writing a launcher for the one in /opt that will set the necessary environment variables?
Depends a lot on how you want to actually use it, how many versions and how often you might want to introduce a new one or remove an old one.
Looking at the package list from wine-1.6.1 (32 bit), the include, share, doc and lib install paths are pretty much self-contained in .../wine/ subdirectories and would be easy to switch using symlinks. The bin and man paths would take a little more thought with 20+ files each, but might be easily enough built to a new path that could be version-symlinked and switched around.
Until recently (when the mobo died on that system) I ran a similar arrangement for switching MySQL versions and ran 3.23, 4.x and 5.x - six different versions at one point, without major problems. I scripted the switch to safely start and stop running instances, change a few symlinks and my.cnf versions, and of course each had its own data path.
That worked well and was easy to manage so long as I was careful when adding new versions.
My MySQL arrangement pre-dated my git experience but when I resurrect that one I intend to try to reproduce that within a git repo such that switching branches would switch running version... might be worth some thought for your case as well.
Of course you can only run one version at a time this way - I can't think of any easy way to run more than one, or why you would want to...
And with wine you might need to be careful about version sensitivity of the registry files - I am not sure how those might be affected.
What's the easiest way to install more than one version of Wine? I might want to have both the stable and development versions installed at the same time.
PlayOnLinux allows to run and install multiple versions of Wine in a rather easy way and works fine for me on a multilib 64bit system. It might be worth looking at either using this or else look how they solved this.
I've yet to try PlayOnLinux, but I did look into how it works. When you install a version of Wine from the PlayOnLinux UI, it downloads downloads a prebuilt Wine tarball from the PlayOnLinux server and then extracts it into a place where PlayOnLinux can find it. The 32-bit Wine packages available to it are here. Each .pol file is a tarball:
PlayOnLinux is an option. What I had in mind, however, was installing both the latest stable and latest experimental versions of Wine, choosing one or the other for each application, and using Winetricks to install each application into its own prefix.
Anyway, I just patched the SBo Wine SlackBuild to build Wine 1.7, install it into /opt, and package it into a package named "wine17". That coexists well with the normal Wine SlackBuild, which installs into /usr and makes a package called "wine".
You may get some clues from looking at AlienBob's wine-pipelight package. Amongst other things, it uses .wine-pipelight for user configuration files rather than .wine. Also if a wine process is running that may well be the one that gets used and that may not be the wine you want to use. I hit some issue like that with pipelight but I don't fully understand it yet.
If you want the development release and the stable one, I'd just go with the development release. In my experience, the "stable" WINE release is usually out of date and not as good as the development one. Unless you need a specific version of WINE, I'd go with whatever's current.
If you want the development release and the stable one, I'd just go with the development release. In my experience, the "stable" WINE release is usually out of date and not as good as the development one. Unless you need a specific version of WINE, I'd go with whatever's current.
Careful! Many games are also "out of date" and prefer earlier versions of wine. Seriously, don't get caught up in this "new always == improved" nonsense. It is oversimplification and completely disregards the converse "tried and true". A blend, arrived at from careful consideration, is most useful and reliable. Rushing headlong in a straight line quite commonly involves colliding with dense obstacles.
Maybe take a look at how TeamViewer bundles WINE with the windows version to create a standalone program bundle? Their Linux version program wraps a custom Wine install ans some scripts around the Windows executable. https://www.teamviewer.com/en/download/linux.aspx
I've picked at this a bit but never really got anything working...and now that more Linux native games are coming out... It would still be nice to create standalone packages for some of my classic old windows games, using the best WINE version for each...
Careful! Many games are also "out of date" and prefer earlier versions of wine.
I'm very active at the application database and that happens very rarely. Sometimes a regression occurs, for example: In Wine 1.7.29 textures in some games were garbled. This was fixed very fast in 1.7.30.
But for the majority of applications a new wine release doesn't change anything (if they already run).
The performance may even get better.
I build the new release every two weeks and test some of the games from my 250 games steam list. Most of them run, some of them need DLL's or a winetricks command, but they run.
The situation with lithtech engine games (No One Lives Forever, TRON, Blood II) has drastically improved in the last few versions, just to name an example. A year ago, they had whacky mouse problems, music wasn't running and overall they ran very unstable. Now I can play them with better performance than on Windows. :-)
If an application breaks after a specific release, the wine maintainers are very eager to fix this problem.
Edit: I have to clarify that I use wine mostly for games, for making music with OpenMPT and occasional 3D design with Cinema 4D. The situation may be different for other applications.
Last edited by schmatzler; 11-06-2014 at 09:40 AM.
Thank you, Schmatzler, that was interesting and informative. I have a question regarding multiple instances/versions and a link to demonstrate one issue that I'd be pleased to know was no longer required. Understand that as the article states this is with PoL and he says any data of experience in wineapps.db that mentions PoL is trashed so I don't know how objective you can be, but I'm willing to give you equal respect until I have reason to not for either.
Initially these libraries are standard for most games. Some games like Magicka require dotnet libraries and XNA libraries, but before you install these, make sure to switch your wine version to 1.5.18 and then switch it back to 1.6.2
dotnet11
dotnet11sp1
dotnet30 (automatically installs dotnet20)
dotnet35
dotnet4
xna31 (some game like Magicka need XNA)
xna40
Internet Explorer 8 (automatically installs Service Pack 3
IIRC there is also included a workaround to get DX versions newer than 9.0c. Several months ago I Steam-installed Deus Ex: Human Revolution which is a DX11 game. I can't recall how I got this to work but it does very well and largely thanks to wineapps.db to which I contributed on the forums.
So my question(s) is - What is currently recommended to solve the dotnet and DX issues?
So my question(s) is - What is currently recommended to solve the dotnet and DX issues?
I don't know which "issues" you are referring to. All dotnet versions can be installed via winetricks. There is no need to downgrade your wine version for this.
I highly recommend to ignore any advices to install the original Internet Explorer. Wine comes with its own implementation of the iexplore.exe that uses Mozillas Gecko engine for rendering. Installing iexplore overwrites a lot of system files that may break wine and applications in the process.
I'm also not very fond of PlayOnLinux. It uses unofficial patches, bundles outdated wine versions and overall makes it very hard to report bugs to the original project. Use the latest wine version and if you encounter any bugs with specific applications, search for help in the wine forums or file a bug.
Quote:
IIRC there is also included a workaround to get DX versions newer than 9.0c.
No. DX11 is not supported yet (DX10 partially, see this). You can copy over the DX11 files, but it won't work. Deus Ex: Human Revolution uses DirectX9 as a fallback which makes it work.
Last edited by schmatzler; 11-10-2014 at 12:55 PM.
I knocked up a simple environment management system to manage Wine bottles. It uses some code from VirtualEnv.
The following is named mkopener and needs to be a) executable and b) in your PATH:
Code:
#!/usr/bin/env python
import argparse
import os
import sys
def main():
parser = argparse.ArgumentParser()
parser.add_argument('bottle', help='The name of the Wine bottle, e.g. PvZ')
parser.add_argument(
'--wine', help='The path to the Wine executable to use'
)
args = parser.parse_args()
set_wine = ''
unset_wine = ''
if args.wine is not None:
if not os.path.isfile(args.wine):
print 'Wine must be the path to an executable'
sys.exit(1)
set_wine = set_wine_template.format(path=os.path.dirname(args.wine))
unset_wine = unset_wine_template
print template.format(
bottle=args.bottle, set_wine=set_wine, unset_wine=unset_wine
)
template = """# This file must be used with "source bin/uncork" *from bash*
# you cannot run it directly
cork () {{
# reset old environment variables
unset WINEPREFIX
# This should detect bash and zsh, which have a hash command that must
# be called to get it to forget past commands. Without forgetting
# past commands the $PATH changes we made may not be respected
if [ -n "$BASH" -o -n "$ZSH_VERSION" ] ; then
hash -r 2>/dev/null
fi
if [ -n "$_OLD_BOTTLE_PS1" ] ; then
PS1="$_OLD_BOTTLE_PS1"
export PS1
unset _OLD_BOTTLE_PS1
fi
{unset_wine}
if [ ! "$1" = "nondestructive" ] ; then
# Self destruct!
unset -f cork
fi
}}
# unset irrelevant variables
cork nondestructive
_OLD_BOTTLE_PS1="$PS1"
PS1="({bottle})$PS1"
export PS1
WINEPREFIX=$HOME/.local/share/wineprefixes/{bottle}
export WINEPREFIX
{set_wine}
# This should detect bash and zsh, which have a hash command that must
# be called to get it to forget past commands. Without forgetting
# past commands the $PATH changes we made may not be respected
if [ -n "$BASH" -o -n "$ZSH_VERSION" ] ; then
hash -r 2>/dev/null
fi"""
set_wine_template = """_OLD_PATH="$PATH"
PATH={path}:$PATH
export PATH"""
unset_wine_template = """ if [ -n "$_OLD_PATH" ] ; then
PATH="$_OLD_PATH"
export PATH
unset _OLD_PATH
fi
"""
if __name__ == '__main__':
main()
The second script needs to be sourced, so it can be put anywhere (as long as you're sourcing it). I called it bottle.sh:
Code:
function mkbottle {
case $# in
1)
mkdir -p $HOME/.local/share/wineprefixes/$1/bin
mkopener $1 > $HOME/.local/share/wineprefixes/$1/bin/uncork
source $HOME/.local/share/wineprefixes/$1/bin/uncork
cd $HOME/.local/share/wineprefixes/$1
;;
2)
if [ -x $2 ]; then
mkdir -p $HOME/.local/share/wineprefixes/$1/bin
mkopener --wine $2 $1 > $HOME/.local/share/wineprefixes/$1/bin/uncork
source $HOME/.local/share/wineprefixes/$1/bin/uncork
cd $HOME/.local/share/wineprefixes/$1
else
echo /path/to/wine must be the path to a Wine execuable
fi
;;
*)
echo mkbottle BottleName \[/path/to/wine\]
echo e.g. mkbottle PvZ
echo e.g. mkbottle PvZ ~/Software/wine-1.7.30/bin/wine
;;
esac
}
function bottle {
case $# in
1)
if [ -f $HOME/.local/share/wineprefixes/$1/bin/uncork ]; then
source $HOME/.local/share/wineprefixes/$1/bin/uncork
cd $HOME/.local/share/wineprefixes/$1
else
echo Invalid prefix
fi
;;
*)
echo bottle BottleName
echo e.g. bottle PvZ
;;
esac
}
Now here's a demonstration. I have Wine 1.6.2 installed using the SBo SlackBuild. I also have Wine 1.7.30 installed like this:
Code:
mkdir -p ~/Software/wine-1.7.30
./configure --prefix=~/Software/wine-1.7.30
make
make install
After sourcing bottler.sh, you have the following commands:
mkbottle creates a Wine bottle (bottle and prefix mean the same thing). It takes the name of the bottle, and optionally the path to the Wine executable you want to use. Creating the bottle will automatically put you inside it, setting your WINEPREFIX and, if necessary, PATH environments appropriately.
cork will take you out of the Wine bottle and restore your environment to normal.
bottle will set your environment to that of an existing Wine bottle.
Perhaps the following transcript will help. Note that the prompt changes to show which bottle you're in:
If Plants vs Zombies requires special settings (it doesn't, but bear with me), you can create a prefix just for it, use Winetricks to install Steam into it, and then tweak it in its own isolated bottle without affecting your other applications:
How long has it been since I posted that? Two weeks? That's how long I've spent reworking it into a complete system for managing your installations of Wine and of Wine software. I'm happy to be able to announce it now. The README should tell you the rest. Have a look:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
It will check out the sources from GitHub, build and package them:
