Written by &name-john-sheets; &email-john-sheets; Wine is a very complicated piece of software with many ways to adjust how it runs. With very few exceptions, you can activate the same set of features through the configuration file as you can with command-line parameters. In this chapter, we'll briefly discuss these parameters, and match them up with their corresponding configuration variables. You can invoke the wine --help command to get a listing of all Wine's command-line parameters: Usage: ./wine [options] program_name [arguments] Options: --config name Specify config file to use --debugmsg name Turn debugging-messages on or off --desktop geom Use a desktop window of the given geometry --display name Use the specified display --dll name Enable or disable built-in DLLs --dosver x.xx DOS version to imitate (e.g. 6.22) Only valid with --winver win31 --help,-h Show this help message --language xx Set the language (one of Br,Ca,Cs,Cy,Da,De,En,Eo,Es,Fi,Fr,Ga,Gd,Gv, Hr,Hu,It,Ja,Ko,Kw,Nl,No,Pl,Pt,Sk,Sv,Ru,Wa) --managed Allow the window manager to manage created windows --synchronous Turn on synchronous display mode --version,-v Display the Wine version --winver Version to imitate (win95,nt40,win31,nt2k,win98,nt351,win30,win20) You can specify as many options as you want, if any. Typically, you will want to have your configuration file set up with a sensible set of defaults; in this case, you can run wine without explicitly listing any options. In rare cases, you might want to override certain parameters on the command line. If you find yourself using the same long set of command options with certain applications, you might find it easier to work with multiple config files, using the --config parameter to specify a non-default configuration. After the options, you should put the name of the file you want wine to execute. If the executable is in the Path parameter in the configuration file, you can simply give the executable file name. However, if the executable is not in Path, you must give the full path to the executable (in Windows format, not UNIX format!). For example, given a Path of the following: [wine] "Path"="c:\windows;c:\windows\system;e:\;e:\test;f:\" You could run the file c:\windows\system\foo.exe with: $ wine foo.exe However, you would have to run the file c:\myapps\foo.exe with this command: $ wine c:\myapps\foo.exe Finally, if you want to pass any parameters to your windows application, you can list them at the end, just after the executable name. Thus, to run the imaginary foo.exe Windows application with its /advanced mode parameter, while invoking Wine in --managed mode, you would do something like this: $ wine --managed foo.exe /advanced In other words, options that affect Wine should come before the Windows program name, while options that affect the Windows program should come after it. The --config parameter allows you to specify which configuration file you want to use for the current invocation of wine. For example, if you like to run a specific application or set of applications with a different array of options than your normal defaults, you might set up a different config file for them, and use the --config option to make use of it. The default value of --config is ~/.winerc. This value is hardwired into the Wine source code. In future versions of Wine, the default may change to ~/.wine/conf. Wine isn't perfect, and many Windows applications still don't run without bugs under Wine (but then, many of them 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. Logging does slow down Wine quite a bit, so don't use --debugmsg 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 --debugmsg option, separate them with commas. For example, to request warn class messages in the heap debug channel, you could invoke wine like this: $ wine --debugmsg warn+heap program_name If you leave off the message class, wine will display messages from all four classes for that channel: $ wine --debugmsg +heap program_name If you wanted to see log messages for everything except the relay channel, you might do something like this: $ wine --debugmsg +all,-relay program_name Here is a master list of all the debug channels and classes in Wine. More channels might be added to (or subtracted from) later versions. all accel advapi animate aspi atom avifile bitblt bitmap caret cdrom class clipboard clipping combo comboex comm commctrl commdlg console crtdll cursor datetime dc ddeml ddraw debug debugstr delayhlp dialog dinput dll dosfs dosmem dplay driver dsound edit elfdll enhmetafile event exec file fixup font gdi global graphics header heap hook hotkey icmp icon imagehlp imagelist imm int int10 int16 int17 int19 int21 int31 io ipaddress joystick key keyboard ldt listbox listview local mci mcianim mciavi mcicda mcimidi mciwave mdi menu message metafile midi mmaux mmio mmsys mmtime module monthcal mpr msacm msg msvideo nativefont nonclient ntdll odbc ole opengl pager palette pidl print process profile progress prop propsheet psapi psdrv ras rebar reg region relay resource richedit scroll segment seh selector sendmsg server setupapi setupx shell snoop sound static statusbar storage stress string syscolor system tab tape tapi task text thread thunk timer toolbar toolhelp tooltips trackbar treeview ttydrv tweak typelib updown ver virtual vxd wave win win16drv win32 wing wininet winsock winspool wnet x11 x11drv For more details about debug channels, check out the The Wine Developer's Guide. By default, wine runs applications on your regular desktop. Wine application windows intermingle with native X11 applications. Windows overlap each other, and you can resize them in relation to each other. Normally, when you minimize Wine windows, they collapse into a small icon at the lower left corner of your desktop, circumventing the behavior of your other non-Wine windows. However, if you're running in --managed mode, your Wine applications will minimize just like your other windows. Sometimes, you may want to restrict Wine windows to a smaller area of your desktop. This is what the --desktop option controls. Whenever you pass this option to wine, it will create a window of that size and use that as Wine's desktop instead of borrowing the regular desktop space. Wine will then place the application window inside the new desktop window. If you minimize the application, it will iconize to the bottom left corner of its own desktop window. The --desktop option geometry info in the standard X11 geometry format, e.g., "640x480" for a desktop window 640 pixels wide and 480 pixels high. You can also in theory specify the coordinates of the upper left corner of the desktop window, but your window manager may choose to override that request. The following invocation would open a new 640 x 480 desktop window at coordinates (10, 25): $ wine --desktop 640x480+10+25 foo.exe More commonly, you'll leave off the starting coordinates, and only use the height and width: $ wine --desktop 640x480 foo.exe By default, wine will display its windows on whichever X Display you have in the $DISPLAY environment variable. Often, $DISPLAY is set to :0, which sends all windows to the primary video monitor on the current host machine. To send windows to a different monitor on the same system, you could change :0 to a different number, for example :1 to send output to the second monitor. You can also specify other systems. If you were logged into the system alpha, but wanted wine to run on another system on the network, beta, you might use a $DISPLAY of beta:0. You can also declare display values on the wine command line, using the --display option. The last example above might look like this: $ wine --display="beta:0" foo.exe