Wine под root

  1. Overview / About
  2. Content overview / Steps to take
  3. Quick start
  4. What is Wine, and how can it help me?
  5. Wine features
  6. Other Versions of Wine
  7. Alternatives to Wine you might want to consider
  8. Native Applications
  9. Another Operating System
  10. Virtual Machines
  11. Wine Installation Methods
  12. Installation from a package
  13. Installation from a source archive
  14. Installation from a Git tree
  15. Installing Wine from a package
  16. Different Distributions
  17. Installing Wine from source
  18. Compiling Wine
  19. Uninstalling Wine from Source
  20. Chapter 3. Running Wine
  21. Applications and control panel applets
  22. How to run Wine
  23. Explorer-like graphical Wine environments
  24. Environment variables
  27. OSS Audio Driver Settings
  28. Wineserver Command Line Options
  29. -k []
  30. -p []
  31. Setting Windows/DOS environment variables
  32. Text mode programs (CUI
  33. Configuration of CUI executables
  34. Chapter 4. Configuring Wine
  35. Using Winecfg
  36. Application Settings
  37. Libraries Settings
  38. Notes About System or Missing DLLs
  39. Graphics Settings
  40. Drive Settings
  41. Audio Settings
  42. Desktop Integration
  43. Registry Structure
  44. Registry Files
  45. System Administration Tips
  46. Other Things to Configure
  47. Serial and Parallel Ports
  48. Network Shares
  49. Fonts
  50. Printers
  51. Scanners
  52. Configuring ODBC on Unix
  53. Using Windows ODBC drivers
  54. What to do if some program still doesn’t work?
  55. Use different startup paths
  56. Check your system environment!
  57. Reconfigure Wine
  58. Check out further information
  59. General questions
  60. Does Wine hurt Linux or other free operating systems?
  61. What is the difference between Wine, CrossOver, and Cedega?
  62. How does the Wine version numbering system work?
  63. What applications run well with Wine?
  64. I think I’ve found a bug. How do I report this to WineHQ?
  65. Where can I get further help?
  66. Does Wine run on all Unix filesystems?
  67. Which version of Wine should I use?
  68. How do I install Wine?
  69. Is there a 64 bit Wine?
  70. Where can I find old Wine binary packages?
  71. How do I install Wine on my netbook (eeePC, Acer Aspire One, etc
  72. Installing on Apple
  73. How do I apply a patch?
  74. How do I uninstall Wine?
  75. Installing and Running Windows Applications
  76. How do I run an installer using Wine?
  77. How do I launch native applications from a Windows application?
  78. My installer tells me I don’t have enough free disk space
  79. When I double-click on a. exe file in my file manager, nothing happens

Overview / About

If, after examining this guide,
the FAQ, and
other relevant documentation there is still something you
cannot figure out, we would love to hear from you.
The mailing
lists section contains several mailing lists and an
IRC channel, all of which are great places to seek help and
offer suggestions. If you are particularly savvy, and
believe that something can be explained better, you can file
a bug report
or post
a patch on Wine documentation itself.

Content overview / Steps to take

In order to be able to use Wine, you must first have a working
installation. This guide will help you to move your system
from an empty, Wineless void to one boasting a fresh, up to
date Wine install. The first step, Getting Wine, illustrates the
various methods of getting Wine’s files onto your computer.
The second step, Configuring
Wine, shows how to customize a Wine installation depending
on your individual needs. The final step, Running Wine, covers the specific
steps you can take to get a particular application to run
better under Wine, and provides useful links in case you need
further help.

Quick start

Different software programs are designed for different
operating systems, and most won’t work on systems that they
weren’t designed for. Windows programs, for example, won’t run
in Linux because they contain instructions that the system can’t
understand until they’re translated by the Windows environment.
Linux programs, likewise, won’t run under the Windows operating
system because Windows is unable to interpret all of their

What is Wine, and how can it help me?

Wine makes it possible to run Windows programs alongside any
Unix-like operating system, particularly Linux. At its heart,
Wine is an implementation of the Windows Application
Programing Interface (API) library, acting as a bridge between
the Windows program and Linux. Think of Wine as a compatibility
layer, when a Windows program tries to perform a function that
Linux doesn’t normally understand, Wine will translate that
program’s instruction into one supported by the system. For
example, if a program asks the system to create a Windows
pushbutton or text-edit field, Wine will convert that
instruction into its Linux equivalent in the form of a command
to the window manager using the standard X11 protocol.

Wine features

Wine is an open source project, and there are accordingly
many different versions of Wine for you to choose from. The
standard version of Wine comes in intermittent releases
(roughly twice a month), and can be downloaded over the
Internet in both prepackaged binary form and ready to compile
source code form. Alternatively, you can install a development
version of Wine by using the latest available source code from
the Git repository. See the next chapter, Getting Wine, for further details.

Other Versions of Wine

There are a number of programs that are derived from the
standard Wine codebase in some way or another. Some of these
are commercial products from companies that actively contribute
to the Wine project.

These products try to stand out or distinguish themselves
from the standard version of Wine by offering greater
compatibility, easier configuration, and commercial support.
If you require such things, it is a good idea to consider
purchasing these products.

Table 1-1. Various Wine offerings

Alternatives to Wine you might want to consider

There are many ways to run software other than through Wine. If
you are considering using Wine to run an application you might
want to think about the viability of these approaches if you
encounter difficulty.

Native Applications

Instead of running a particular Windows application with Wine,
one frequently viable alternative is to simply run a different
application. Many Windows applications, particularly more
commonly used ones such as media players, instant messengers,
and filesharing programs have very good open source equivalents.
Furthermore, a sizable number of Windows programs have been
ported to Linux directly, eliminating the need for Wine (or
Windows) entirely. These alternatives should be found through
your system package management facilities.

Another Operating System

Probably the most obvious method of getting a Windows
application to run is to simply run it on Windows. However,
security, license cost, backward-compatibility, and machine
efficiency issues can make this a difficult proposition, which
is why Wine is so useful in the first place.

Virtual Machines

Rather than installing an entirely new operating system on your
machine, you can instead run a virtual machine at the software
level and install a different operating system on it. Thus, you
could run a Linux system and at the same time run Windows along
with your application in a virtual machine simultaneously on the
same hardware. Virtual machines allow you to install and run
not only different versions of Windows on the same hardware, but
also other operating systems, including ReactOS.

There are several different virtual machine offerings out there,
and some are also able to emulate x86 hardware on different
platforms. The open source Bochs,
VirtualBox and
QEMU can run
both Windows and ReactOS virtually. Other, commercial virtual
machine offerings include VMware and Microsoft’s

There are significant drawbacks to using virtual machines,
however. Unlike Wine, such programs
emulators, so there is an inevitable speed decrease which can
be quite substantial. Furthermore, running an application
inside a virtual machine prevents fully integrating the
application within the current environment. You won’t, for
example, be able to have windows system tray icons or program
shortcuts sitting alongside your desktop Linux ones, since
instead the Windows applications must reside completely within
the virtual machine.

Wine Installation Methods

Once you’ve decided that Wine is right for your needs, the next step is
to decide how you want to install it. There are three methods for
installing Wine from WineHQ, each with their own advantages and

Installation from a package

By far the easiest method for installing Wine is to use a prepackaged
version of Wine. These packages contain ready-to-run Wine binary
files specifically compiled for your distribution, and they are
tested regularly by the packagers for both functionality and

Packages are the recommended method for installing Wine. We make
them easily available at the WineHQ downloads page,
and these are always the latest packages available. Being
popular, Wine packages can also be found elsewhere in official
distribution repositories. These can, however, sometimes be out of
date, depending on the distribution. Packages are easily upgradable
as well, and many distributions can upgrade Wine seamlessly with a
few clicks. Building your own installable binary package from a
source package is also possible, although it is beyond the scope of
this guide.

Installation from a source archive

Sometimes the Wine packages don’t fit your needs exactly. Perhaps
they’re not available for your architecture or distribution, or
perhaps you want to build Wine using your own compiler optimizations
or with some options disabled, or perhaps you need to modify a
specific part of the source code before compilation. Being an open
source project, you are free to do all of these things with Wine
source code, which is provided with every Wine release. This method
of installation can be done by downloading a Wine source archive and
compiling from the command line. If you are comfortable with such
things and have special needs, this option may be for you.

Getting Wine source archives is simple. Every release, we put a
source package in compressed tar.bz2 format
at the WineHQ downloads
page. Compiling and installing Wine from source is slightly
more difficult than using a package, however we will cover it in
depth and attempt to hold your hand along the way.

Installation from a Git tree

If you wish to try out the bleeding edge of Wine development, or
would even like to help develop Wine yourself, you can download the
very latest source code from our Git repository. Instructions for
downloading from the Wine Git repository are available at

Please take note that the usual warnings for using a developmental
version still apply. The source code on the Git repository is largely
untested and may not even compile properly. It is, however, the
best way to test out how Wine will work in the next release, and if
you’re modifying source code it’s best to get the latest copy. The
Git repository is also useful for application maintainers interested
in testing if an application will still work right for the next
release, or if a recent patch actually improves things. If you’re
interested in helping us to get an application working in Wine, see
the HowTo.

Installing Wine from a package

Installing a package on a fresh system is remarkably straightforward.
Simply download and install the package using whatever utility your
distribution provides. There is usually no need to explicitly
remove old packages before installing, as modern Linux distributions
should upgrade and replace them automatically. If you installed
Wine from source code, however, you should remove it before
installing a Wine package. See the section on uninstalling Wine from source
for proper instructions.

Different Distributions

Wine works on a huge amount of different Linux distributions, as well
other Unix-like systems such as Solaris and FreeBSD, each with their
own specific way of installing and managing packages. Fortunately,
however, the same general ideas apply to all of them, and installing
Wine should be no more difficult than installing any other software,
no matter what distribution you use. Uninstalling Wine packages is
simple as well, and in modern Linux distributions is usually done
through the same easy interface as package installation.

We won’t cover the specifics of installing or uninstalling Wine
packages among the various systems’ methods of packaging and package
management in this guide, however, up to date installation notes for
particular distributions can be found at the WineHQ website in the
If you need further help figuring
out how to simply install a Wine package, we suggest consulting your
distribution’s documentation, support forums, or IRC channels.

Installing Wine from source

If you wish to install build dependencies by hand, there are several
ways to see if you’re missing some useful development libraries.
The most straightforward approach is to watch the output of
configure before you compile Wine and see if anything
important is missing; if it is, simply install what’s missing and rerun
configure before compiling. You can also check the file
configure generates (include/config.h) and see what files
configure is looking for but not finding.

Compiling Wine

$ ./configure
$ make depend
$ make
# make install

The last command requires root privileges. Although you should
never run Wine as root, you will need to install it this way.

Uninstalling Wine from Source

# make uninstall

Chapter 3. Running Wine

This chapter will describe all aspects of running Wine, like e.g.
basic Wine invocation, command line parameters of various Wine
support programs etc.

Applications and control panel applets

Applications are installed under Wine the same way you would
in Windows: by running the installer. You can just accept the
defaults for where to install, most installers will default to
C:Program Files, which is fine. If the application
installer requests it, you may find that Wine creates icons on
your desktop and in your app menu. If that happens, you can
start the app by clicking on them.

The standard way to uninstall things is for the application to
provide an uninstaller, usually registered with the «Add/Remove
Programs» control panel applet.
To access the Wine equivalent, run the uninstaller
program (it is located in the
programs/uninstaller/ directory in a Wine
source directory) in a terminal:

Дополнительно:  Root доступ как отключить на xiaomi redmi

$ wine uninstaller

Some programs install associated control panel applets, examples
of this would be Internet Explorer and QuickTime. You can access
the Wine control panel by running in a

$ wine control

which will open a window with the installed control panel
applets in it, as in Windows.

If the application doesn’t install menu or desktop items, you’ll
need to run the app from the command line. Remembering where you
installed to, something like:

$ wine «C:Program Filesappnameappname.exe»

will probably do the trick. The path isn’t case sensitive, but
remember to include the double quotes. Some programs don’t
always use obvious naming for their directories and executable files,
so you might have to look inside the Program Files
directory to see what was put where.

How to run Wine

You can simply invoke the wine command to
get a small help message:

You could run the file
c:windowssystem oo.exe with:

$ wine foo.exe

However, you would have to run the file
c:myapps oo.exe with this command:

$ wine c:\myapps\foo.exe

(note the backslash-escaped »)

$ wine ~/.wine/drive_c/myapps/foo.exe

For details on running text mode (CUI) executables, read the
section below.

Explorer-like graphical Wine environments

If you prefer using a graphical interface to manage your
files you might want to consider using winefile. This Winelib
application comes with Wine and can be found with the other
Wine programs. It is a useful way to view your drive configuration
and locate files, plus you can execute programs directly from
winefile. Please note that many functions are not yet implemented.

Environment variables

Wine isn’t perfect, and many Windows applications still
don’t run without bugs under Wine (but then, a lot of programs
don’t run without bugs under native Windows either!). To
make it easier for people to track down the causes behind
each bug, Wine provides a number of debug
channels that you can tap into.

Each debug channel, when activated, will trigger logging
messages to be displayed to the console where you invoked
wine. From there you can redirect the
messages to a file and examine it at your leisure. But be
forewarned! Some debug channels can generate incredible
volumes of log messages. Among the most prolific offenders
are relay which spits out a log
message every time a win32 function is called,
win which tracks windows message
passing, and of course all which is
an alias for every single debug channel that exists. For a
complex application, your debug logs can easily top 1 MB and
higher. A relay trace can often
generate more than 10 MB of log messages, depending on how
long you run the application. (You’ll want to check out
RelayExclude registry key to
modify what the relay trace reports).
Logging does slow down Wine
quite a bit, so don’t use WINEDEBUG
unless you really do want log files.

Within each debug channel, you can further specify a
message class, to filter out the
different severities of errors. The four message classes
trace, fixme, warn, err.

To turn on a debug channel, use the form
To turn it off, use
To list more than one channel in the same WINEDEBUG
option, separate them with commas. For example, to request
warn class messages in the
heap debug channel, you could invoke
wine like this:

$ WINEDEBUG=warn+heap wine program_name

If you leave off the message class, Wine
will display messages from all four classes for that channel:

$ WINEDEBUG=heap wine program_name

If you wanted to see log messages for everything except the
relay channel, you might do something like this:

$ WINEDEBUG=+all,-relay wine program_name

You can find a list of the debug channels and classes at
More channels will be added to (or subtracted from) later versions.


It’s not always possible to run an application on builtin
DLLs. Sometimes native DLLs simply work better. Although
these DLL overrides can be set using winecfg you might want
to use the WINEDLLOVERRIDES environment variable to set them.

$ WINEDLLOVERRIDES=»comdlg32,shell32=n,b» wine program_name

Try to load comdlg32 and shell32 as native Windows DLLs first and try the builtin
version if the native load fails.

$ WINEDLLOVERRIDES=»comdlg32,shell32=n;c:\foo\bar\baz=b» wine program_name

Try to load the comdlg32 and shell32 libraries
as native windows DLLs. Furthermore, if an application requests to load
c: ooaraz.dll load
the builtin library baz.

$ WINEDLLOVERRIDES=»comdlg32=b,n;shell32=b;comctl32=n;oleaut32=» wine program_name

Try to load comdlg32 as builtin first and try the
native version if the builtin load fails; load shell32 always as builtin and comctl32 always as native. oleaut32 will be disabled.


Specifies the Windows architecture to support. It can be set either to
win32 (support only 32-bit applications), or to
win64 (support both 64-bit applications and 32-bit
ones in WoW64 mode).
The architecture supported by a given Wine prefix is set at prefix
creation time and cannot be changed afterwards. When running with an
existing prefix, Wine will refuse to start if WINEARCH doesn’t match
the prefix architecture.

OSS Audio Driver Settings

As an example:

$ AUDIODEV=/dev/dsp4 MIXERDEV=/dev/mixer1 MIDIDEV=/dev/midi3 wine program_name

Wineserver Command Line Options

Sets the debug level for debug output in the terminal that
wineserver got started in at level
In other words: everything greater than 0 will enable
wineserver specific debugging output.

Display wineserver command line options help message.

-k []

Kill the current wineserver, optionally with signal

-p []

This parameter makes wineserver persistent, optionally
for n seconds. It will prevent
wineserver from shutting down immediately.

Usually, wineserver quits almost immediately after the last
Wine process using this wineserver terminated.
However, since wineserver loads a lot of things on startup
(such as the whole Windows registry data), its startup might
be so slow that it’s very useful to keep it from exiting after
the end of all Wine sessions, by making it persistent.

This parameter makes a newly started wineserver wait until the
currently active instance terminates.

Setting Windows/DOS environment variables

Your program might require some environment variable to be set
properly in order to run successfully.
In this case you need to set this environment variable in the
Linux shell, since Wine will pass on the entire shell environment
variable settings to the Windows environment variable space.
Example for the bash shell (other shells may have a different syntax!):

This will make sure your Windows program can access the
MYENVIRONMENTVAR environment variable once you start your program using Wine.
If you want to have MYENVIRONMENTVAR set permanently, then you can
place the setting into

, or also

when using bash.

Note however that there are some exceptions to the rule:
If you want to change the PATH, SYSTEM or
TEMP variables, then of course
you can’t modify it that way, since this will alter the Unix environment
settings. Instead, you should set them into the registry. To set them
you should launch wine regedit and then go to the

key. Now you can create
or modify the values of the variables you need

«System» = «c:\windows\system»

This sets up where the Windows system files are. The Windows
system directory should reside below the directory used for the

Thus when using

as Windows path, the system directory would be

It must be set with no trailing slash, and you must be sure that
you have write access to it.

«Temp» = «c:\temp»

This should
be the directory you want your temp files stored in,

in our previous example.
Again, no trailing slash, and !!!

«Path» = «c:\windows;c:\windows\system;c:\blanco»

Behaves like the PATH setting on UNIX
boxes. When Wine is run like wine sol.exe, if

resides in a directory specified in the

setting, Wine will run it (of
course, if

resides in the
current directory, Wine will run that one). Make sure it
always has your

and system directory (for this setup, it must contain

Text mode programs (CUI

Given the wide scope of features above, and the current usage
in Un*x world, Wine comes out with three different ways for
running a console program (aka a CUI executable):

Table 3-1. Basic differences in consoles

Configuration of CUI executables

Here’s the list of the items you can configure, and their

Table 3-2. Wineconsole configuration options

Chapter 4. Configuring Wine

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.

Using Winecfg

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 winecfg.

When the program starts you’ll notice there are tabs along the top
of the window for:

Changing settings in the
tabs 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 , , and
tabs are linked together! If you have «Default
Settings» selected under , all of the changes made
within the and tabs will
be changed for all applications. If you’ve configured a specific application under the
tab and have it selected, then any changes made in
or will affect only that
application. This allows for custom settings for specific applications.

Application Settings

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. Wine default Windows version
is Windows XP. Some applications may perform better if you
choose Windows 98.

Within the tab you’ll notice there is a
entry. If you select that
you’ll see the current default
for all applications. A troublesome application
is best configured separately from the Default Settings. To do that:

Libraries Settings

Likewise, some applications require specific libraries in order
to run. Wine reproduces the Windows system libraries (so-called
native DLLs) with completely custom versions designed to
function exactly the same way but without requiring licenses
from Microsoft. Wine has many known deficiencies in its
built-in versions, but in many instances the functionality
is sufficient. Using only builtin DLLs ensures that your
system is Microsoft-free. However, Wine has the ability to
load native Windows DLLs.

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 DLLs at two different levels.
If you have selected
in the 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 tab.

To add an override for FOO.DLL, enter
FOO into the box
labeled New override for library: and
click on the button. To change how
the DLL behaves, select it within the Existing
overrides: box and choose .
By default the new load order will be native Windows libraries
before Wine builtin ones (Native then
Builtin). You can also choose native only, builtin
only, or disable it altogether.

Notes About System or Missing DLLs

There are of course DLLs that Wine does not currently implement
very well (or at all).

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. In the latter case, check that you have installed
your program correctly.

Most often applications will assume that a required redistributable
package has already been installed and subsequently fail to run when
the required dependencies are not met. For example:

err:module:import_dll Library MFC42.DLL (which is needed by L»C:\Program Files\Foo\Bar.dll») not found

Redistributable packages which install the necessary runtimes can
be obtained through the use of winetricks. Note
these components are subject to their own
license and are not part of the Wine project. You should refer to
the application’s AppDB
entry for advice on what is required.

Graphics Settings

There are basically five different graphics settings you
can configure. For most people the defaults are fine.

The first setting primarily affect games and is somewhat
self-explanatory. You can prevent the mouse from leaving the
window of a full-screen program (e.g. a game) and the default
is to not have that box checked. That is mostly needed when using
a virtual desktop.

Drive Settings

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

Дополнительно:  Ubuntu password recovery give root password for maintenance

Wine drive configuration is relatively simple.
In winecfg under the 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 drive points to by changing what’s in the
box. If you’re unsure of the
exact path you can choose to search for it.
Removing a drive is as easy as selecting the drive and
clicking .

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 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
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:

Audio Settings

Wine can work with quite a few different audio subsystems.
You can see the selected driver that Wine figures out for you
under the tab.

You can manually select which device will be used for
Output, Input, Voice output and Voice input. For example you can choose
the digital output of your sound device instead of the analog one.

Desktop Integration

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 type of themes. 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:

All of the settings you change in winecfg, with exception of
the drive settings, are ultimately stored in the registry.
In Windows, this is a central repository for the configuration
of applications and the operating system. Likewise, Wine
implements a registry and some settings not found in Winecfg
can be changed within it (there’s actually more of a chance
you’ll need to dip into the registry to change the settings of an application
than Wine itself).

Now, the fact that Wine itself uses the registry to store settings
has been controversial. Some people argue that it’s too much like
Windows. To counter this there are several things to consider.
First, it’s impossible to avoid implementing a registry simply
because applications expect to be able to store their settings there.
In order for Wine to store and access settings in a separate
configuration file would require a separate set of code to basically
do the same thing as the Win32 APIs Wine already implements.

Registry Structure

This fundamental root key (in win9x it’s stored in the
hidden file system.dat) contains
everything pertaining to the current Windows
installation. This is often abbreviated HKLM.

This is a link to HKEY_LOCAL_MACHINESoftwareClasses.
It contains data describing things like file
associations, OLE document handlers, and COM classes.

Registry Files

This file contains HKEY_LOCAL_MACHINE.

These files are automatically created the first time you use
Wine. A set of global settings is stored in the
wine.inf file and is processed by
the rundll32.exe program. The first
time you run Wine the wine.inf file
gets processed to populate the initial registry. The
registry is also updated automatically
if wine.inf changes, for instance when
upgrading to a newer Wine version.

Note: Older Wine versions (before 1.0) required you to run
the wineprefixcreate command manually to
upgrade your settings. This is no longer necessary.

It is not advisable to edit these files to modify the registry
as they are managed by Wine internally. Use regedit.exe,
reg.exe or any program which uses the standard registry functions.

An easy way to access and change the registry is with the
regedit tool. Similar to the Windows
program it replaces, regedit serves to provide a system level
view of the registry containing all of the keys. When you start it, you’ll
immediately notice that the cryptic keys displayed in the text file
are organized in a hierarchical fashion.

To navigate through the registry, click on the keys on the
left to drill down deeper. To delete a key, click on it and
choose from the menu. To add a
key or value, locate where you want to put it and choose
from the menu. Likewise, you modify an existing key by
highlighting it in the right-hand window pane and choosing
from the menu. Another way to
perform these same actions is to right-click on the key or value.

System Administration Tips

cd ~root/.wine
cp system.reg /usr/local/etc/wine.systemreg

ln -sf /usr/local/etc/wine.systemreg system.reg

Note that the tools/wineinstall script
used to do some of this if you installed Wine source as root, however
it no longer does.

Other Things to Configure

This section is meant to cover the rest of the things you can configure.
It also serves as a collection of tips and tricks to get the most out
of using Wine.

Serial and Parallel Ports

ln -s /dev/ttyS0 com1
ln -s /dev/lp0 lpt1

Network Shares

ln -s /mnt/smb/myserver/some unc/myserver/some

to make it available in Wine (don’t forget to create the

directory if it doesn’t already exist).


Font configuration, once a nasty problem, is now much simpler.
If you have a collection of TrueType fonts in Windows it’s
simply a matter of copying the .ttf files
into c:windows onts.


Wine can interact directly with the local CUPS printing system to
find the printers available on your system. Configuring
printers with Wine is as simple as making sure your CUPS
configuration works. Wine still needs the
lpr command (from CUPS), when printing a document.

If you do not use CUPS, the old BSD-Printing system is used:


The ODBC system within Wine, as with the printing system, is designed
to hook across to the Unix system at a high level. Rather than
ensuring that all the Windows code works under Wine it uses a suitable
Unix ODBC provider, such as unixODBC. Thus if you configure Wine to
use the built-in odbc32.dll,
that Wine DLL will interface to your
Unix ODBC package and let that do the work, whereas if you configure
Wine to use the native odbc32.dll
it will try to use the native ODBC32 drivers etc.

Configuring ODBC on Unix

The first step in using a Unix ODBC system with Wine is, of course,
to get the Unix ODBC system working itself. This may involve
downloading code or binary packages etc. There are several Unix ODBC systems
available such as unixODBC or an ODBC-ODBC bridge that can be used
to access a Microsoft Access database. Typically such systems will
include a tool, such as isql, which will allow
you to access the data from the command line so that you can check
that the system is working.

The next step is to hook the Unix ODBC library to the Wine built-in
odbc32 DLL. The built-in odbc32 (currently)
looks to the environment variable
LIB_ODBC_DRIVER_MANAGER for the name of the ODBC
library. For example:

If that environment variable is not set then it looks for a
library called and so
you can add a symbolic link to
equate that to your own library. For example as root you could
run the commands:

# ln -s /usr/lib/
# /sbin/ldconfig

The last step in configuring this is to ensure that Wine is set up
to run the built-in version of odbc32.dll,
by modifying the DLL
configuration. This built-in DLL merely acts as a stub between the
calling code and the Unix ODBC library.

If you have any problems then you can use
WINEDEBUG=+odbc32 command
before running Wine to trace what is happening. One word of
warning: some programs actually cheat a little and bypass the ODBC
library. For example the Crystal Reports engine goes to the registry
to check on the DSN. The fix for this is documented at unixODBC
site where there is a section on using unixODBC with Wine.

Using Windows ODBC drivers

Native ODBC drivers have been reported to work for many types of
databases including MSSQL and Oracle. In fact, some like MSSQL can
only be accessed on Linux through a Winelib app. Rather than
just copying DLL files, most ODBC drivers require a Windows-based
installer to run to properly configure things such as registry keys.

In order to set up MSSQL support you will first need to download
and run the mdac_typ.exe installer from . In order to
configure your ODBC connections you must then run CLICONFG.EXE
and ODBCAD32.EXE under Wine. You can find them in the
directory after mdac_typ runs. Compare the output of these programs
with the output on a native Windows machine. Some things, such
as protocols, may be missing because they rely on being installed
along with the operating system. If so, you may be able to copy
missing functionality from an existing Windows installation as
well as any registry values required. A native Windows installation
configured to be used by Wine should work the same way it did
when run natively.

Types successfully tested under Wine:

Please report any other successes to the
mailing list.

What to do if some program still doesn’t work?

Look at the output from wine —version to make sure you’re running
a recent version of Wine. Launch winecfg and look over the
settings to make sure you have settings that look normal. Look
in ~/.wine/dosdevices to make sure your
c: points to where you think it should.

Use different startup paths

Run with WINEDEBUG=+loaddll to figure out which
DLLs are being used, and whether they’re being loaded as native or built-in.
Then make sure you have proper native DLL files in your
configured C:windowssystem32 directory and
fiddle with DLL load order settings at command line or with winecfg.

Check your system environment!

Maybe your app is using some kind of copy protection?

Many copy protections currently don’t work on Wine.
Some might work in the future, though.
(the CD-ROM layer isn’t really full-featured yet).

Reconfigure Wine

Sometimes Wine installation process changes and new versions of
Wine account on these changes.
This is especially true if your setup was created long time ago.

Rename your existing ~/.wine directory
for backup purposes.
Use the setup process that’s recommended for your Wine distribution
to create new configuration.
Use information in old ~/.wine
directory as a reference. Later you can remove the new
~/.wine directory and rename your old one back.

Check out further information

A file which is in machine executable, compiled form: hex data (as opposed to a source code file).

A distribution is usually the way in which some ships operating system CDs
(usually mentioned in the context of Linux).
A Linux environment can be shipped in lots of different configurations: e.g. distributions could be built to be suitable for games, scientific
applications, server operation, desktop systems, etc.

A DLL (Dynamic Link Library) is a file that can be loaded and executed by programs dynamically. Basically it’s an external code repository for programs.
Since usually several different programs reuse the same DLL instead of having that code in their own file, this dramatically reduces required storage space.
A synonym for a DLL would be .

An editor is usually a program to create or modify text files.
There are various graphical and text mode editors available on

Examples of graphical editors are: nedit,
gedit, kedit,
xemacs, gxedit.

Examples of text mode editors are: joe,
ae, emacs, vim,
In a terminal, simply run them via:

$ editorname filename

Environment variables are text definitions used in a Shell to store important system settings.
In a bash shell (the most commonly used one in Linux),
you can view all environment variables by executing:

If you want to change an environment variable, you could run:

For deleting an environment variable, use:

Git is a fast version control system, originally written for use with
large repositories, such as the Linux Kernel source.
See the Git chapter in the Wine Developers Guide for detailed usage information.

A package is a compressed file in a
distribution specific format. It contains the
files for a particular program you want to install. Packages are
usually installed via the dpkg or
rpm package managers.

$ su -#

Source code is the code that a program consists of before the program
is being compiled, i.e. it’s the original building instructions of a
program that tell a compiler what the program should look like once
it’s been compiled to a Binary.

A terminal window is usually a graphical window that one uses to
execute a Shell. If Wine asks you to open a
terminal, then you usually need to click on an icon on your desktop
that usually shows a big black window.
Wine assumes you’re using the bash shell, so if your terminal happens to use
a different shell program, simply type bash in the terminal window.

Translations of this page:

Français ; Not all ported. Translators, please see Discussion page.

This FAQ, or Frequently Asked Questions, covers general topics about Wine. For questions related to Wine software development, see the Developer FAQ.

Дополнительно:  Root External 2 Internal SD APK + MOD v1.8

Quick links: running a program in Wine, running Wine from a terminal, running program as root, uninstalling an application, getting a debugging log, using a wineprefix, creating a 32 bit wineprefix.

General questions

Wine is available thanks to the work of many people around the world. Some companies that are or have been involved with Wine development are CodeWeavers, Bordeaux, TransGaming, Corel, Macadamian and Google. See Acknowledgements and Wine History.

Does Wine hurt Linux or other free operating systems?

There is a lot of confusion about this, particularly caused by people getting Wine’s name wrong and calling it WINdows Emulator.

That said, Wine can be thought of as a Windows emulator in much the same way that Windows Vista can be thought of as a Windows XP emulator: both allow you to run the same applications by translating system calls in much the same way. Setting Wine to mimic Windows XP is not much different from setting Vista to launch an application in XP compatibility mode.

A few things make Wine more than just an emulator:

«Wine is not just an emulator» is more accurate. Thinking of Wine as just an emulator is really forgetting about the other things it is. Wine’s «emulator» is really just a binary loader that allows Windows applications to interface with the Wine API replacement.

What is the difference between Wine, CrossOver, and Cedega?

Wine is the base of the project, where most of the work is being done. Wine is not perfect, but tens of thousands of people nevertheless use «vanilla» Wine successfully to run a large number of Windows programs.

CrossOver XI (formerly CrossOver Office) is a product made by a company called CodeWeavers that is based directly on Wine with a few tweaks and proprietary add-ons. Unlike the biweekly Wine releases, CrossOver releases are rigorously tested for compatibility with CodeWeavers’ supported applications in order to prevent «regressions». CodeWeavers employs a large proportion of the Wine developers and provides a great deal of leadership for the project. All improvements to Wine eventually work their way into CrossOver.

Cedega (formerly WineX) is a product from a company called TransGaming. TransGaming based their product on Wine back in 2002 when Wine had a different license, closed their source code, and rebranded their version as specialized for gamers. In the years since Cedega was originally created from Wine, development on Wine and Cedega have continued mostly independently. TransGaming currently gives back very little code to Wine. Cedega is not «Wine with more gaming support» — because Wine has had years of development since Cedega was made, and many games actually run better under Wine than under Cedega. Currently, Wine has more advanced Direct3D support than Cedega, but Cedega still has more advanced copy protection support due to TransGaming’s licensing of (closed source) code from a handful of copy protection companies. Unlike CrossOver, most improvements to Wine don’t get into Cedega due to the license differences between Cedega and Wine.

How does the Wine version numbering system work?

Normally you do not have to use the command line to use Wine in Linux. You can use a graphical interface for most things, much like on Windows. In many cases you can right-click an installer and select «Open with Wine», or just double-click it. You can start installed programs using the shortcut icon or menu.

However, there are several situations when you might need to use the command line. The most common reason is to get debug output when your program does not run properly. You might also want to use utilities such as regedit that do not have menu shortcuts (note that you can create them using whatever tools your DE provides).

This does not hold true for Mac OS X Wine usage, which is all command line currently, unless you use a third party application.

What applications run well with Wine?

You can contribute programming or documentation skills, or monetary or equipment donations, to aid the Wine developers in reaching their goals.

For a list of ideas of how you can help, please consult the Contribute section of the main page.

I think I’ve found a bug. How do I report this to WineHQ?

Bug reports should be submitted to our online Bugzilla system. To increase developer productivity and facilitate a resolution to submitted bugs, please read the Wiki article on Bugs. A poor bug report may be marked INVALID and closed, leaving you no closer to resolving your problem. High quality bug reports are an essential part of making Wine better.

Please note that you should generally avoid submitting bug reports if you have used any third party applications or native DLL overrides.

Where can I get further help?

Wine, along with the operating system you use to run it, generally requires less disk space and memory than Windows itself. If you’re not currently running a Windows application, Wine won’t consume any resources at all other than about 20 megabytes of disk space.

Ideally, if an application runs fine in Windows, it should run fine on the same hardware using Wine, provided native drivers for your hardware are installed and equivalent to the Windows drivers. Open source Linux graphics drivers in particular are often inadequate to run games that work fine on the same hardware in Windows. If there is no native driver for your hardware, Wine will not be able to use it.

Does Wine run on all Unix filesystems?

Until recently with projects such as Wayland, serious alternatives to x11drv weren’t even on the horizon so development has focused on X. However, Wine’s interface with the graphics driver is designed to be abstract so supporting future graphics systems will hopefully be straight-forward.

Which version of Wine should I use?

Short answer: Use the version that works best with the particular applications you want to run. In most cases, this will be the latest development version; however, in some cases it may take some experimenting to find it.

Longer answer: Wine development is rapid, with new releases in the development branch every two weeks or so. Functionality will usually be best with the most recent development version, however, there are cases where changes to existing code in Wine cause applications that worked well in older versions to not work in the new one (these are called regressions), as well as problems caused by the introduction of new, but as-yet-incomplete and untested, functions.

A good rule of thumb is to start with the version of Wine installed with your distro and see if that works with the applications you want to use. If it does, good! If it doesn’t, upgrade. In most cases the upgrade should be to the latest development version, but it is a good idea to check Bugzilla and the AppDB for any known regressions and/or new bugs. If you find an existing bug marked STAGED, this means there is a patch for the problem in wine-staging (the experimental branch), and you should try the latest version in that branch. If there are known bugs without a STAGED patch or easy workaround, upgrade to the most recent version of Wine known to work for your application.

How do I install Wine?

Yes, but you will have to build Wine yourself (see Building Wine), as it is not possible to have multiple distro packages installed. The easiest way to do this is to run Wine from the build directory (don’t do make install). If you want to actually install multiple versions, use —prefix when building Wine to designate a different install directory for each version, e.g.

./configure prefix=path_to_install_directory && make

then install it with

sudo make install

On Linux, you may need to set LD_LIBRARY_PATH, like so:

Note that regardless of whether you install multiple versions or run them from the build directory, you will still have to designate which version of Wine you wish to use when running applications. It is also recommended that applications being run with different Wine versions be installed into separate wineprefixes.

Is there a 64 bit Wine?

A few things to note:

Where can I find old Wine binary packages?

Old WineHQ binary packages are kept in their respective directories in the the WineHQ download server.

Consult your distro for information on obtaining old versions of distro Wine packages.

How do I install Wine on my netbook (eeePC, Acer Aspire One, etc

If you have replaced the customized distro that came preinstalled on your netbook (Xandros, Linpus, etc.) with one of the mainstream distros that provide up-to-date Wine packages, you should be able to install Wine as normal for that distro.

Installing on Apple

No, not even in Linux. Older Macs used PowerPC processors are incompatible with code compiled for x86 (Intel and AMD) processors, unless the code is run under CPU emulation. Wine Is Not a (CPU) Emulator, nor does it include one. The Darwine project was an effort to do just that, but it has not been maintained in many years.

See Building Wine.

How do I apply a patch?

You have to build Wine from source; see above.

How do I uninstall Wine?

rm -rf .wine

To rename it from the command line instead of deleting it:

mv ~/.wine ~/.wine-old

Alternatively, you can stop Wine from creating menu entries in the first place.

Installing and Running Windows Applications

Short answer: you have to install them in Wine just like you did in Windows. Applications usually have a setup or installer program.

Long answer: some applications can be copied from Windows to Wine and still work, but don’t try this unless you like tinkering under the hood of your car while it’s running.

Wine is not designed to interact with an existing Windows installation. If you have any data you need from a Windows installation, browse your Windows filesystems in your normal file manager and copy the data to another location.

Do not try to configure Wine to point to your actual Windows C: drive. This will break Windows and require a Windows reinstall. We have tried to make this hard to do, so you probably cannot do it by accident. If you do manage this, Wine may or may not continue to operate, but your Windows install will be 100% dead due to critical parts of it being overwritten. The only way to fix Windows after this has happened is to reinstall it.

How do I run an installer using Wine?

Use winetricks to install whatever version of .NET the program requires, cd to the directory containing the .application file, and run it with

wine start whatever.application

How do I launch native applications from a Windows application?

First, run regedit and add a dot character to the end of the list of extensions in HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession ManagerEnvironmentPATHEXT.

Note that this change will have to be made every time you upgrade Wine, as it will be reverted whenever the wineprefix is updated.

You can then start native applications using wine cmd if you specify the full path or use the shell, e.g.:

wine cmd /c /usr/bin/glxgears

wine cmd /c /bin/sh -c glxgears

You might also need winepath to translate the filename from Windows format to Linux format (see How do I associate a native program with a file type in Wine?).

My installer tells me I don’t have enough free disk space

Usually, you really don’t have enough free disk space. Wine’s C: drive is located in your home directory. Whatever partition contains /home must have enough free space for your program. You can check by running:

df -h ~

If the amount of space you need is less than 1 GB, and df reports you have more than 1 GB available, try setting the Windows version to Windows 98. This will work around bugs in some old (Windows 98 era) installers that could not cope with large drives.

If you want to use a different partition that has more free space, use a wineprefix that is located on the other partition. Note that your other partition must be a Unix filesystem: FAT and NTFS partitions will not work. See #How can I run two programs as if they were on different computers? for instructions.

When I double-click on a. exe file in my file manager, nothing happens

Note: if you can, start applications by clicking on the application’s icon in the Applications / Wine menu or desktop instead. Double-clicking .exe files is typically only needed for applications that aren’t installed yet, e.g. to run the setup.exe on a CD-ROM game or a downloaded installer.

If double-clicking doesn’t work, you might need to right-click the file and choose «Run with Wine». It depends on your file manager. If that also doesn’t work, contact whoever built your Wine packages and let them know there’s a problem.

If the dialog says «Read about the executable bit», with a hyperlink, try clicking on the hyperlink and reading about the executable bit.

If the file is on your hard drive, right-click it, choose Properties / Permissions, and check «Allow executing file as program».

If the file is on a CD-ROM, you can run it from the command line as described above. Or, if you know how to use mount, remount the cd-rom to mark all files as executable with a command like mount -o remount,mode=0777,exec /media/cdrom but using the real mount point if it’s different from /media/cdrom.

Оцените статью
Master Hi-technology
Добавить комментарий