Advanced Wine Installation

Jump to: navigation, search


Information For the Advanced Wine User

The Advanced user of Wine can make wine do amazing feats. Some of these would not be recommended for a new user of Wine. Start with learning how to install the basic wine setup and only after you are comfortable, begin to investigate further.

Advanced Installing Wine

Verifying your Wine Source Download

A user wrote [Jul 07 wine user]: I have never used PGP nor GnuPG, but I understand that it has more features beyond using say MD5 to verify my downloads. I noticed Wine has a .sign file (i.e. wine-0.9.40.tar.bz2.sign for wine-0.9.40.tar.bz2).

I installed (which has an MD5 for download verification), and since I never used PGP/GnuPG, the instructions seem to just say to create a keypair, which I did.

How do I verify my wine download? Whether I use:

gpg wine-0.9.40.tar.bz2.sign


gpg --verify wine-0.9.40.tar.bz2.sign wine-0.9.40.tar.bz2 

I receive: gpg: Signature made Fri Jun 29 12:38:13 2007 CDT using DSA key ID B9461DD7 gpg: Can't check signature: public key not found

Do I need to get a public key from the download mirror server? How?

Victor: You can find a key using public key servers, which can be easily found using google (with "public key server" request). The author of the key you are looking for is "Alexandre Julliard <[email protected]>". One of the key servers i've been using is .

Compiling Wine from source

J. Huk [Nov 08]: The [...] advantages you may get are: [the very latest] wine if you are using "not so popular" distro, [and by compiling] you can also add some additional patches to your wine to improve some things (and usually [break some things] at the same time). Ed, if you are a maintainer you can also compile wine. By testing your software before a release, you can sometimes catch bugs and breakages before the release.

You will need a fast computer J. Huk [Nov 08]: my old Duron 1200 it took about 1 hour 30 minutes). [Ed this time can be shortened on my computer by using ccache] Another reported that a 4 core pentium took 8 minutes.

R. Lunnon noted: Somewhere between Version 0.9.23 and Version 0.9.25 the version string format changed from Wine X.X.X to wine-X.X.X

N. Skrypuch [Nov 06]: I think that's a result of the new git version magic, for example:

$ ./wine --version

Presumably the gef2c062 allows one to identify the exact sources used to build that version, but for release builds just the tag is sufficient.

J. Huk: [feb 10] "-O2" is consider safe for most software "-O3" is not - from my experience, wine will [crash] with most apps, when compiled with "-O3"

Note: Comments taken from the list about flags can get out of date quick, so note the date that it refers to.


feb 10 winedev Is the Wine compile option to treat warnings as errors a Wine default or is it some type of system configuration option? Since the last couple of releases have quite a few of these

A. English: That would be '-Werror', and is not a wine default. See:;;hb=HEAD#l1497

Building Wine Even Faster

Copied from WWN269Wine HQ WWN 269 Speeding up Builds
Each time I make a modification (even one line), a 'make' followed by a 'make install' can take a long while...

S.Dossinger: I run these commands in the directory of the dll or program which I changed. That is way faster(especially make install)

The user reported that this was 'way faster'

M.McCormack suggested: Try skipping the 'make install', and instead run wine from the build directory. eg.

~/src/wine/wine regedit

I make a point of never installing Wine to make sure I don't accidently run an older installed version that didn't get overwritten properly.

I.Leo Poti expanded on this: you can also just have a script called "wine" in your path, that does something like

/path/to/wine $*

The user then tried runing wine from the build directory: The downside is that make is still slower than if you do it in the directory where you made a modification. The plus side is that it also works when you are modifying the server part of wine. Wine Archive Link

Running Wine from its source tree

M. McCormack: Yes, it can be done [without re installing wine]. In fact, I don't have Wine installed to make sure that I don't get confused as to which version I'm testing. I have the attached script (exists at ~/bin/wine_envsetup) to set up my environment (assumes wine in ~/wine), but running ~/wine/wine will also work.

You can set up a ~/.wine from the source tree using:

./tools/wineprefixcreate --use-wine-tree .

Then add an alias to set up your environment to your ~/.bashrc, something like this:

export OLDPATH=$PATH alias winehq='. $HOME/bin/wine_envsetup'

You can then run 'winehq' to setup your environment. I find this configuration useful to because I have multiple wine environments, so multiple ~/bin/*_envsetup scripts. It points everything to the right place so that running 'wine' on the command line will run the wine binary from the setup I'm interested in, not a shell script.

Again, you don't need to go to all this trouble if you're happy to run the ~/wine/wine script in the source directory.


  1. !/bin/sh
  2. set up the Wine environment
CVSROOT=:pserver:[email protected]:/home/wine

D. Kegel [Dec 05] discovered a possible concern when running wine from it's source tree:

wine: cannot open builtin library for L"C:\\windows\\system32\\regsvr32.exe": 
/home/[nobody]/wine/programs/ invalid ELF header

V. Margolen: The only time I have seen this message in relation to regsvr32.exe is only when Wine's builtin was overwritten with native PE executable. That could happen only of you have write access to the the place where you installed wine, or if you running it from the source tree. [It] Looks like a case of overwritten regsvr32.exe with native copy (like what IE6 installation will do).

[After some troubleshooting D. Kegel reported: the problem was caused by having an old copy of wine installed in /usr/local while running a new copy of wine from the build directory. Removing the old copy, and installing wine from the build directory, fixes the problem; I can then run regsvr32 from either the build directory or the installed copy without problems. Nasty little troubleshooting problem. I guess I have to be a lot more careful, and make sure to uninstall all old copies of wine before running new builds without installing. wine archive

Running Wine from the Source Tree

[Bug 1947 Aug 07] Call the wine binary out of your git directory, ie:

$ ~/wine-git/wine /path/to/app.exe

It makes git bisect easy and it's faster with not having to do "make install" first.

Further Reading

Compile and Debug Messages

CLSID_Registrar undeclared

registrar.c: In function �DllGetClassObject�:
registrar.c:747:18: error: �CLSID_Registrar� undeclared (first use in this function)

With wine 1.3.7 there was a breakage in compiling wine. P. Vriens explained the workaround: rm dlls/atl/atliface.h

R. Dunn The issue is that atliface.idl was moved to the include directory and its content was changed. If you are doing an incremental build of wine pulling in these changes together, there is an atliface.h left over in the dlls/atl directory containing the old contents. The build is then picking that up.

As a result, you need to delete the dlls/atl/atliface.h file (like P[..] Virens described) and re-run ./configure.

warning: XXX: missing glyph for char YYY

vitamin [mar 09] You [can] ignore those messages, unless you want to add all the missing font glyphs (characters, symbols, etc) yourself. [ed. please - even just adding one would be an interesting job for a non programmer wanting to help wine]

A developer queried [Feb 07]: Is it still possible to compile out debugging messages? According to, I can pass --disable-debug, but the Changelog says that option was removed about 10 month ago. [...] the patch from 2007/04/17 only removed -DWINE_NO_DEBUG_MSGS / -DWINE_NO_TRACE_MSGS from configure, but not from include/wine/debug.h.

M. Stefanuic: Right, it was a problem with a lot of people turning debug messages off and sending in useless problem reports. So that option got removed from configure. There is one valid reason to turn debugging off and that is to cross check that there are no side effects hidden in some debug message.

L. Zhang: Well, we should update the documentation either by removing section 2.6 or mention passing -DWINE_NO_{DEBUG/TRACE}_MSGS instead.

Build Dependencies

One of the package maintainers [Sept 07 wine devel] I stumbled across this patch while browsing recent commits:

Am I correct to say that we no longer need libicu when compiling Wine? By the way, it would be nice if someone shot off an email to wine-devel whenever the build dependencies change (either removing or adding a lib) -- it makes it a lot easier on we package maintainers.

The developer apparently involved replied: Yes. Next time I'll send a message to wine-devel if I change a build dependency.


A user reported [wine bug 9423] My first attempt was unsuccessful because by default wine required DRI , so I had to recomple it with ./configure --without-opengl

Debug Packages

Winehq Bugzilla entry 18650 do I need to pass anything special to get debugging symbols when I compile? K. Sharp: You can add CFLAGS="-g" as an environment variable, but they should be added by default.

Static Linking and Wine

A programmer queried: what's the reason that wine can't be built statically? A design decision or a technical (code) reason somewhere?

A. Julliard: Technical reasons. Windows can't be built statically either, dynamic loading is very much integral to the whole design. Wine is not a stand-alone application, it's really a set of libraries, the true application is the Windows binary, so that's what would have to be statically linked. [...] . There are many things that depend on dynamic linking on the Unix side too, like dns lookups or opengl. Just forget about static linking, it's not a viable solution for anything except very simple apps.



i386 Building from source

x86_64 Building from source

Win64 Building from source

This is different from running 32 bit wine on a 64bit system. Rather you can build wine to handle 64bit Windows software, though this is a work in progress as of now.

D. Kegel Jan 08 winedevel: I just improved so it does all the futzing needed to build 32 bit wine on 64 bit systems (although at the moment it only does this for Ubuntu Intrepid).

Because it puts the missing .so files in /usr/lib32, there's no need to futz with LDPATH. For example, after running the script, you can do either


to build 64 bit wine, or

./configure --target=i686-unknown-gnu-linux make to build 32 bit wine. Easy beans!

M. Lankhorst [dec 08]: Kai Tietz and I have been working on squashing all gcc related bugs. Now that they are gone I'm moving on to other stuff. Right now I want to have +relay working so that debugging will be a bit easier to do. If this works then I will need to work on exception handling and moving menus to wineserver. I will also need to talk with AJ some more about what he exactly wants from wineserver for 64-bits compatibility. There's enough to do without even worrying about the WoW64 stuff, so more help is of course welcome.

Winehq Bugzilla entry 18928 [Jun 09] ./configure ... --enable-win64 You realize you compiling something that's in alpha stage?

../../include/winnt.h:671: warning: 'ms_abi' attribute directive ignored

V. Margolen: Your compiler doesn't support required call conversion (ms_abi). You can't compile Wine-64 without that support.

Other Platforms and Processors

ARM Building from source

Note as of 2010 that this will not run Windows software unless you have the source code for your application and recompile using winelib, but it does work. Wine does not emulate the x86 processor and thus the software code will need to be recompiled. However according to a developer, a possibility is to use qemu. In future it might support windows mobile applications, but if you really want this, if this is your itch - recognise that this is an open source project and you can and should help with scratching this itch by developing or supporting the talented developers working on this such as Andre Hentschel.

V. K. Kamuju [Jul 06]: I have made a small patch has put in some basic framework for winedbg and wineserver for compiling on ARM (i think so). See WineHQ #285 ( I do not have an ARM based machine and Linux installed on it. And haven't tested it [thoroughly] I need someone to test this one. This patch may contain some bugs, use at your own risk. [wine archive]

and apparently not connected with Wine, but on the topic of ARM

Sparc Building from source


There has been some work towards Cygwin working with wine, but there is more to go.

Further Reading

Forum comments:

Changing the location of Wine's installation to RAM

A user wrote [feb 09]: I have created a tmpfs directory in my home directory. how do I [ install wine and all its libraries into your ram disk.]

IndeedAname: You need to build wine your self fetch the source and run this [..] before you use "make":

./configure --prefix="/path/to/the/place/you/have/your/ramdisk/mounted"

Then when you run wine use:

env WINEPREFIX="/path/to/the/place/you/have/your/ramdisk/mounted/myprefix" "/path/to/the/place/you/have/your/ramdisk/mounted/bin/wine" "(PROGRAM


By the way you will need to dump your ramdisk to your hard drive before you shutdown or you lost it all. but I'm sure you knew that.

The user reported back that worked nicely [..] but there is no speed improvement.

Changing the location of Wine's fake windows

V. Margolen Wine user May 2008: You can't really control where Wine itself is installed (unless you compile it yourself). However ~/.wine directory is Wine's "configuration". Wine is not installed there. [but this is the location of the fake windows] If you want to move that whole directory out to external harddrive (which CAN NOT be ntfs [Sept 08 update: Some reports appear to suggest that this may work if you have the very latest drivers for ntfs] or fat-32) you have to use WINEPREFIX environment variable. And set it to what you want "~/.wine" be. For example:

export WINEPREFIX=/media/external_drive/wine

Sept 08 wine user Jeffz: When you run wine, it operates in a prefix which is ~/.wine by default. Any files which are created when you run wine, such as the registry, installed programs etc exist there. If you want to start from scratch you remove or move ~/.wine

Alternatively, you can set a different prefix by using the WINEPREFIX environment variable, for example:

WINEPREFIX=/home/magicmaster87/wine-yugioh wine setup.exe

Each time, you want to use that prefix, you specify "WINEPREFIX=/home/magicmaster87/wine-yugioh"

A user asked [Aug 05]: How do I change $HOME/.wine for $HOME/.my-configuration ?

V. Margolen: Two steps:

F. Gouget: If the question is 'How do I get Wine to use $HOME/.my-configuration instead of $HOME/.wine?', then setting WINEPREFIX=$HOME/.my-configuration should do the trick. Wine Archive

This becomes handy when you have a version of wine which has all your favourite installations, but you want to test a new program.. W. Sippel [to do a clean install on a test application] Why not simply use a seperate dir for your experiments?

"WINEPREFIX=~/.winetest wineprefixcreate"


"WINEPREFIX=~/.winetest wine $RANDOM_TEST_APP" should be all you need, no? ;-) wine archive

Note in May 2008 A. Julliard bug 13113 said - There's no need to run wineprefixcreate any more, it's deprecated. Just run wine and everything happens automatically.

Ed. then you can undo or delete your testing with rm -rf [your temp wine install dir]

Howver Dietmar noticed a problem [Jan 07 wine user]: when I - double-click (in Nautilus) on the setup.exe of the windows program for installation [the] installer runs [and] I find the .wine in $HOME has been created.

I. Couchman: Run winecfg. Select the Drives tab. Highlight C: Change the path to point to the partion you want.

T. Carnecky: Add 'export WINEPREFIX=/wine' to $HOME/.bashrc (if you use bash). Maybe you'll have to restart nautilus (or logout and login again). R. Lovlie: Does nautilus really care about what's in ~/.bashrc? That's just a startup file for bash, isn't it?

T. Carnecky: edit /usr/share/applications/wine.desktop and change the 'Exec' line:

Exec=bash -i -c "wine %f"

I need the '-i' (interactive mode) to get bash load $HOME/.bashrc, you can omit it if you know which script bash sources if it is in non-interactive mode (maybe it's $HOME/.bash_profile but I'm not sure).

R. Riches Jr [Jan 07 wine user]: When environment variable WINEPREFIX is set, that becomes the root of the fake-windows area, instead of $HOME/.wine. You need to have the same WINEPREFIX value when you install an app vs. try to use it.

Killing Wineserver With a Different Wine Location

Here is an example for a wineprefix for ieforlinux. Note ie4linux is not supported by wine as it has too many overrides for wine developers to be able to debug..

D. Kegel[may 08]:to shut wineserver down cleanly[...] you need to do something like

WINEPREFIX=$HOME/.ies4linux/ie6 wineserver -k

Wine Bottles managing the location of the fake windows drive

A user asked [Oct 2006 wine-user] How does one set up different "bottles" like in Crossover office? Meaning how do I isolate an installation of Program A from Program B, when running under Wine? is that possible? That's a neat feature they have in Crossover, but I can't seem to find any documentation of how to do the samething in generic WINE.

O. Leidinger: You could use

wineprefix --prefix=~/somename

to create the "bottle" and then in bash:

WINEPREFIX=~/somename  winecfg
WINEPREFIX=~/somename  wine filename.exe


export WINEPREFIX=~/somename
wine filename.exe

in any case you've to set WINEPREFIX to access your new "bottle" [wine user oct2006]

Managing Multiple Installs

A user [May 06] asked how to use two installations of Wine. One being a normal Wine release, but the other a daily pull from cvs.

L. Pulzer:Just do

./configure --prefix=/opt/wine
(or /usr/local/wine, whatever suits you)
and run wine with /opt/wine/bin/wine.

The paths are adjusted automatically -- the wine from /opt/wine will use DLLs and other support files from /opt/wine. wine archive

This was asked again [nov 06 wine user]Can someone point me to instructions or FAQ on a logical way of running multiple versions of WINE at the same time. What I am getting at is sometimes an application fails to run with the latest and greatest of WINE. Sometimes an ap runs better with a newer version of WINE. What I would like to be able to do would be to run an ap with which ever version of WINE ran the best for me. I of course have the real estate to keep the code around for both or several versions of WINE. Any info on how to do this?

D. Skorka: Don't do a 'make install'. Keep the object files and executables in the source directory and run from there. You will of course have to use WINEPREFIX as well, to keep the registry and stuff seperate, as well as to insure that the correct wineserver is being used. BTW, programs being run under different wineservers will not be able to see each other.

A user asked via the mailing list: is Wine safe to run on SMP systems? M. Stefaniuc [Setp 05]: I'm running it since 1.5 years on a SMP system (P4, HT enabled and smp kernel). I don't remember to have run into SMP problems. Or better said in the problems i tried to debug there wasn't a SMP bug.

Further Reading

Running Wine from the Make Directory

This is a more advanced install.

A user asked [Sept 07 wine user]: can I just start wine from the make directory?

Another replied: you could run it from the directory where you fetch sources from git repository. [The ] Other programs are just under the_dir_where_sources_are/programs/program-name/program (eg.: winecfg is the_dir/programs/winecfg/winecfg)

Installing Gecko

Wine usually will automatically download Gecko, but there is another way which can be handy: L. Rayhen [Aug 07 wine user]: You can use winetricks:

Download it and install it like this:

sudo ln ./winetricks /usr/local/bin/
sudo chmod +x /usr/local/bin/winetricks

Now download and install gecko:

winetricks gecko

Please note that using winetricks you can install gecko engine to all your WINEPREFIXes without downloading it again (you need download it once) - this is very useful if you have a lot of WINEPREFIXes.

D. Riekenberg [Aug 07 wine user] Please don't do that at this time. The installed gecko version is outdated and use the old location. With a current wine, use:

wine iexplore.exe

[As of wine0.9.43 This opens a window which asks if you wish to install Gecko.]

Sharing the Wine

Installing Wine across Multiple desktops

Copying the a Wine Installation
A user [Jun 05]: With winetools 2.12 and the 2004-10-somethingorother release I'm finally able to 'use' wine with some industry specific little applications. (THANKS Joachim for making other's hard work so useable! I've been wanting to do this for ever and never got it to work previously.) So, I've installed wine, winetools and a half dozen Windows applications. I'd like to duplicate this setup across a bunch of desktops. Assuming I install the same version of wine and winetools on each desktop, can I just rsync the .wine folder I have onto each desktop? Is there anything stored outside of that folder I need to worry about? The only thing that occured to me was the link to the cdrom, but it's /mnt/cdrom on all of them....

J. von Thadden: You are right. Just copy the [.wine] folder [over to each desktop]. That's all.Wine Archive

[the aforementioned anonymous user above]: His advice could be a little misleading. There are a few links created by winetools 2.12 that are absolute not relative (i.e. ~/.wine/dosdevices/e: f: etc) If you rsync the folder to another machine or user with a different user name those links are broken. I'm not sure if they need to be absolute like that or a relative link (../../etc) would work. I'm *guessing* that they were done that way for a reason. I just used 'find ~/.wine -type l -ls' to get a list of all of the links and checked/rebuilt them by hand as required. Also of note if you just 'cp' 'scp' the .wine folder you'll be sorry ! :-) The default scp -r (recursive) option will follow the link from .wine/dosdevices/z: to '/' and there you have it - I nice big never ending loop that just fills your harddrive.

Sharing a Wine Installation

An advanced user request [Jun 05]: I am looking to setup a multi-user box so that hundreds of users can share the same base registry.

Username substitution would help in the registry processing. So when a flag is set for installing a global setting, registry keys written which include the username would instead put something like $username into the key.

Having an include directory could also be useful so that all the individual files inside the directory would be included. It would be usefull to disqualify files ending with a ~ character such as the Emacs program creates when creating temporary backups of the file you are editing. So I'm looking to eliminate having seperate (full) fake windows directories for every user. Are these concerns already addressed or dealt with in some other way?

Dosinger commented on a way for smaller situations: I've found a way to do so, but I have only a small home computer and not hundrets of users.

  1. I've put the C-Drive in /opt/windows, owned by root:root and writeable only by root.
  2. system.reg, dosdevices, userdef.reg and the config file are in /etc/wine. [Ed: the Config file was removed June 2005]
  3. In the home directories, there's a .wine directory with individual user.reg directories and soft links to the files in /etc/wine.
  4. I copy the applnk entries to a system wide directory(/usr/share/applnk/wine) and modify them manually so every user can see them in his start menu.

This way only root can install software and the users can't modify HKEY_LOCAL_MACHINE(They can temporarily for themselves, but it won't be stored and the others are not affected.

The major problem I have are those Apps which require full access to their install directories and installers which write required application settings to HKEY_CURRENT_USER. So basically the same problems as under Windows :-( Another thing is that even new applications do not really realize that I'm using the Administrator account if I am root, so that's why they install everything to HKEY_CURRENT_USER.

My hack works for a small system like mine.Wine Archive

Wine Terminal Server

A post to the list [April 06] asked: Would it be possible to use Wine with a few extra bits to make a kind of Windows Terminal Server? So you login via VNC, and the Wine system prompts you for a username and password, which it authenticates. It then loads up a "desktop", with a fake "Start" menu, that you have things similar to a normal start menu, but more appropriate to a terminal server environment. You then run your programs, but all the I/O is to/from the remote client, and each session is independent of each other, so there can be lots of different clients with different permissions (so admin may have full access to all of the drive, but users have various bits of their "hard drive" read-only and things like that).

Would seem to make Wine very useful if that could be done. Then VNC clients simply see a "Windows" desktop, and can do what they want, but all the back-end is Wine and Linux.

B. Harrosh: I have done something similar but with the X11 protocol. The client user browses to a web site (somewhere on the LAN). He than gets a Menu of applications /Sessions he can use. If these clients are Linux than no problem an ssh-X session is initiated to open that application. ( We used a load balanced collection of servers). If it was a Windows Client than first time comers get an OCX installed that in turn installs XMing X-Server and plink. Once installed, the web page will initiate the same ssh-X session as before. We chose remote application to run as Native apps so there is no distinction between locally running or remote applications. But a desktop mode can be used as well.

One thing to watch out is that: Currently, wine does not support multiple X connections on the same WineServer. What I did is use the ssh connection environment variables and set up a quick on-the-fly wine $WINEPREFIX folder for each new session. This gave me a nice Cytrix like control over what gets saved during a session. (Which was nothing in our case) Remoting is nothing new to Linux, and VNC could work Just as well. Wine is just a regular X-client application. Anything that applies to a Linux application also applies to a Wine application running under Wine. wine archive

Using An Existing Windows Partition

Ed. [Dec 06] When you install wine in a user home directory, if anything goes wrong you can easily copy important data files to a safe place and then wipe your .wine directory. You can set up wine again by typing winecfg and then reinstall your software. If anything goes wrong with your windows partition, then you need to reinstall windows which will keep you busy for a long time and of course you have backups, no?

W. Olgbugn: The general recommendation is to install applications separately under wine. [...] If you want to use an existing Windows partition, you have to do some more work. There are instructions at

Drescher [Oct 05] Gave a caution about using a Windows 2000 or XP ntfs formatted drive: [While] That can be done by mounting your ntfs drive in a folder under your linux filesystem then linking your Program Files folder to your ~/.wine/drive_c/Program Files folder, I do not believe this is a good idea for several reasons. First off. NTFS write support in linux does not work well at all. With the kernel drivers writing is limited to files that are the same # of blocks of storage and that are not compressed or encrypted. You can not copy or make new files. With the captive driver (which uses your windows dlls) it crashes frequently reverting your filesystem back to some old state.

It is far better to copy the programs you need to use into your ~/.wine/drive_c/Program Files folder. wine archive

Make Wine look beyond Wine's fake_c directory

[Mar 05]I want it to be able to look into into my directory where my work is located.

H. Bostick: You don't say what version of Wine you're using, but if you look in ~/.wine, you should see a /dosdevices directory, unless your version is very, very old. This is where Wine maps drives. The default mapped drives are c: , which points to Wine's "drive_c" folder, d: , which points to your home folder, and z: , which points to the / folder, allowing you to reach all the other folders on the system, as they are mounted somewhere in / . To simplify things, just create a symlink from any folder you want and name it with an unused drive letter (e: , f: , etc), and it will be seen by most Windows programs' file dialogs.

Naturally, you will want to make sure you have write permissions to the directory in question. Also, be aware that if you're using an additional mounted partition as a drive, some Windows install programs may not be able to calculate the free drive space correctly, and --depending on the installer used-- may give you a warning or may refuse to install. If this happens, and you know you have sufficient space, and the installer just gives a warning, then go on with the install and it should be fine. If the installer refuses to proceed, then you have little choice but to let the installer install to where it thinks it's OK, and then either

  1. live with it, or
  2. move the installed files to where you want them and then
    • edit the registry to change the install path or
    • symlink the install directory back to where the program thinks it is and set Wine to allow symlinks to be followed, using the config file. Wine Archive Link [Ed: The config file was removed in June 2005. Most settings were moved to the Wine Registry]

H. Bostick [May 05]: Where you install Wine is not relevant to this question (so just install it to the default location). [...]You don't have a C:\ or a D:\ drive under Linux. You have partitions, mounted to directories under the / filesystem.

Make a symbolic link in /home/username/.wine/dosdevices to your /home directory [or any other directory you want] and call it d:

To make a symlink, open a terminal and type

l n -s <source_directory_or_file> <location_and_name_of_the_final_link>

So to make a symlink in dosdevices, to /home, called d:, you would type

l n -s /home/username /home/username/.wine/dosdevices/d:

(replace "username" with the name of the user in question) and hit Enter.

Now browse to ~/.wine/dosdevices in a file manager, and click on the new d: link; you'll find yourself looking at your home directory. Then open a Windows program --notepad.exe is a good one for this experiment; wine notepad.exe in a terminal should bring it up. In the blank document, type anything, then save it to the D:\ drive as whatever.txt. Close notepad, open your file manager, and look for whatever.txt-- there it is, in your /home folder. [...]Windows programs now consider your /home folder to be the D:\ drive, because that's what your symlink told Wine to tell the Windows programs

if you want the files behind your[...] symlink to be accessible to Wine programs, you will need to change one line in the Wine configuration file (normally found at ~/.wine/config), because Wine normally cannot follow symlinks.

In this section of the configuration file

"Windows" = "c:\\windows"
"GraphicsDriver" = "x11drv"
;"ShowDirSymlinks" = "1"

;"ShowDotFiles" = "1"

The ';' symbol turns the line into a "comment", meaning the setting is ignored. This line must be changed (the ";" removed from in front), to read

"ShowDirSymlinks" = "1"

J. von Thadden: Winetools enables symlinks and hidden files by default. In the standard it makes these drives:

So via Z: you can access the whole file system. Note that during all installations of WineTools the drive Z: is moved away because namely Microsoft installers like to search all drives for installed software and this could need hours if they search through your whole hard disk via Z:. After performing the install the drive letter Z: is moved in again.Wine Archives

The Unixfs
Work has been ongoing to allow Wine access to the Unix file system. Jun 05 M. Jung: With the current CVS version, the unixfs shell namespace extension is now registered by default at the desktop [as long as you start without a pre existing wine directory].[...] So for a fresh install, you will end up with unixfs. But if you already have a '.wine' directory and want unixfs to be registered, you'll have to do it by hand. [...] If you do a 'regsvr32 shell32' you will see the unix filesystem in the file dialogs. It's probably still quite buggy though. It would be cool if we could get the biggest problems sorted out before the next release. So if you have an application, which doesn't work due to unixfs, please report to wine-devel.

[...]You still can only access the parts of the filesystem, which are accessible by a wine drive. You will see the complete unix directory structure, but you will only be able to select files, which are accessible by wine. The unix directories, which are not accessible, are much like the MyComputer folder in that they don't map to a windows filesystem location.

If you don't want to use unixfs, because you don't like it or because it totally breaks your setup, you can delete the following registry-key and you should be back to the old behaviour: This will also help you to figure out if a problem is due to unixfs. (If you do 'regsvr32 shell32' again, the key will be re-created.)Wine Archive


window partitions need not apply:

This is a job for a wine guru. Dont try this at home folks. This really crazy and wine is not built to run like this. One guy in [wine users 08] thought he had it worked out but perhaps rather ruefully he commented that Windows no longer booted.

user reported: I configured wine to use a windows partition. For this I created a symbolic link to the window partition in the dosdevices directory with ln -s /mnt/win_c c: .I changed variable in the config variable system, I put "c://windows//system32" and in the path variable also.

J. Hawkins [May05]: While it is possible to use a windows parition with wine, your best bet is to use the [automatically created]fake drive_c. wine includes (mostly) everything you need to run your windows programs.

J von Thadden further cautioned: I can definitely not recommend using a windows system with Wine. Many things are unpredictable [...]Wine Archive Link

Drive Labels

[May 05] Can Symlink names [be something ]other than lone alphabets? Can I call my Resumes/reference/letters folder that's inside the home partition "employ"?

H. Bostick: Not for Wine purposes, because Windows (and programs that run under Windows) does not understand any drive letters other than the 'lone alphabet' you refer to. So any symlinks that you make for Wine to use in the ~/.wine/dosdevices folder must be named a 'lone alphabet' letter.

J. von Thadden: if you want to have more meaningful names, make a file called .windows-label in the root-directory of the drives symlink. In the file you name the drive. In all windows file dialog boxes you will then get the drive letter with the additional name.Wine Archives

CDROM access

A user [Jan 06] was running a program in Wine which requires access to the CD ROM drive, but it appears that it couldn't find it. He then asked How do I tell it how to access the CD ROM drive?

S. Leichter: You need to create a link in the ~/.wine/dosdevices directory to the directory where you mount the CDROM in, e.g. wine archive

sle@sle3:~> ls -l .wine/dosdevices/ [snip] lrwxrwxrwx 1 sle users 12 2005-11-26 18:36 r: -> /media/cdrom lrwxrwxrwx 1 sle users 17 2005-11-26 18:36 w: -> /media/dvd

USB access

On user explained: all hardware is installed and operated through Linux and that's where Wine will look for it. Any hardware that isn't working under Linux will not work under Wine on a Linux system (at least that's the rule of thumb I use).

L. Rayhen noted the exception to the rule: Actually there is a lot of important cases when unsupported by Linux hardware works with WINE. Currently this is only possible for devices which work via tty and lp ports; devices which use ttyusb hardware also may work. For example my Samsung phone is unsupported on Linux and I have USB data-cabel. With WINE I can run Windows software so I can use all functionality of my phone via USB data-cabel. Unfortunatelly in case of non-ttyusb devices (almost all printers and scanners) you are out of luck. You need native (Linux) support or you can try to use lp port instead of usb but this will be slow even if it will work. If you really need to make to work any USB device (fully or partially unsupported on Linux and cannot find support on Linux and have no time to write drivers yourself you can use VMWare or QEmu and Windows drivers.[...] Of course first you should try to use Google to find out people who already found a way to make everything work on Linux. Only if that fails and you havn't time to write a driver yourself you can use VMWare and QEmu.

L. Rayhen: You need to create a symbolic link from COM device to TTY like this:

ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com2

This will create the symbolic link from COM2 to ttyUSB0.

Ed. There are some settings for parallel posts here

Saving to another partition

This is a matter of personal preference, but it is possible.

H. Bostick: Whenever I install a game with Wine, the first thing I do is find the "saves" directory and symlink it to a partition that I keep savegames on-- basically, I'd create a folder on the "storage" partition using the name of the game, and symlink that folder in the game's install directory, naming the symlink whatever the save game directory is supposed to be called according to the game. Naturally, I've got Wine set to recognize and allow symlinks (otherwise this wouldn't work at all). So when the game creates a savegame file, it's created on the storage partition rather than in my /home/.wine/c_drive/Program\ Files/game_install/saves directory.

For documents, I keep all my documents on the "storage" partition as well; map the "mydocs" (or whatever) folder on that partition to a drive letter in ~/.wine/dosdevices, and then I just save all my data files to E:\whatever. Audio files and pictures reside in a separate partition from application data as well, not to mention email. It's just a matter of specifying where the application is reading the data it's acting upon from, and it really makes backing up your personal volatile data much, *much* easier. Throw in a DVD, burn off everything in ~/storage (which is where the partition is mounted into the Linux filesystem), and life is good in case of disaster. Consolidating backup-able data in this way makes it much more likely that you *will* backup every now and again. Consolidating data files also makes disaster much more manageable-- even if you have to delete every other partition on the drive(s) to recover either Windows, or Linux, or both, you can easily avoid the data storage partition and reinstall the OS without fear that you've screwed yourself beyond recall. Wine Archives

Running in a Virtual Desktop

A user queried [Apr 2007 wine devel]: I have a single, very old application that needs to run in Windows 98 mode with a 640x480 virtual desktop. But, I'd like to run other applications at the same time. How come I can't set winecfg to make a virtual desktop for just this application, and handle everything else in the window manager?

L. Rahyan: Very simple. Run your application like this:

wine explorer /desktop=MyDesktopName,640x480 myprogram.exe

Then run your other applications as usual:

wine otherprogram.exe

It is obvious that you can setup short alias so you can just type: "myprogram" instead of "wine explorer /desktop=MyDesktopName,640x480 myprogram.exe" in the console (or you can make an launch icon if you preffer GUI for starting programs).

The user then asked: why doesn't winecfg let me do this?

A. Julliard: Because it wouldn't do what you want, since an app inherits the desktop of its parent; so the behavior has to be dependent on how you launch the app, not on the exe name.

The user suggested: When Wine detects that it's about to launch an app with special configurations set in winecfg, why can't it launch a new desktop as though we were calling an entirely new Wine instance? Alternatively, perhaps winecfg should be able to intelligently create and modify launchers for the start menu using its special overrides.

A. Julliard: Because usually when an app launches another one it expects to communicate with it, and that won't work if they are in separate desktops.

Wine in a Sandbox

A user asked [Jul 07 wine devel]: Is there a way to restrict wine from accessing some folders and/or resources? Ideally have Wine restraint in its WINEPREFIX directory and configure what resources it could access (like network for instance). I've seen few talks on having a 'sandbox' that date back to 2002 and most conclusions suggest that access restrictions should be made on the host OS. If that's the case, any tips on how one could do that in Linux would be appreciated.

S. Dossinger:Wine isn't a sandbox, and can't be used as one. The Windows App's code runs like any Linux native code, and thus it can call any Linux command. Most importantly, it can use Linux syscalls via int 0x80. So any security limitations imposed by Wine can be bypassed. You have to use things like chroot or a different user to restrict the Windows app.

M. Meissner: AppArmor, SELinux. Or use a seperate "Wine" user and use ssh -X wineuser@localhost (but this one could break out of it too).

Leszek: You might be interested in this question on launchpad: It describes how to run Internet Explorer in wine as a separated user.

Multiple Desktop Settings

P. Romanyszyan [May 06]: Somewhere at or after wine-0.9.11. The per application desktop was remove. All run on an explorer desktop or all don't. The option for a command like argument to set the desktop was mentioned.

V Povirk wrote: The command is wine explorer /desktop=name[,widthxheight] app.exe [args]

D. Clark: [regarding using winecfg to store virtual etc desktop settings on a per application basis.] :Though it is a bit cryptic how. Notice when you add an application in the Applications tab of winecfg, and click on it, the title of the window border changes to "Wine configuration for myapp.exe". So now when you go to the Graphics tab, the settings will effect only that application. wine archive

Emulated Desktop

A user queried: Is there a way to use different settings (ie: emulate virtual desktop, amount of hardware sound acceleration, etc.) for different programs run under wine? failing that, is there a way to turn on / off the emulation of a virtual desktop while running a program from the command line? I'd like to be able to run only certain programs, the ones that change the screen resolution, in a virtual desktop, and run all others without one. I'd also like to be able to use full hardware acceleration for sound in some programs, but have it set to "emulation" by default.

A user suggested [Jan 07 wine user] You can create an emulated desktop on the command line like this: wine explorer /desktop=default,640x480 /c/Program\ Files/Riven/Riven.exe

The exact path may vary. I have found the following to work:

wine explorer /desktop=default,640x480 c:/Program\ Files/Program/Program_executable.exe

Locales and Language

You can make wine use another Language, other than the one your computer is set as.

A user asked: How do i make wine use pl_PL@UTF-8 for some specific apps?

another replied [wine user Sept 06]: Like you would with any other app:

$ LC_ALL=pl_PL@UTF-8 wine foo.exe

Uninstalling Wine

Normally you would use your distribution's method of uninstalling. In the case where you have installed wine by compiling it you can still uninstall.

vitamin [jul 08]: In the terminal run:

which wine

If it returns something like "/usr/local/bin/wine" then you previously compiled and installed Wine yourself. And that directory you indicated above "winecomp" is most likely the source. If it is indeed the source dir you can 'cd' into it and run 'sudo make uninstall'. That should remove your self-compiled Wine.

Segin:[Apr 06] You can remove it by going to the source tree [by using the command line and changing to it's dir] and typing

make uninstall

However some have got themselves in a heap of trouble by installing, compiling and randomly removing parts. You can recover from this.

wineuser sept 08: I installed wine from compiling source code, and then deleted the source code. Now I want to update my wine, the README said I must uninstall the old version wine. How to uninstall it, the source code was deleted, I can't "make uninstall".

Vitamin: The simplest way - repeat the process again (extract source, configure). Only instead of make, run make uninstall.

and in the worst case one developer suggested: Segin [Apr 06]: If this fails, delete these files:


Kernel Issues


A user posted: since i upgraded my kernel to 2.6.16, wine segfaults immediatly after i start it. When i upgraded to 2.6.16, i also chose to use the 2G/2G vmsplit. Is wine supposed to work with that config?

A. Julliard: No, it won't work (and other apps will break too). Don't mess with vmsplit. wine archive

Posix Threading

A user noticed [Jun 05]: When I use wine in the default redhat 9 kernel 2.4.20-8, i see that the wineserver and wine-pthread binaries are running. Whereas when i use the vannila kernel 2.4.20, wineserver and wine-kthread binaries are running.

T. Rollo: It's Posix threads versus the older Linux threading. Redhat backported Posix threads to their 2.4 kernels, which is why wine-pthread is used for the Redhat kernel. 2.6 kernels also use wine-pthread. Non-redhat 2.4 and earlier kernels will use wine-kthread.Wine Archive

May 2008 wine user A. Julliard explained to a user: On any given setup, either wine-pthread or wine-kthread works, but not both. That's the way it's supposed to be, and that's why we have two of them. There's no reason whatsoever to force it to use the wrong one.

The user replied" In first time i use my application with wine 0.922 on kernel 2.3.31 and wine use kthread by default and my application have good performace and thread in my application work like windows, the graphics interface don't influece time critical thread now use kernel 2.6.21 and wine use automaticaly pthead and my application change performace on time critical thread, so i want try to use kthread. What can i change in setup kernel or wine setup for use by default kthread?

A. Julliard:The difference in behavior you see is not caused by kthread vs. pthread, it's caused by the different kernels. If you want the old behavior you should go back to the old kernel.

Jun 2008 bug 13749 A. Julliard: wine-pthread is for platforms with NPTL or TLS, wine-kthread for those without. Only one of them can work on any given platform, that's why we have two of them.

[ed. update. wine announcement approx may 09 notes - Get rid of the no longer supported wine-kthread. ]

Personal tools