a prefix holds a virtual windows with separate wine settings (drives, virtual desktop, special dlls and so on)
Prefixes are set with the environment variable WINEPREFIX
so, for example, we can use
# export WINEPREFIX=$HOME/.wine-wow/ # winecfg # wine "D:\Setup.exe"
# WINEPREFIX=$HOME/.wine-wow/ wine "C:\Program Files\WoW\WoW.exe" -opengl
the upside now is that we can rm -rf ~/.wine-wow to uninstall that application. And because the application doesn't depend upon or install junk into any of our other virtual windows, we can safely remove the whole 'wineprefix' or Windows. Also, using winetricks you can set special dlloverrides and such per prefix, which can come in handy rather often.
[Dec 10] you can have separate wine prefixes for 64bit and 32 bit as D. Kegel wrote that you can: export WINEARCH=win32 before creating the wineprefix. If you use 64 bit, to create a separate, 32 bit wineprefix using [export] WINEARCH=win32 eg code:
This also comes in handy when testing software. You can create a temporary wine environment to play with and then erase it when you have finished.
Vitamin [nov 09] Everything goes under [the] directory specified in WINEPREFIX, including [wine's] registry. The only exceptions are the desktop and menu links. [i.e you can even specify a link to external drive]. However DeVince cautioned: be aware that if your external drive isn't formatted as ext3, some Windows applications might not work. But I myself haven't actually ever encountered this.
when you have a specific wineprefix and want to use it by default vitamin [nov09] you can this to your ~/.bashrc:
- export WINEPREFIX=/path/to/external/drive/.wine
When software is installed it often creates a link to the desktop. This link may not work, if you are running a compiled wine from the wine tree (ie, you did not use 'make install'). The advantage of this is that you are testing the latest wine, and broken links are easily worked around: edit the properties and change the command 'wine' to include the path to the wine executable, all of which should be something like
Setting vs Unsetting
A user proposed 2011Jan: I (hypothetically) want to create a new clean wine-environment, install the winetricks d3dx9 package into it, and then run three applications in it. Would the following commands be the right way to do it? Code:
- winetricks d3dx9
- wine app1.exe
- wine app2.exe
- wine app3.exe
Or do I need to set the WINEPREFIX again for every command? Do I need to run some special command after setting the new WINEPREFIX?\
Dimesio: If you simply say
[ed you could also do: env WINEPREFIX=$HOME/.new-wine]
yes, you will need to repeat that for every command. If you do Code:
- export WINEPREFIX=$HOME/.new_wine
you will not have to repeat it for subsequent commands entered in that terminal session.
P. Troller: [after exporting WINEPREFIX]... the rest may be run without specifying the prefix, but in the current shell session only. When you log out and on again, or you are using more shells (in different windows, for example), you must execute exactly the same export command in every one of them. To forget the prefix, just do "unset WINEPREFIX" and default .wine will be used since then, until you issue your export ... again.
G van den Berg:Read the bash man page's section on enviroment variables and the export command and the man page for the env command
jan 09 bug 16779 vitamin: WINEPREFIX [has] to be a real directory. You can put it anywhere you want to, but WINEPREFIX env var has to point to a real directory. A user then said: i also tried symlinking just the drive_c folder and not the .wine. but Vitamin said: This is not supported either. That have to be a real directory as well. The symlink [belongs] under .wine/dosdevices. However A. Julliard: Having .wine or drive_c as a symlink works just fine. The problem is most likely with JFS. This was confirmed by the user: When symlinking drive_c to a directory within the /home mount (a seperate Ext3 formatted disk) there is no problem. Only when symlinking to JFS. I had this in my /etc/fstab:
- /dev/sda1 /jfs jfs user,relatime,errors=remount-ro 0 1
i changed it to:
- /dev/sda1 /jfs jfs relatime,errors=remount-ro 0 1
After removing the 'user' mount option, the bug disappears. [appears to be not a wine bug]
Setting wine to specific Wineprefix on bootup
Where I put it?
Nov 10: Depends where you need it of course. ~/.bashrc might be a good user-global place.