| <chapter id="running"> | |
| <title>Running Wine</title> | |
| <para> | |
| This chapter will describe all aspects of running Wine, like e.g. | |
| basic Wine invocation, command line parameters of various Wine | |
| support programs etc. | |
| </para> | |
| <sect1 id="basic-usage"> | |
| <title>Basic usage: applications and control panel applets</title> | |
| <para> | |
| Assuming you are using a fake Windows installation, you install | |
| applications into Wine in 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. | |
| </para> | |
| <para> | |
| 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 <command>uninstaller</command> | |
| program (it is located in the | |
| <filename>programs/uninstaller/</filename> directory in a Wine | |
| source directory) in a <glossterm>terminal</glossterm>: | |
| </para> | |
| <screen> | |
| <prompt>$</prompt> <userinput>uninstaller</userinput> | |
| </screen> | |
| <para> | |
| 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 | |
| <glossterm>terminal</glossterm>: | |
| </para> | |
| <screen> | |
| <prompt>$</prompt> <userinput>wine control</userinput> | |
| </screen> | |
| <para> | |
| which will open a window with the installed control panel | |
| applets in it, as in Windows. | |
| </para> | |
| <para> | |
| 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: | |
| </para> | |
| <screen> | |
| <prompt>$</prompt> <userinput>wine "c:\program files\appname\appname.exe"</userinput> | |
| </screen> | |
| <para> | |
| 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 EXE files, | |
| so you might have to look inside the program files directory to | |
| see what was put where. | |
| </para> | |
| </sect1> | |
| <sect1 id="running-wine"> | |
| <title>How to run Wine</title> | |
| <para> | |
| You can simply invoke the <command>wine</command> command to | |
| get a small help message: | |
| </para> | |
| <para> | |
| <screen> | |
| Wine 20040405 | |
| Usage: wine PROGRAM [ARGUMENTS...] Run the specified program | |
| wine --help Display this help and exit | |
| wine --version Output version information and exit | |
| </screen> | |
| </para> | |
| <para> | |
| The first argument should be the name of the file you | |
| want <command>wine</command> to execute. If the executable is | |
| in the <parameter>Path</parameter> environment variable, you can | |
| simply give the executable file name. However, if the executable | |
| is not in <parameter>Path</parameter>, you must give the full path to | |
| the executable (in Windows format, not UNIX format!). For | |
| example, given a <parameter>Path</parameter> of the following: | |
| </para> | |
| <screen> | |
| Path="c:\windows;c:\windows\system;e:\;e:\test;f:\" | |
| </screen> | |
| <para> | |
| You could run the file | |
| <filename>c:\windows\system\foo.exe</filename> with: | |
| </para> | |
| <screen> | |
| <prompt>$</prompt> <userinput>wine foo.exe</userinput> | |
| </screen> | |
| <para> | |
| However, you would have to run the file | |
| <filename>c:\myapps\foo.exe</filename> with this command: | |
| </para> | |
| <screen> | |
| <prompt>$</prompt> <userinput>wine c:\\myapps\\foo.exe</userinput> | |
| </screen> | |
| <para> | |
| (note the backslash-escaped "\" !) | |
| </para> | |
| <para> | |
| For details on running text mode (CUI) executables, read the | |
| <link linkend="CUI-programs">section</link> below. | |
| </para> | |
| </sect1> | |
| <sect1 id="explorer-like-wine"> | |
| <title>Explorer-like graphical Wine environments</title> | |
| <para> | |
| 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, many functions are not yet implemented. | |
| </para> | |
| </sect1> | |
| <sect1 id="command-line-options"> | |
| <title>Wine Command Line Options</title> | |
| <sect2> | |
| <title>--help</title> | |
| <para> | |
| Shows a small command line help page. | |
| </para> | |
| </sect2> | |
| <sect2> | |
| <title>--version</title> | |
| <para> | |
| Shows the Wine version string. Useful to verify your installation. | |
| </para> | |
| </sect2> | |
| </sect1> | |
| <sect1> | |
| <title>Environment variables</title> | |
| <sect2> | |
| <title>WINEDEBUG=[channels]</title> | |
| <para> | |
| 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 <firstterm>debug | |
| channels</firstterm> that you can tap into. | |
| </para> | |
| <para> | |
| Each debug channel, when activated, will trigger logging | |
| messages to be displayed to the console where you invoked | |
| <command>wine</command>. 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 <parameter>relay</parameter> which spits out a log | |
| message every time a win32 function is called, | |
| <parameter>win</parameter> which tracks windows message | |
| passing, and of course <parameter>all</parameter> 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 <parameter>relay</parameter> trace can often | |
| generate more than 10 MB of log messages, depending on how | |
| long you run the application. (As described in the | |
| <link linkend = "config-debug-etc">Debug</link> | |
| section of configuring wine you can | |
| modify what the <parameter>relay</parameter> trace reports). | |
| Logging does slow down Wine | |
| quite a bit, so don't use <parameter>WINEDEBUG</parameter> | |
| unless you really do want log files. | |
| </para> | |
| <para> | |
| Within each debug channel, you can further specify a | |
| <firstterm>message class</firstterm>, to filter out the | |
| different severities of errors. The four message classes | |
| are: | |
| <simplelist type="inline"> | |
| <member><parameter>trace</parameter></member> | |
| <member><parameter>fixme</parameter></member> | |
| <member><parameter>warn</parameter></member> | |
| <member><parameter>err</parameter></member> | |
| </simplelist>. | |
| </para> | |
| <para> | |
| To turn on a debug channel, use the form | |
| <parameter>class+channel</parameter>. To turn it off, use | |
| <parameter>class-channel</parameter>. To list more than one | |
| channel in the same <parameter>WINEDEBUG</parameter> | |
| option, separate them with commas. For example, to request | |
| <parameter>warn</parameter> class messages in the | |
| <parameter>heap</parameter> debug channel, you could invoke | |
| <command>wine</command> like this: | |
| </para> | |
| <screen> | |
| <prompt>$</prompt> <userinput>WINEDEBUG=warn+heap wine <replaceable>program_name</replaceable></userinput> | |
| </screen> | |
| <para> | |
| If you leave off the message class, <command>wine</command> | |
| will display messages from all four classes for that channel: | |
| </para> | |
| <screen> | |
| <prompt>$</prompt> <userinput>WINEDEBUG=heap wine <replaceable>program_name</replaceable></userinput> | |
| </screen> | |
| <para> | |
| If you wanted to see log messages for everything except the | |
| relay channel, you might do something like this: | |
| </para> | |
| <screen> | |
| <prompt>$</prompt> <userinput>WINEDEBUG=+all,-relay wine <replaceable>program_name</replaceable></userinput> | |
| </screen> | |
| <para> | |
| Here is a list of the debug channels and classes in Wine. | |
| More channels will be added to (or subtracted from) later | |
| versions. | |
| </para> | |
| <table frame="none"><title>Debug Channels</title> | |
| <tgroup cols=5 align="left"> | |
| <tbody> | |
| <row> <entry>accel</entry> <entry>adpcm</entry> <entry>advapi</entry> <entry>animate</entry> <entry>aspi</entry> </row> | |
| <row> <entry>atom</entry> <entry>avicap</entry> <entry>avifile</entry> <entry>bidi</entry> <entry>bitblt</entry> </row> | |
| <row> <entry>bitmap</entry> <entry>cabinet</entry> <entry>capi</entry> <entry>caret</entry> <entry>cdrom</entry> </row> | |
| <row> <entry>cfgmgr32</entry> <entry>class</entry> <entry>clipboard</entry> <entry>clipping</entry> <entry>combo</entry> </row> | |
| <row> <entry>comboex</entry> <entry>comm</entry> <entry>commctrl</entry> <entry>commdlg</entry> <entry>computername</entry> </row> | |
| <row> <entry>console</entry> <entry>crtdll</entry> <entry>crypt</entry> <entry>curses</entry> <entry>cursor</entry> </row> | |
| <row> <entry>d3d</entry> <entry>d3d_shader</entry> <entry>d3d_surface</entry> <entry>datetime</entry> <entry>dc</entry> </row> | |
| <row> <entry>ddeml</entry> <entry>ddraw</entry> <entry>ddraw_fps</entry> <entry>ddraw_geom</entry> <entry>ddraw_tex</entry> </row> | |
| <row> <entry>debugstr</entry> <entry>devenum</entry> <entry>dialog</entry> <entry>dinput</entry> <entry>dll</entry> </row> | |
| <row> <entry>dma</entry> <entry>dmband</entry> <entry>dmcompos</entry> <entry>dmfile</entry> <entry>dmfiledat</entry> </row> | |
| <row> <entry>dmime</entry> <entry>dmloader</entry> <entry>dmscript</entry> <entry>dmstyle</entry> <entry>dmsynth</entry> </row> | |
| <row> <entry>dmusic</entry> <entry>dosfs</entry> <entry>dosmem</entry> <entry>dplay</entry> <entry>dplayx</entry> </row> | |
| <row> <entry>dpnhpast</entry> <entry>driver</entry> <entry>dsound</entry> <entry>dsound3d</entry> <entry>edit</entry> </row> | |
| <row> <entry>enhmetafile</entry> <entry>environ</entry> <entry>event</entry> <entry>eventlog</entry> <entry>exec</entry> </row> | |
| <row> <entry>file</entry> <entry>fixup</entry> <entry>font</entry> <entry>fps</entry> <entry>g711</entry> </row> | |
| <row> <entry>gdi</entry> <entry>global</entry> <entry>glu</entry> <entry>graphics</entry> <entry>header</entry> </row> | |
| <row> <entry>heap</entry> <entry>hook</entry> <entry>hotkey</entry> <entry>icmp</entry> <entry>icon</entry> </row> | |
| <row> <entry>imagehlp</entry> <entry>imagelist</entry> <entry>imm</entry> <entry>int</entry> <entry>int21</entry> </row> | |
| <row> <entry>int31</entry> <entry>io</entry> <entry>ipaddress</entry> <entry>iphlpapi</entry> <entry>jack</entry> </row> | |
| <row> <entry>joystick</entry> <entry>key</entry> <entry>keyboard</entry> <entry>listbox</entry> <entry>listview</entry> </row> | |
| <row> <entry>loaddll</entry> <entry>local</entry> <entry>mapi</entry> <entry>mci</entry> <entry>mcianim</entry> </row> | |
| <row> <entry>mciavi</entry> <entry>mcicda</entry> <entry>mcimidi</entry> <entry>mciwave</entry> <entry>mdi</entry> </row> | |
| <row> <entry>menu</entry> <entry>menubuilder</entry> <entry>message</entry> <entry>metafile</entry> <entry>midi</entry> </row> | |
| <row> <entry>mmaux</entry> <entry>mmio</entry> <entry>mmsys</entry> <entry>mmtime</entry> <entry>module</entry> </row> | |
| <row> <entry>monthcal</entry> <entry>mpeg3</entry> <entry>mpr</entry> <entry>msacm</entry> <entry>msdmo</entry> </row> | |
| <row> <entry>msg</entry> <entry>mshtml</entry> <entry>msi</entry> <entry>msimg32</entry> <entry>msisys</entry> </row> | |
| <row> <entry>msrle32</entry> <entry>msvcrt</entry> <entry>msvideo</entry> <entry>mswsock</entry> <entry>nativefont</entry> </row> | |
| <row> <entry>netapi32</entry> <entry>netbios</entry> <entry>nls</entry> <entry>nonclient</entry> <entry>ntdll</entry> </row> | |
| <row> <entry>odbc</entry> <entry>ole</entry> <entry>oledlg</entry> <entry>olerelay</entry> <entry>opengl</entry> </row> | |
| <row> <entry>pager</entry> <entry>palette</entry> <entry>pidl</entry> <entry>powermgnt</entry> <entry>print</entry> </row> | |
| <row> <entry>process</entry> <entry>profile</entry> <entry>progress</entry> <entry>propsheet</entry> <entry>psapi</entry> </row> | |
| <row> <entry>psdrv</entry> <entry>qcap</entry> <entry>quartz</entry> <entry>ras</entry> <entry>rebar</entry> </row> | |
| <row> <entry>reg</entry> <entry>region</entry> <entry>relay</entry> <entry>resource</entry> <entry>richedit</entry> </row> | |
| <row> <entry>rundll32</entry> <entry>sblaster</entry> <entry>scroll</entry> <entry>seh</entry> <entry>selector</entry> </row> | |
| <row> <entry>server</entry> <entry>setupapi</entry> <entry>shdocvw</entry> <entry>shell</entry> <entry>shlctrl</entry> </row> | |
| <row> <entry>snmpapi</entry> <entry>snoop</entry> <entry>sound</entry> <entry>static</entry> <entry>statusbar</entry> </row> | |
| <row> <entry>storage</entry> <entry>stress</entry> <entry>string</entry> <entry>syscolor</entry> <entry>system</entry> </row> | |
| <row> <entry>tab</entry> <entry>tape</entry> <entry>tapi</entry> <entry>task</entry> <entry>text</entry> </row> | |
| <row> <entry>thread</entry> <entry>thunk</entry> <entry>tid</entry> <entry>timer</entry> <entry>toolbar</entry> </row> | |
| <row> <entry>toolhelp</entry> <entry>tooltips</entry> <entry>trackbar</entry> <entry>treeview</entry> <entry>ttydrv</entry> </row> | |
| <row> <entry>twain</entry> <entry>typelib</entry> <entry>uninstaller</entry> <entry>updown</entry> <entry>urlmon</entry> </row> | |
| <row> <entry>uxtheme</entry> <entry>ver</entry> <entry>virtual</entry> <entry>vxd</entry> <entry>wave</entry> </row> | |
| <row> <entry>wc_font</entry> <entry>win</entry> <entry>win32</entry> <entry>wineboot</entry> <entry>winecfg</entry> </row> | |
| <row> <entry>wineconsole</entry> <entry>wine_d3d</entry> <entry>winevdm</entry> <entry>wing</entry> <entry>winhelp</entry> </row> | |
| <row> <entry>wininet</entry> <entry>winmm</entry> <entry>winsock</entry> <entry>winspool</entry> <entry>wintab</entry> </row> | |
| <row> <entry>wintab32</entry> <entry>wnet</entry> <entry>x11drv</entry> <entry>x11settings</entry> <entry>xdnd</entry> </row> | |
| <row> <entry>xrandr</entry> <entry>xrender</entry> <entry>xvidmode</entry> </row> | |
| </tbody> | |
| </tgroup> | |
| </table> | |
| <para> | |
| For more details about debug channels, check out the | |
| <ulink url="http://wine.codeweavers.com/docs/wine-devel/"> | |
| The Wine Developer's Guide</ulink>. | |
| </para> | |
| </sect2> | |
| </sect1> | |
| <sect1 id="wineserver-command-line-options"> | |
| <title>wineserver Command Line Options</title> | |
| <para> | |
| wineserver usually gets started automatically by Wine whenever | |
| the first wine process gets started. | |
| However, wineserver has some useful command line options that | |
| you can add if you start it up manually, e.g. via a user login | |
| script or so. | |
| </para> | |
| <sect2 id="wineserver-config-parameter"> | |
| <title>-d<n></title> | |
| <para> | |
| Sets the debug level for debug output in the terminal that | |
| wineserver got started in at level <n>. | |
| In other words: everything greater than 0 will enable | |
| wineserver specific debugging output. | |
| </para> | |
| </sect2> | |
| <sect2> | |
| <title>-h</title> | |
| <para> | |
| Display wineserver command line options help message. | |
| </para> | |
| </sect2> | |
| <sect2> | |
| <title>-k[n]</title> | |
| <para> | |
| Kill the current wineserver, optionally with signal n. | |
| </para> | |
| </sect2> | |
| <sect2> | |
| <title>-p[n]</title> | |
| <para> | |
| This parameter makes wineserver persistent, optionally for n | |
| seconds. It will prevent wineserver from shutting down immediately. | |
| </para> | |
| <para> | |
| 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. | |
| </para> | |
| </sect2> | |
| <sect2> | |
| <title>-w</title> | |
| <para> | |
| This parameter makes a newly started wineserver wait until the | |
| currently active wineserver instance terminates. | |
| </para> | |
| </sect2> | |
| </sect1> | |
| <sect1 id="environment-variables"> | |
| <title>Setting Windows/DOS environment variables</title> | |
| <para> | |
| 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 | |
| !): | |
| <screen> | |
| export MYENVIRONMENTVAR=myenvironmentvarsetting | |
| </screen> | |
| 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 /etc/profile, or also ~/.bashrc in the case of | |
| bash. | |
| </para> | |
| <para>Note however that there are some exceptions to the rule: | |
| If you want to change the PATH, SYSTEM or TEMP variables, the 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 <userinput>wine regedit</userinput> and then go to the | |
| <screen>HKEY_CURRENT_USER/Environment</screen> key. Now you can create | |
| or modify the values of the variables you need | |
| </para> | |
| <para> | |
| <programlisting>"System" = "c:\\windows\\system"</programlisting> | |
| This sets up where the windows system files are. The Windows | |
| system directory should reside below the directory used for the | |
| <literal>Windows</literal> setting. | |
| Thus when using /usr/local/wine_c_windows as Windows path, | |
| the system directory would be | |
| <filename>/usr/local/wine_c/windows/system</filename>. | |
| It must be set with no trailing slash, and you must be sure that | |
| you have write access to it. | |
| </para> | |
| <para> | |
| <programlisting>"Temp" = "c:\\temp"</programlisting> This should | |
| be the directory you want your temp files stored in, | |
| /usr/local/wine_c/temp in our previous example. | |
| Again, no trailing slash, and <emphasis>write | |
| access</emphasis>!! | |
| </para> | |
| <para> | |
| <programlisting>"Path" = "c:\\windows;c:\\windows\\system;c:\\blanco"</programlisting> | |
| Behaves like the <envar>PATH</envar> setting on UNIX | |
| boxes. When wine is run like <userinput>wine | |
| sol.exe</userinput>, if <filename>sol.exe</filename> | |
| resides in a directory specified in the | |
| <literal>Path</literal> setting, wine will run it (Of | |
| course, if <filename>sol.exe</filename> resides in the | |
| current directory, wine will run that one). Make sure it | |
| always has your <filename>windows</filename> directory and | |
| system directory (For this setup, it must have | |
| <filename>"c:\\windows;c:\\windows\\system"</filename>). | |
| </para> | |
| </sect1> | |
| <sect1 id="CUI-programs"> | |
| <title>Text mode programs (CUI: Console User Interface)</title> | |
| <para>Text mode programs are program which output is only made | |
| out of text (surprise!). In Windows terminology, they are | |
| called CUI (Console User Interface) executables, by opposition | |
| to GUI (Graphical User Interface) executables. Win32 API | |
| provide a complete set of APIs to handle this situation, which | |
| goes from basic features like text printing, up to high level | |
| functionalities (like full screen editing, color support, | |
| cursor motion, mouse support), going through features like | |
| line editing or raw/cooked input stream support | |
| </para> | |
| <para> | |
| 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): | |
| <itemizedlist> | |
| <listitem> | |
| <para> | |
| bare streams | |
| </para> | |
| </listitem> | |
| <listitem> | |
| <para> | |
| wineconsole with user backend | |
| </para> | |
| </listitem> | |
| <listitem> | |
| <para> | |
| wineconsole with curses backend | |
| </para> | |
| </listitem> | |
| </itemizedlist> | |
| </para> | |
| <para>The names here are a bit obscure. "bare streams" means | |
| that no extra support of wine is provide to map between the | |
| unix console access and Windows console access. The two other | |
| ways require the use of a specific Wine program (wineconsole) | |
| which provide extended facilities. The following table | |
| describes what you can do (and cannot do) with those three | |
| ways. | |
| <table> | |
| <title>Basic differences in consoles</title> | |
| <tgroup cols="4" align="left"> | |
| <thead> | |
| <row> | |
| <entry>Function</entry> | |
| <entry>Bare streams</entry> | |
| <entry>Wineconsole & user backend</entry> | |
| <entry>Wineconsole & curses backend</entry> | |
| </row> | |
| </thead> | |
| <tbody> | |
| <row> | |
| <entry>How to run (assuming executable is called foo.exe)</entry> | |
| <entry><msgtext> | |
| <screen><prompt>$</prompt> <userinput>wine foo.exe</userinput></screen> | |
| </msgtext></entry> | |
| <entry><msgtext> | |
| <screen><prompt>$</prompt> <userinput>wineconsole -- --backend=user foo.exe</userinput></screen> | |
| </msgtext></entry> | |
| <entry><msgtext> | |
| <screen><prompt>$</prompt> <userinput>wineconsole foo.exe</userinput></screen> | |
| </msgtext>You can also use --backend=curses as an option</entry> | |
| </row> | |
| <row> | |
| <entry>Good support for line oriented CUI applications | |
| (which print information line after line) | |
| </entry> | |
| <entry>Yes</entry> | |
| <entry>Yes</entry> | |
| <entry>Yes</entry> | |
| </row> | |
| <row> | |
| <entry>Good support for full screen CUI | |
| applications (including but not limited to color | |
| support, mouse support...)</entry> | |
| <entry>No</entry> | |
| <entry>Yes</entry> | |
| <entry>Yes</entry> | |
| </row> | |
| <row> | |
| <entry>Can be run even if X11 is not running</entry> | |
| <entry>Yes</entry> | |
| <entry>No</entry> | |
| <entry>Yes</entry> | |
| </row> | |
| <row> | |
| <entry>Implementation</entry> | |
| <entry>Maps the standard Windows streams to the | |
| standard Unix streams (stdin/stdout/stderr) | |
| </entry> | |
| <entry> | |
| Wineconsole will create a new Window (hence | |
| requiring the USER32 DLL is available) where all | |
| information will be displayed | |
| </entry> | |
| <entry> | |
| Wineconsole will use existing unix console | |
| (from which the program is run) and with the help of | |
| the (n)curses library take control of all the terminal | |
| surface for interacting with the user | |
| </entry> | |
| </row> | |
| <row> | |
| <entry>Known limitations</entry> | |
| <entry></entry> | |
| <entry></entry> | |
| <entry> | |
| Will produce strange behavior if two (or more) | |
| Windows consoles are used on the same Un*x terminal. | |
| </entry> | |
| </row> | |
| </tbody> | |
| </tgroup> | |
| </table> | |
| </para> | |
| <sect2 id="CUI-programs-config"> | |
| <title>Configuration of CUI executables</title> | |
| <para> | |
| When wineconsole is used, several configuration options are | |
| available. Wine (as Windows do) stores, on a per application | |
| basis, several options in the registry. This let a user, for | |
| example, define the default screen-buffer size he would like | |
| to have for a given application. | |
| </para> | |
| <para> | |
| As of today, only the USER backend allows you to edit those | |
| options (we don't recommend editing by hand the registry | |
| contents). This edition is fired when a user right click in | |
| the console (this popups a menu), where you can either | |
| choose from: | |
| <itemizedlist> | |
| <listitem> | |
| <para> | |
| Default: this will edit the settings shared by all | |
| applications which haven't been configured yet. So, | |
| when an application is first run (on your machine, | |
| under your account) in wineconsole, wineconsole will | |
| inherit this default settings for the | |
| application. Afterwards, the application will have its | |
| own settings, that you'll be able to modify at your will. | |
| </para> | |
| <para> | |
| Properties: this will edit the application's | |
| settings. When you're done, with the edition, you'll | |
| be prompted whether you want to: | |
| <orderedlist> | |
| <listitem> | |
| <para> | |
| Keep these modified settings only for this | |
| session (next time you run the application, you | |
| will not see the modification you've just made). | |
| </para> | |
| </listitem> | |
| <listitem> | |
| <para> | |
| Use the settings for this session and save them | |
| as well, so that next you run your application, | |
| you'll use these new settings again. | |
| </para> | |
| </listitem> | |
| </orderedlist> | |
| </para> | |
| </listitem> | |
| </itemizedlist> | |
| </para> | |
| <para> | |
| Here's the list of the items you can configure, and their | |
| meanings: | |
| <table> | |
| <title>Wineconsole configuration options</title> | |
| <tgroup cols="2" align="left"> | |
| <thead> | |
| <row> | |
| <entry>Configuration option</entry> | |
| <entry>Meaning</entry> | |
| </row> | |
| </thead> | |
| <tbody> | |
| <row> | |
| <entry>Cursor's size</entry> | |
| <entry> | |
| Defines the size of the cursor. Three options are | |
| available: small (33% of character height), medium | |
| (66%) and large (100%) | |
| </entry> | |
| </row> | |
| <row> | |
| <entry>Popup menu</entry> | |
| <entry> | |
| It's been said earlier that wineconsole | |
| configuration popup was triggered using a right | |
| click in the console's window. However, this can | |
| be an issue when the application you run inside | |
| wineconsole expects the right click events to be | |
| sent to it. By ticking control or shift you select | |
| additional modifiers on the right click for | |
| opening the popup. For example, ticking shift will | |
| send events to the application when you right | |
| click the window without shift being hold down, | |
| and open the window when you right-click while | |
| shift being hold down. | |
| </entry> | |
| </row> | |
| <row> | |
| <entry>Quick edit</entry> | |
| <entry> | |
| This tick box lets you decide whether left-click | |
| mouse events shall be interpreted as events to be | |
| sent to the underlying application (tick off) or | |
| as a selection of rectangular part of the screen | |
| to be later on copied onto the clipboard (tick on). | |
| </entry> | |
| </row> | |
| <row> | |
| <entry>History</entry> | |
| <entry> | |
| This lets you pick up how many commands you want | |
| the console to recall. You can also drive whether | |
| you want, when entering several times the same | |
| command - potentially intertwined with others - | |
| whether you want to store all of them (tick off) | |
| or only the last one (tick on). | |
| </entry> | |
| </row> | |
| <row> | |
| <entry>Police</entry> | |
| <entry> | |
| The Police property sheet allows you to pick the | |
| default font for the console (font file, size, | |
| background and foreground color). | |
| </entry> | |
| </row> | |
| <row> | |
| <entry>Screenbuffer & window size</entry> | |
| <entry> | |
| The console as you see it is made of two different | |
| parts. On one hand there's the screenbuffer which | |
| contains all the information your application puts | |
| on the screen, and the window which displays a | |
| given area of this screen buffer. Note that the | |
| window is always smaller or of the same size than | |
| the screen buffer. Having a strictly smaller window | |
| size will put on scrollbars on the window so that | |
| you can see the whole screenbuffer's content. | |
| </entry> | |
| </row> | |
| <row> | |
| <entry>Close on exit</entry> | |
| <entry> | |
| If it's ticked, then the wineconsole will exit | |
| when the application within terminates. Otherwise, | |
| it'll remain opened until the user manually closes | |
| it: this allows seeing the latest information of a | |
| program after it has terminated. | |
| </entry> | |
| </row> | |
| <row> | |
| <entry>Edition mode</entry> | |
| <entry> | |
| <msgtext> | |
| <para> | |
| When the user enter commands, he or she can | |
| choose between several edition modes: | |
| <itemizedlist> | |
| <listitem> | |
| <para> | |
| Emacs: the same keybindings as under | |
| emacs are available. For example, Ctrl-A | |
| will bring the cursor to the beginning | |
| of the edition line. See your emacs | |
| manual for the details of the commands. | |
| </para> | |
| </listitem> | |
| <listitem> | |
| <para> | |
| Win32: these are the standard Windows | |
| console key-bindings (mainly using | |
| arrows). | |
| </para> | |
| </listitem> | |
| </itemizedlist> | |
| </para> | |
| </msgtext> | |
| </entry> | |
| </row> | |
| </tbody> | |
| </tgroup> | |
| </table> | |
| </para> | |
| </sect2> | |
| </sect1> | |
| </chapter> | |
| <!-- Keep this comment at the end of the file | |
| Local variables: | |
| mode: sgml | |
| sgml-parent-document:("wine-user.sgml" "set" "book" "chapter" "") | |
| End: | |
| --> |