blob: 78bd386a467cb9ba118f40d29f4beb438067d6aa [file] [log] [blame]
<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&lt;n&gt;</title>
<para>
Sets the debug level for debug output in the terminal that
wineserver got started in at level &lt;n&gt;.
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 &amp; user backend</entry>
<entry>Wineconsole &amp; 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 &amp; 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:
-->