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
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
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
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
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
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.
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 dll 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 libraries comdlg32 and shell32 as native windows dlls. Furthermore, if an application request 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.
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:
As an example:
$ AUDIODEV=/dev/dsp4 MIXERDEV=/dev/mixer1 MIDIDEV=/dev/midi3 wine program_name