WINEDEBUG=channelsWine 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 are: trace, fixme, warn, err.
To turn on a debug channel, use the form
class+channel.
To turn it off, use
class-channel.
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 DebugChannels. More channels will be added to (or subtracted from) later versions.
For more details about debug channels, check out the The Wine Developer's Guide.
WINEDLLOVERRIDES=DLL Overrides 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.
Examples:
$ 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:\foo\bar\baz.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.
For more information about DLL overrides, please refer to the DLL overrides section of this guide.
WINEARCH 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.
If you are using the OSS audio driver and you have multiple devices, (i.e. /dev/dsp*, /dev/mixer*) you can specify which one you want to use with the following environment variables:
AUDIODEV=audio device
MIXERDEV=mixer device
MIDIDEV=MIDI device
As an example:
$ AUDIODEV=/dev/dsp4 MIXERDEV=/dev/mixer1 MIDIDEV=/dev/midi3 wine program_name
