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.
In short: either put the required DLL into your program
directory (might be ugly), or put it into the Windows system
directory. Also, if possible you probably shouldn't use NT-based
native DLLs, since Wine's NT API support is somewhat weaker than
its Win9x API support (possibly leading to even worse compatibility
with NT DLLs than with a no-windows setup!).
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:
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.
