Most of the most common configuration changes can be done with the Winecfg tool. We'll go through an easy, step-by-step introduction to Winecfg and outline the options available. In the next section we'll go over more advanced changes you can make using regedit as well as provide a complete reference to all Wine configuration settings. Finally, some things you might want to configure fall out of the scope of Winecfg and regedit, and we'll go over those.
In the past, Wine used a special configuration file that could be found in ~/.wine/config. If you are still using a version of Wine that references this file (older than June, 2005) you should upgrade before doing anything else. All settings are now stored directly in the registry and accessed by Wine when it starts.
Winecfg should have been installed on your computer along with the rest of the Wine programs. If you can't figure out how to start it, try running the command: $ /usr/local/bin/winecfg
or possibly just: $ winecfg
When the program starts you'll notice there are tabs along the top of the window for:
Applications
Libraries
Graphics
Desktop Integration
Drives
Audio
About
Changing settings in the Applications and Libraries tab will have the most impact on getting an application to run. The other settings focus on getting Wine itself to behave the way you want it to.
Note: The Applications, Libraries, and Graphics tabs are linked together! If you have Default Settings selected under Applications, all of the changes made within the Libraries and Graphics tabs will be changed for all applications. If you've configured a specfic application under the Applications tab and have it selected, then any changes made in Libraries or Graphics will affect only that application. This allows for custom settings for specific applications.
Wine has the ability to mimic the behavior of different versions of Windows. In general, the biggest difference is whether Wine behaves as a Win9x version or an NT version. Some applications require a specific behavior in order to function and changing this setting may cause a buggy app to work. Recently Wine's default Windows version has changed to Windows 2000. It's known that many applications will perform better if you choose Windows 98.
Within the tab you'll notice there is a Default Settings entry. If you select that you'll see the current default Windows Version for all applications. A troublesome application is best configured separately from the Default Settings. To do that:
Click on the Add application button.
Browse until you locate the .exe
After it's been added you can choose the specific Windows version Wine will emulate for that application.
Likewise, some applications require specific libraries in order to run. Wine reproduces the Windows system libraries (so-called native DLL's) with completely custom versions designed to function exactly the same way but without requiring licenses from Microsoft. Wine has many known deficiencies in it's built-in versions, but in many instances the functionality is sufficient. Using only builtin DLL's ensures that your system is Microsoft-free. However, Wine has the ability to load native Windows DLL's.
It's not always possible to run an application on builtin DLL's. Sometimes native DLL's simply work better. After you've located a native DLL on a Windows system, you'll need to put it in suitable place for Wine to find it and then configure it to be used. Generally the place you need to put it is in the directory you've configured to be c:\windows\system32 (more on that in the drives section). There are four DLL's you should never try to use the native versions of: kernel32.dll, gdi32.dll, user32.dll, and ntdll.dll. These libraries require low-level Windows kernel access that simply doesn't exist within Wine.
With that in mind, once you've copied the DLL you just need to tell Wine to try to use it. You can configure Wine to choose between native and builtin DLL's at two different levels. If you have Default Settings selected in the Applications tab, the changes you make will affect all applications. Or, you can override the global settings on a per-application level by adding and selecting an application in the Applications tab.
To add an override for FOO.DLL, enter "FOO" into the box labeled New override for library: and click on the Add button. To change how the DLL behaves, select it within the Existing overrides: box and choose Edit. By default the new load order will be native Windows libraries before Wine's own builtin ones (Native then Builtin). You can also choose native only, builtin only, or disable it altogether.
The Wine team has determined that it is necessary to create fake DLL files to trick many programs that check for file existence to determine whether a particular feature (such as Winsock and its TCP/IP networking) is available. If this is a problem for you, you can create empty files in the configured c:\windows\system32 directory to make the program think it's there, and Wine's built-in DLL will be loaded when the program actually asks for it. (Unfortunately, tools/wineinstall does not create such empty files itself.)
Applications sometimes also try to inspect the version resources from the physical files (for example, to determine the DirectX version). Empty files will not do in this case, it is rather necessary to install files with complete version resources. This problem is already fixed for many files. For others, you may still need to grab some real DLL files to fool these apps with.
There are of course DLLs that Wine does not currently implement very well (or at all). If you do not have a real Windows you can copy necessary DLLs from, you can always get some from one of the Windows DLL archive sites that can be found via internet search engine. Please make sure to obey any licenses on the DLLs you fetch; some are redistributable, some aren't.
In case Wine complains about a missing DLL, you should check whether this file is a publicly available DLL or a custom DLL belonging to your program (by searching for its name on the internet). After you've located the DLL, you need to make sure Wine is able to use it. DLLs usually get loaded in the following order:
The directory the program was started from.
The current directory.
The Windows system directory.
The Windows directory.
The PATH variable directories.
There are basically five different graphics settings you can configure. For most people the defaults are fine.
The first few settings primarily affect games and are somewhat self-explanatory. You can prevent the mouse from leaving the window of a DirectX program (i.e. a game.) and the default is to have that box checked. There's lots of reasons you might want to do that, not the least of which includes it's easier to play the game if the cursor is confined to a smaller area. The other reason to turn this option on is for more precise control of the mouse - Wine warps the location of the mouse to mimic the way Windows works. Similarly, "desktop double buffering" allows for smoother updates to the screen, which games can benefit from, and the default is to leave it turned on. The tradeoff is increased memory use.
You may find it helpful to Emulate a virtual desktop. In this case, all programs will run in a separate window. You may find this useful as a way to test buggy games that change (possibly unsuccessfully) the screen resolution. Confining them to a window can allow for more control over them at the possible expense of decreased usability. Sizes you might want to try are 640x480 (the default) or 800x600.
Finally, you can configure some Direct3D settings. For the most part these settings are detected automatically, but you can force them to behave in a specific manner. Some games attempt to probe the underlying system to see if it supports specific features. By turning these off Wine won't report the ability to render games in a certain way. It may lead to the game running faster at the expense of the quality of the graphics or the game may not run at all.
Windows requires a fairly rigid drive configuration that Wine imitates. Most people are familiar with the standard notation of the "A:" drive representing the floppy disk, the "C:" drive representing the primary system disk, etc. Wine uses the same concept and maps those drives to the underlying native filesystem.
Wine's drive configuration is relatively simple. In Winecfg under the Drives tab you'll see buttons to add and remove available drives. When you choose to add a drive, a new entry will be made and a default drive mapping will appear. You can change where this drives points to by changing what's in the Path: box. If you're unsure of the exact path you can choose "Browse" to search for it. Removing a drive is as easy as selecting the drive and clicking "Remove".
Winecfg has the ability to automatically detect the drives available on your system. It's recommended you try this before attempting to configure drives manually. Simply click on the Autodetect button to have Wine search for drives on your system.
You may be interested in configuring your drive settings outside of Winecfg, in which case you're in luck because it's quite easy. All of the drive settings reside in a special directory, ~/.wine/dosdevices. Each "drive" is simply a link to where it actually resides. Wine automatically sets up two drives the first time you run Wine:
$ ls -la ~/.wine/dosdevices/ lrwxrwxrwx 1 wineuser wineuser 10 Jul 23 15:12 c: -> ../drive_c lrwxrwxrwx 1 wineuser wineuser 1 Jul 23 15:12 z: -> /
To add another drive, for example your CD-ROM, just create a new link pointing to it: $ ln -s /mnt/cdrom ~/.wine/dosdevices/d: Take note of the DOS-style naming convention used for links - the format is a letter followed by a colon, such as "a:". So, if the link to your c: drive points to ~/.wine/drive_c, you can interpret references to c:\windows\system32 to mean ~/.wine/drive_c/windows/system32.
Wine can work with quite a few different audio subsystems which you can choose under the "Audio" tab. winecfg figures out all available drivers for you, but you can manually select which driver will be used. Older Linux distributions using the 2.4 kernel or earlier typically use the "OSS" driver. Usually 2.6 kernels have switched to "ALSA". The "aRts" driver was recently deactivated due to the general lack of maintenance of the "aRts" subsystem. If you're using GNOME you can probably use EsounD. The OSS and ALSA audio drivers get the most testing, so it's recommended you stick with them if possible. If you need to use "Jack", "NAS" or "CoreAudio" you probably already know why.
DirectSound settings are primarily used by games. You can choose what level of hardware acceleration you'd like, but for most people "Full" is fine.
Wine can load Windows themes if you have them available. While this certainly isn't necessary in order to use Wine or applications, it does allow you to customize the look and feel of a program. Wine supports the newer MSStyles typ of themese. Unlike the older Microsoft Plus! style themes, the uxtheme engine supports special .msstyles files that can retheme all of the Windows controls. This is more or less the same kind of theming that modern Linux desktops have supported for years. If you'd like to try this out:
Download a Windows XP theme. Be sure it contains a .msstyles file.
Create a set of new directories in your fake Windows drive: $ mkdir -p ~/.wine/drive_c/windows/Resources/themes/name-of-your-theme
Move the .msstyles to that new name-of-your-theme directory.
Use the Desktop Integration tab of winecfg to select the new theme.