<sect1 id="config">
<title>Runtime Configuration Options</title>

<para>
This section of the document by Hans, 
<ulink
url="mailto:lermen@fgan.de"
>&#60;lermen@fgan.de&#62;</ulink
>. Last
updated on Mar 20, 1998.
</para>

<para>
Most of DOSEMU configuration is done during runtime and per default it
expects the system wide configuration file /etc/dosemu.conf optionally
followed by the users ~/.dosemurc and additional configurations statements
on the commandline (-I option). The builtin configuration file of a DEXE
file is passed using the -I technique, hence the rules of -I apply.
</para>

<para>
In fact /etc/dosemu.conf and ~/.dosemurc (which have identical syntax)
are included by the systemwide configuration script
/var/lib/dosemu/global.conf, but as a normal user you won't ever think on
editing this, only dosemu.conf and your personal ~/.dosemurc.
</para>

<para>
In DOSEMU prior to 0.97.5 the private configuration file was called ~/.dosrc
(not to be confused with the new ~/.dosemurc). This will work as expected
formerly, but is subject to be nolonger supported in the near future.
This (old) ~/.dosrc is processed <emphasis>after</emphasis> global.conf and follows (same
as -I) the syntax of global.conf.
</para>

<para>
The first file expected (and interpreted) before any other configuration
(such as global.conf, dosemu.conf and ~/.dosemurc) is /etc/dosemu.users.
If /etc/dosemu.users doesn't exist, DOSEMU check for /etc/dosemu/dosemu.users,
this makes people happy, which prefer to have to configuration stuff in
a separate directory under /etc.
Within dosemu.users the general permissions are set:
</para>

<para>

<itemizedlist>
<listitem>

<para>
 which users are allowed to use DOSEMU.
</para>
</listitem>
<listitem>

<para>
 which users are allowed to use DOSEMU suid root.
</para>
</listitem>
<listitem>

<para>
 which users are allowed to have a private lib dir.
</para>
</listitem>
<listitem>

<para>
 what kind of access class the user belongs to.
</para>
</listitem>
<listitem>

<para>
 what special configuration stuff the users needs
</para>
</listitem>

</itemizedlist>

</para>

<para>
and further more:

<itemizedlist>
<listitem>

<para>
 whether the lib dir (/var/lib/dosemu) resides elsewhere.
</para>
</listitem>
<listitem>

<para>
 setting the loglevel.
</para>
</listitem>

</itemizedlist>

</para>

<para>
This is done via setting configuration variables.
</para>

<para>
After /etc/dosemu.users /etc/dosemu.conf (via global.conf) is interpreted,
and only during global.conf parsing access to all configuration options is
allowed. Your personal ~/.dosemurc is included directly after dosemu.conf,
but has less access rights (in fact the lowest level), all variables you
define within ~/.dosemurc transparently are prefixed with `dosemu_' such
that the normal namespace cannot be polluted (and a hacker cannot overwrite
security relevant enviroment variables). Within global.conf only those
~/.dosemurc created variables, that are needed are taken over and may
overwrite those defined in /etc/dosemu.conf.
</para>

<para>
The dosemu.conf (global.conf) may check for the configuration variables,
that are set in /etc/dosemu.users and optionaly include further configuration
files. But once /etc/dosemu.conf (global.conf) has finished interpretation,
the access to secure relevant configurations is (class-wise) restricted while
the following interpretation of (old) .dosrc and -I statements.
</para>

<para>
For an example of a general configuration  look
at ./etc/global.conf. The later behaves insecure, when /etc/dosemu.users
is a copy of ./etc/dosemu.users.easy and behave 'secure', when
/etc/dosemu.users is a copy of ./etc/dosemu.users.secure.
</para>

<sect2>
<title>Format of /etc/dosemu.users</title>

<para>
Except for lines starting with x=' (explanation below),
each line corresponds to exactly _one_ valid user count:
</para>

<para>

<screen>
  loginname [ c_strict ] [ classes ...] [ c_dexeonly ] [ other ]
</screen>

</para>

<para>
where the elements are:
</para>

<para>
<variablelist>

<varlistentry>
<term>loginname</term>
<listitem>
<para>
 valid login name (root also is one) or 'all'. The later means
any user not mentioned in previous lines.
</para>
</listitem></varlistentry>
<varlistentry>
<term>nosuidroot</term>
<listitem>
<para>
 Do not allow execution of a suid dosemu binary. The user
may, howver, use a non-suid root copy of DOSEMU
(reasonable sysadmins will supply it)
For more information on this look at chapter 11.1
(`Priveleges and Running as User')
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_strict</term>
<listitem>
<para>
 Do not allow -F option (global.conf can't be replaced)
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_dexeonly</term>
<listitem>
<para>
 Only allow execution of DEXE files, forbid any other use.
</para>
</listitem></varlistentry>
<varlistentry>
<term>classes</term>
<listitem>
<para>
 One or more of the following:
<variablelist>

<varlistentry>
<term>c_all</term>
<listitem>
<para>
 no restriction
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_normal</term>
<listitem>
<para>
 normal restrictions, all but the following classes:
c_var, c_boot, c_vport, c_secure, c_irq, c_hardram.
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_var</term>
<listitem>
<para>
     allow (un)setting of configuration- and
environment variables
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_nice</term>
<listitem>
<para>
    allow `HogThreshold' setting
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_floppy</term>
<listitem>
<para>
  allow floppy access
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_boot</term>
<listitem>
<para>
    allow definition of boot file/device
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_secure</term>
<listitem>
<para>
  allow setting of 'secure off'
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_vport</term>
<listitem>
<para>
   allow setting of 'allowvideoportaccess'
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_dpmi</term>
<listitem>
<para>
    allow DPMI setting
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_video</term>
<listitem>
<para>
   allow `video' setting
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_port</term>
<listitem>
<para>
    allow `port' setting
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_disk</term>
<listitem>
<para>
    allow `disk'  settings
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_x</term>
<listitem>
<para>
       allow X support settings
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_sound</term>
<listitem>
<para>
   allow sound settings
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_irq</term>
<listitem>
<para>
     allow `irqpassing' statement
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_dexe</term>
<listitem>
<para>
    allow `dexe' settings
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_printer</term>
<listitem>
<para>
 allow printer settings
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_hardram</term>
<listitem>
<para>
 allow 'hardware_ram' settings
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_shell</term>
<listitem>
<para>
   allow the parser's `shell()' function
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</listitem></varlistentry>
<varlistentry>
<term>other</term>
<listitem>
<para>
      Here you may define any configuration variable, that you
want to test
in global.conf (or (old) .dosrc, -I), see `ifdef', `ifndef'
When this variable is intended to be unset in lower privilege
configuration files (.dosrc, -I), then the variable name
has to be prefixed with `u_'.
</para>
</listitem></varlistentry>
<varlistentry>
<term>private_setup</term>
<listitem>
<para>
 Keyword, this makes dosemu to accept a private DOSEMU lib
under  $HOME/.dosemu/lib. If this directory is existing, DOSEMU
will expect all normally under /var/lib/dosemu within that
directory,including `global.conf'. As this would be a security
risc, it only will be allowed, if the used DOSEMU binary is
non-suid-root. If you realy trust a user you may additionally
give the keyword `unrestricted', which will allow this user to
execute a suid-root binary even on a private lib directory
(though, be aware).
</para>
</listitem></varlistentry>
<varlistentry>
<term>unrestricted</term>
<listitem>
<para>
 Keyword, used to allow `private_setup' on suid-root
binaries too. USE WITH CARE !
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>
A line with '#' at colum 1 is treated as comment line. When only the login
name is given (no further parameters, old format) the following setting is
assumed:
</para>

<para>

<screen>
  if 'root'  c_all
  else       c_normal
</screen>

</para>

<para>
Other than with previous DOSEMU versions, the /etc/dosemu.users now is
mandatory. Also note, that you may restrict 'root' doing something silly ;-)
</para>

<para>
In addition, dosemu.users can be used to define some global settings, which
must be known before any other file is accessed, such as:

<screen>
  default_lib_dir= /opt/dosemu  # replaces /var/lib/dosemu
  log_level= 2                  # highest log level
</screen>

</para>

<para>
With `default_lib_dir=' you may move /var/lib/dosemu elsewere, this mostly
is interesting for distributors, who want it elswere but won't patch the
DOSEMU source just for this purpose. But note, the dosemu supplied scripts
and helpers may need some adaption too in order to fit your new directory.
</para>

<para>
The `log_level=' can be 0 (never log) or 1 (log only errors) or 2 (log all)
and controls the ammount written to the systems log facility (notice).
This keyword replaces the former /etc/dosemu.loglevel file, which now is
obsolete.
</para>

</sect2>

<sect2>
<title>Format of /var/lib/dosemu/global.conf ( (old) .dosrc, -I option)</title>

<para>
The configuration files are not line oriented, instead are consisting of
`statements' (optionally separated by `;'), whitespaces are removed
and all behind a '#' up to the end of the line is treated as comment.
( Note that older DOSEMUs also allowed `!' and `;' as comment character,
but those are no longer supported ). 
</para>

<sect3>
<title>Enviroment variables and configuration variables</title>

<para>
They existed already in very early versions of DOSEMU (until now),
but now evironment variables are much more useful in dosemu.conf / global.conf
as before, because you now can set them, test them in the new 'if' statement
and compute them in expressions.
The problem with the enviroment variables is, however,
that the user may set and fake them <emphasis>before</emphasis> calling DOSEMU, hence this
is a security problem. To avoid this, we have the above mentioned
<emphasis>configuration variables</emphasis>, which are of complete different name space
and are not visible outside of DOSEMU's configuration parser. On the other
hand it may be useful to export settings from global.conf to the
running DOS environment, which can be achieved by the 'unix.exe -e'
DOS programm.
</para>

<para>
To summarize:
<variablelist>

<varlistentry>
<term>configuration variables</term>
<listitem>
<para>
 have their own namespace only within the
configuration parser. They usual are prefixed by <emphasis>c_</emphasis>, <emphasis>u_</emphasis>
and <emphasis>h_</emphasis> and cannot be made visible outside. They do not contain
any value and are only tested for existence.
</para>
</listitem></varlistentry>
<varlistentry>
<term>environment variables</term>
<listitem>
<para>
 are inherited from the calling process, can
be set within global.conf (dosemu.conf) and passed to DOSEMU running
DOS-applications. Within *.conf they always are prefixed
by '$' (Hence TERM becomes $TERM, even on the left side of an
assigment). However, <emphasis>setting</emphasis> them is controled by the configuration
variable 'c_var' (see above) and may be disallowed within the user
supplied (old) .dosrc and alike.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>
At startup DOSEMU generates the following environment variables, which
may be used to let the configuration adapt better:
</para>

<para>
<variablelist>

<varlistentry>
<term>KERNEL_VERSION_CODE</term>
<listitem>
<para>
 holds the numerical coded version of the running
linux kernel (same format as within linux/version.h)
</para>
</listitem></varlistentry>
<varlistentry>
<term>DOSEMU_VERSION_CODE</term>
<listitem>
<para>
 holds the numerical coded version of the running
DOSEMU version (format: MSB ... LSB == major, minor, patchlevel,
sublevel)
</para>
</listitem></varlistentry>
<varlistentry>
<term>DOSEMU_EUID</term>
<listitem>
<para>
 effective uid
</para>
</listitem></varlistentry>
<varlistentry>
<term>DOSEMU_UID</term>
<listitem>
<para>
 uid. You may protect security relevant parts of the
configuration such as:

<screen>
if ( ! $DOSEMU_EUID &#38;&#38; ($DOSEMU_EUID != $DOSEMU_UID) )
  warn "running suid root"
endif
  
</screen>

</para>
</listitem></varlistentry>
<varlistentry>
<term>DOSEMU_HOST</term>
<listitem>
<para>
 Name of the host DOSEMU is running on. This is same
as what follows the `h_' configuration variable, see below.
( if not available, then DOSEMU_HOST contains `unknown' )
</para>
</listitem></varlistentry>
<varlistentry>
<term>DOSEMU_USER</term>
<listitem>
<para>
 The user name, that got matched in /etc/dosemu.users.
This needs not to be the _real_ user name, it may be `all' or
`unknown'.
</para>
</listitem></varlistentry>
<varlistentry>
<term>DOSEMU_REAL_USER</term>
<listitem>
<para>
 The user name out of getpwuid(uid).
</para>
</listitem></varlistentry>
<varlistentry>
<term>DOSEMU_SHELL_RETURN</term>
<listitem>
<para>
 The exitcode (0-255) from the recently executed
<emphasis>shell()</emphasis> command.
</para>
</listitem></varlistentry>
<varlistentry>
<term>DOSEMU_OPTIONS</term>
<listitem>
<para>
      A string of all commandline options used (one
character per option). You may remove a character from this string,
such that the normal override of dosemu.conf settings will not take
place for that option. However, parsing the command line options
happens in two stages, one _before_ parsing dosemu.conf and one
_after_. The options 'FfhIdLoO23456' have
already gotten processed before dosemu.conf, so they can be disabled.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

</sect3>

<sect3>
<title>Conditional statements</title>

<para>
You may control execution of configuration statements via the following
conditional statement:
</para>

<para>

<screen>
  ifdef &#60;configuration variable&#62;
</screen>

or

<screen>
  ifndef &#60;configuration variable&#62;
    ...
  else
    ...
  endif
</screen>

</para>

<para>
 where <emphasis>variable</emphasis> is a <emphasis>configuration variable</emphasis> (not an
environment variable). Additionally there is a `normal' <emphasis>if statement</emphasis>,
a <emphasis>while statement</emphasis> and a <emphasis>foreach statement</emphasis> such as

<screen>
  if ( expression )
  endif
  while ( expression )
  done
  foreach loop_variable (delim, list)
  done
</screen>

but these behaves a bit different and are described later.
</para>

<para>
The 'else' clause may be ommitted and 'ifndef' is the opposite to 'ifdef'.
The &lt;variable&gt; can't be tested for its contents, only if it is set or not.
Clauses also may contain further if*def..endif clause up to a depth of 15.
All stuff in /etc/dosemu.users behind the 'loginname' in fact are
<emphasis>configuration variables</emphasis>
that are set. Hence, what you set there, can be tested here in the config
file. Further more you may set/unset  <emphasis>configuration variables</emphasis>
in the config files itself:
</para>

<para>

<screen>
  define &#60;configuration variable&#62;
  undef  &#60;configuration variable&#62;
</screen>

</para>

<para>
However, use of define/undef is restricted to scope of global.conf,
as long as you don't 'define c_var' _within_ global.conf.
If you are under scope of a 'user config file' (e.g. outside
global.conf) you have to prefix the <emphasis>configuration variable</emphasis>
name with 'u_', else it
will not be allowed to be set/unset (hence 'c_' type variables can't be
unset out of scope of global.conf).
</para>

<para>
There are some <emphasis>configuration variables</emphasis>
(besides the ones described above for dosemu.users)
implicitely predefined by DOSEMU itself:
</para>

<para>
<variablelist>

<varlistentry>
<term>c_system</term>
<listitem>
<para>
     set while being in /var/lib/dosemu/global.conf
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_user</term>
<listitem>
<para>
       set while parsing a user configuration file
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_dosrc</term>
<listitem>
<para>
      set while parsing (old) .dosrc
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_comline</term>
<listitem>
<para>
    set while parsing -I option statements
</para>
</listitem></varlistentry>
<varlistentry>
<term>c_dexerun</term>
<listitem>
<para>
    set if a DEXE will be executed
</para>
</listitem></varlistentry>
<varlistentry>
<term>h_&lt;ownhost&gt;</term>
<listitem>
<para>
  defined on startup as 'h_&lt;host&gt;.&lt;domain&gt;' of the host
DOSEMU is running on. If &lt;domain&gt; can't be resolved,
the pure hostname is taken. This makes sense only if a file
system containing DOSEMU is mounted on diskless machines and you
want restrict access. Note however, h_&lt;ownhost&gt; is set using
gethostname/getdomainname. Hence, if the user on the
diskless machine has root access, this is _not_ secure,
because he could fake a valid address.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>
Also, you may define any 'u_' type variable at start of DOSEMU via the new
option -u such as
</para>

<para>

<screen>
# dosemu -u myspecialfun
</screen>

</para>

<para>
this will then define the config variable 'u_myspecialfun' _before_ parsing
any configuration file. You then may check this in your (old) ./dosrc or
global.conf to do the needed special configuration.
</para>

<para>
Now, what's this with the <emphasis>if statement</emphasis> and <emphasis>while statement</emphasis>?
All those conditionals via <emphasis>ifdef</emphasis> and <emphasis>indef</emphasis> are completly
handled <emphasis>before</emphasis> the remaining input is passed to the parser. Hence you
even may use them <emphasis>within</emphasis> a configuration statement such as
</para>

<para>

<screen>
terminal { charset
  ifdef u_likeibm
    ibm
  else
    latin
  endif
  updatefreq 4  color on }
</screen>

</para>

<para>
This is not the case with the (above mentioned) <emphasis>if statement</emphasis>, this one
is of course processed within the parser itself and can only take place within
the proper syntax context such as
</para>

<para>

<screen>
      
  if ( defined( u_likeibm ) )
    $mycharset = "ibm"
  else
    $mycharset = "latin"
  endif
  terminal { charset $mycharset updatefreq 4  color on }
</screen>

</para>

<para>
but it has the advantage, that you can put any (even complex)
<emphasis>expression</emphasis> (see chapter `expressions') between the brackets.
If the expression's numerical value is 0, then false is assumed, else true.
</para>

<para>
Same rules apply to the <emphasis>while statement</emphasis>, the loop will be executed
as long as `expression' is not 0. The loop end is given by the keyword
<emphasis>done</emphasis> such as in
</para>

<para>

<screen>
  $counter = (3)
  while ($counter &#62; 0)
    # what ever should loop
    $counter = ($counter -1)
  done

  # or some kind of list processing
  # ... but look below, `foreach' does it better
  $list = "aa bbb ccc"
  while (strlen($list))
    $item = strdel($list, strchr($list," "), 999)
    $list = strsplit($list, (strlen($item)+1),9999);
    warn "doing something with ", $item
  done

</screen>

</para>

<para>
The <emphasis>foreach statement</emphasis> behaves a bit like the /bin/sh `for i in', but
you can specify a list of delimiters.
</para>

<para>

<screen>
  $list = "anton, berta; caesar dora"
  $delim = " ,;"
  foreach $xx ($delim, $list)
    warn "My name is ", $xx
  done

  $list = "a b c : 1 2 3"               
  $delim = ":"
  foreach $xx ($delim, $list)
    if ($delim eq ":")
      $delim = " ";
    else
      warn "processing number ", $xx
    endif
  done
</screen>

The later example jumps to the colon (`:') in one step and after that
process the numbers step by step.
</para>

<para>
For all loops and `if' statement the allowed depth is 32 (totally).
</para>

</sect3>

<sect3>
<title>Include files</title>

<para>
If you for some reason want to bundle some major settings in a separate file
you can include it via
</para>

<para>

<screen>
  include "somefile"
</screen>

</para>

<para>
If 'somefile' doesn't have a leading '/', it is assumed to be relative to /etc.
Also includeing may be nested up to a max depth of 10 files.
Note however, that the privilege is inherited from the main file from which
is included, hence all what is included by /var/lib/dosemu/global.conf has its
privilege.
</para>

<para>
However, there are restrictions for `while' loops: You can't have
<emphasis>include statements</emphasis> within loops without beeing prepared for unexpected
behave. In fact you may try, but due to the technique used, include files
within loops are loaded completely <emphasis>prior</emphasis> loop execution.
Hence, if you do conditional including this won't work.
</para>

<para>
A further restriction is, that the name of the include file must not be
a variable. However, you can work around this with a macro (see next
chapter) as shows the following example:
</para>

<para>

<screen>
  $file = $HOME, "/.my_dosrc_include"
  shell("test -f ", $file)
  if ( ! $DOSEMU_SHELL_RETURN)                                       
    # we can include
    $INC = ' include "', $file, '"';
    $$INC
  endif
</screen>

</para>

</sect3>

<sect3>
<title>Macro substitution</title>

<para>
There is a <emphasis>very</emphasis> rudimentary macro substitution available, which
does allow recursion but no arguments: Whenever you write
</para>

<para>

<screen>
  $MYMACRO = "warn 'this is executed as macro'" ;
  $$MYMACRO
</screen>

it will expand to

<screen>
  warn 'this is executed as macro'
</screen>

</para>

<para>
Note, that the `;' is required for parser to recognize the end of the
statement and to set the variable <emphasis>before</emphasis> it tries to read the next
token (which will let the lexer process `$$MYMACRO'). Macro substitution
is completely done on the input stream before the parser gets the data.
</para>

<para>
For what is it worth then? Now, this enables you to insert text into the
input stream, that otherwise would be expected to be constant. Or simple,
it allows you to be lazy to write the same things more then once.

<screen>
  $loop = '
    while ($xxx)
      warn "loop in macro ",$xxx
      $xxx = ($xxx -1)
    done  
  ';
  $xxx = (2); $$loop; $xxx = (3); $$loop;

  $_X_keycode = (off)
  $_X_lin_filt = (on)
  ...
  if ($_X_keycode) $_X_keycode = "keycode" else $_X_keycode = "" endif
  if ($_X_lin_filt) $_X_lin_filt = "lin_filt" else $_X_lin_filt = "" endif
  X { icon_name "xdos" $$_X_keycode $$_X_lin_filt }
</screen>

You see, that in cases the variables are `false', the (parameterless)
`keycode' and/or `lin_filt' keywords would not appear in the `X{}' statement.
</para>

</sect3>

<sect3>
<title>Expressions</title>

<para>
Expression within the configuration files follow the usual numerical rules
and may be as complex as you wish. At some places, the parser only can
`understand' expressions, when you enclose them in brackets, but mostly
you just can type

<screen>
  123 + 456 + 2 * 1.2
</screen>

</para>

<para>
Though, if you want be sure, you better type them as

<screen>
  ( 123 + 456 + 2 * 1.2 )
</screen>

</para>

<para>
You may place expressions whenever a numerical value is expected and there
is no ambiguity in the syntax. Such an ambiguity is given, when a statement
needs more then one successive number such as
</para>

<para>

<screen>
  ... winsize x y ...
  ... vesamode width heigh ...
  ... range from to ...
</screen>

</para>

<para>
If you want to place expression herein, you need the new syntax for those
statements / terms which have a coma (instead of a blank) as delimiter:
</para>

<para>

<screen>
  ... winsize x , y ...
  ... vesamode width , heigh ...
  ... range from , to ...
</screen>

</para>

<para>
The old syntax is left for compatibility and is only parsed correcty, if
pure numbers (integers) are used.
</para>

<para>
Valid constant numbers (not only in expressions) are

<screen>
  123     decimal, integer
  0x1a    hexadecimal, integer
  0b10101 bitstream, integer
  1.2     float number, real
  0.5e3   exponential form, real
  off     boolean false, integer
  on      boolean true, integer
  no      boolean false, integer
  yes     boolean true, integer
</screen>

</para>

<para>
The following operator are recognized:

<screen>
  + - *   as usual
  / div   division, the '/' _must_ be surrounded by whitespaces, else
          it conflicts with pathnames on quoteless strings
  |       bitwise or
  ^       bitwise exclusive or
  ~       bitwise not
  &#38;       bitwise and
  &#62;&#62;      shift right
  &#60;&#60;      shift left
  &#60;       less then
  &#60;=      less or equal
  &#62;       greater then
  &#62;=      greater or equal
  ||      boolean or
  &#38;&#38;      boolean and
  !       boolean not
  ==      numerical equivalence
  eq      string equivalence
  !=      numerical, not equal
  ne      string not equal
</screen>

</para>

<para>
The type of the expression result may be real (float) or integer, depending
on which type is on the `left side'. Conversion is mostly done automaticaly,
but you may force it using the (below mentioned) int() and real() functions
such as:

<screen>
   $is_real =    ( 3.1415 * 100 )
   $is_integer = ( int( 3.1415 * 100) )
   $is_integer = ( 100 * 3.1415 )
   $is_real =  ( real($is_integer) )
</screen>

</para>

<para>
The above also shows, how environment variables can be set: if you want
to place `expressions' (which are always numbers) onto a variable, you
have to surround them with brackets, else the parser won't be able to detect
them. In principal, all $xxx settings are string-settings and numbers will
be converted correctly before. In fact the `$xxx =' statement accepts a
complete coma separated list, which it will concatenate, examples:
</para>

<para>

<screen>
  $termnum = (1)
  $MYTERM = "/dev/ttyp", $termnum       # results in "/dev/ttyp1"
  $VER = (($DOSEMU_VERSION_CODE &#62;&#62; 24) &#38; 255)
  $MINOR = (($DOSEMU_VERSION_CODE &#62;&#62; 16) &#38; 255)
  $running_dosemu = "dosemu-", $VER, ".", $MINOR
</screen>

</para>

<para>
Several builtin functions, which can be used in expressions, are available:
<variablelist>

<varlistentry>
<term>int(real)</term>
<listitem>
<para>
         converts a float expression to integer
</para>
</listitem></varlistentry>
<varlistentry>
<term>real(integer)</term>
<listitem>
<para>
    converts a integer expression to float
</para>
</listitem></varlistentry>
<varlistentry>
<term>strlen(string)</term>
<listitem>
<para>
    returns the length of `string'
</para>
</listitem></varlistentry>
<varlistentry>
<term>strtol(string)</term>
<listitem>
<para>
    returns the integer value of `string'
</para>
</listitem></varlistentry>
<varlistentry>
<term>strncmp(str1,str2,expression)</term>
<listitem>
<para>
 compares strings, see `man strncmp'
</para>
</listitem></varlistentry>
<varlistentry>
<term>strpbrk(str1,str2)</term>
<listitem>
<para>
 like `man strpbrk', but returns an index
or -1 instead of a char pointer.
</para>
</listitem></varlistentry>
<varlistentry>
<term>strchr(str1,str2)</term>
<listitem>
<para>
 like `man strchr', but returns an index
or -1 instead of a char pointer.
</para>
</listitem></varlistentry>
<varlistentry>
<term>strrchr(str1,str2)</term>
<listitem>
<para>
 like `man strrchr', but returns an index
or -1 instead of a char pointer.
</para>
</listitem></varlistentry>
<varlistentry>
<term>strstr(str1,str2)</term>
<listitem>
<para>
 like `man strstr', but returns an index
or -1 instead of a char pointer.
</para>
</listitem></varlistentry>
<varlistentry>
<term>strspn(str1,str2)</term>
<listitem>
<para>
 as `man strspn'
</para>
</listitem></varlistentry>
<varlistentry>
<term>strcspn(str1,str2)</term>
<listitem>
<para>
 as `man strcspn'
</para>
</listitem></varlistentry>
<varlistentry>
<term>defined(varname)</term>
<listitem>
<para>
  returns true, if the configuration variable
`varname' exists.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

</sect3>

<sect3>
<title>String expressions</title>

<para>
For manipulation of strings there are the following builtin functions,
which all return a new string. These very well may be placed as argument
to a numerical function's string argument, but within an `expression' they
may be only used together with the `eq' or `ne' operator.
</para>

<para>
<variablelist>

<varlistentry>
<term>strcat(str1, ,strn)</term>
<listitem>
<para>
 concatenates any number of strings, the result
is a string again.
</para>
</listitem></varlistentry>
<varlistentry>
<term>strsplit(string, expr1, expr2)</term>
<listitem>
<para>
 cuts off parts of `string', starting
at index `expr1' with length of `expr2'.
If either `expr1' is &#60; 0 or `expr2' is &#60; 1, an empty
string is returned.
</para>
</listitem></varlistentry>
<varlistentry>
<term>strdel(string, expr1, expr2)</term>
<listitem>
<para>
 deletes parts of `string', starting
at index `expr1' with length of `expr2'.
If either `expr1' or `expr2' is &#60; 0, nothing
is deleted (the original strings is returned.)
</para>
</listitem></varlistentry>
<varlistentry>
<term>shell(string)</term>
<listitem>
<para>
     executes the command in `string' and returns
its stdout result in a string. The exit code of
executed command is put into $DOSEMU_SHELL_RETURN
(value between 0 and 255). You may also call
shell() as a standalone statement (hence
discarding the returned string), if you only need
$DOSEMU_SHELL_RETURN (or not even that).
However, to avoid
security implications all privilegdes are dropped
and executions is under control of <emphasis>c_shell</emphasis>
configuration variable. The default is, that it
can only be executed from within global.conf.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>
With these tools you should be able to make your global.conf adapt
to any special case, such as different terminal types, different hdimages
for different users and/or different host, adapt to different (future)
dosemu and/or kernel versions. Here some small examples:
</para>

<para>

<screen>
  $whoami = shell("who am i")
  if ( strchr($whoami, "(" ) &#60; 0 )
    # beeing on console
  else
    if (strstr($whoami, "(:") &#60; 0)
      # beeing remote logged in
    endif
    if ($TERM eq "xterm")
      # beeing on xterm
    else
      if (strstr("linux console", $TERM) &#60; 0)
        # remote side must be some type of real terminal
      else
        # remote side is a Linux console
      endif
    endif
  endif

  if ($DISPLAY ne "")
    # we can rely on reaching an Xserver
    if (strsplit($DISPLAY, 0, 1) ne ":")
      # the X server is remote
    endif
  endif

  if ($DOSEMU_REAL_USER eq "alistair")
    # ha, this one is allowed to do odds sound tricks :-)
  endif

  if (strsplit($DOSEMU_HOST, 0, strchr($DOSEMU_HOST,"."))
                                                   eq $DOSEMU_HOST)
    # we have no domain suffix for this host, should be a local one
  endif

  # disable setting graphics mode per commandline option -g
  $DOSEMU_OPTIONS = strdel($DOSEMU_OPTIONS, strchr($DOSEMU_OPTIONS,"g"),1);

</screen>

</para>

</sect3>

<sect3>
<title>`Dry' testing your configuration</title>

<para>
It may be usefull to verify, that your *.conf does what you
want before starting a real running DOSEMU. For this purpose there is a 
new commandline option (-h), which just runs the parser, print some
useful output, dumps the main configuration structure and then exits.
The option has an argument (0,1,2), which sets the amount of parser debug
output: 0 = no parser debug, 1 = print loop debugs, 2 = same as 1 plus
if_else_endif-stack debug. This feature can be used such as
</para>

<para>

<screen>
  $ dosemu.bin -h0 -O 2&#62;&#38;1 | less
</screen>

</para>

<para>
The output of `-h2' looks like

<screen>
  PUSH 1-&#62;2 1 &#62;foreach__yy__&#60;
  PUSH 2-&#62;3 1 &#62;if&#60;
  POP 2&#60;-3 0 &#62;endif&#60; -1
  POP 1&#60;-2 1 &#62;done&#60; -1
  PUSH 1-&#62;2 1 &#62;foreach__yy__&#60;
  PUSH 2-&#62;3 1 &#62;if&#60;
  POP 2&#60;-3 1 &#62;endif&#60; -1
  POP 1&#60;-2 1 &#62;done&#60; -1
      |  | |         +-------`cached' read status (0 = not cached)
      |  | +-----------------`if' or `loop' test result (0 = false = skipped)
      |  +-------------------inner level
      +----------------------outer level (1 = no depth)
</screen>

</para>

<para>
There are also some configuration statements, which aren't of any use
except for help debugging your *.conf such as
</para>

<para>

<screen>
  exprtest ($DOSEMU_VERSION_CODE)   # will just print the result
  warn "content of DOSEMU_VERSION_CODE: ", $DOSEMU_VERSION_CODE
</screen>

</para>

</sect3>

<sect3>
<title>Debug statement</title>

<para>
This section is of interest mainly to programmers.  This is useful if
you are having problems with DOSEMU and you want to enclose debug info
when you make bug reports to a member of the DOSEMU development team.
Simply set desired flags to "on" or "off", then redirect stderr of
DOSEMU to a file using "dosemu.bin -o debug" to record the debug information
if desired.  Skip this section if you're only starting to set up.
</para>

<para>

<screen>
  debug { config  off	disk    off	warning off	hardware off
        port    off	read    off	general off	IPC      off
        video   off	write   off	xms     off	ems      off
        serial  off	keyb    off	dpmi    off
       	printer off	mouse   off	sound	off
  }
</screen>

</para>

<para>
Alternatively you may use the same format as -D commandline option
(but without the -D in front), look at the dosemu.bin.1 man page.
</para>

<para>

<screen>
  debug "+a-v"     # all messages but video
  debug "+4r"      # default + maximum of PIC debug
</screen>
    
</para>

<para>
or simply (to turn off all debugging)
</para>

<para>

<screen>
  debug { off }
</screen>

</para>

</sect3>

<sect3>
<title>Miscellaneous</title>

<para>
The HogThreshold value determines how nice Dosemu will be about
giving other Linux processes a chance to run.  Setting the HogThreshold
value to approximately half of you BogoMips value will slightly
degrade Dosemu performance, but significantly increase overall
system idle time.  A zero value runs Dosemu at full tilt.
</para>

<para>

<screen>
  HogThreshold 0
</screen>

</para>

<para>
Want startup DOSEMU banner messages?  Of course :-)
</para>

<para>

<screen>
  dosbanner on
</screen>

</para>

<para>
Timint is necessary for many programs to work.
</para>

<para>

<screen>
  timint on
</screen>

</para>

<para>
For "mathco", set this to "on" to enable the coprocessor during DOSEMU.
This really only has an effect on kernels prior to 1.0.3.
</para>

<para>

<screen>
  mathco on
</screen>

</para>

<para>
For "cpu", set this to the CPU you want recognized during DOSEMU.
</para>

<para>

<screen>
  cpu 80386
</screen>

</para>

<para>
If you have DOSEMU configured to use the 386-emulator, you can enable the
emulator via
</para>

<para>

<screen>
  cpu emulated
</screen>

</para>

<para>
You may ask why we need to emulate a 386 on an 386 ;-) Well, for normal
purpose its not needed (and will be slower anyway), but the emulator offers
a better way to debug DOS applications, especially DPMI code.
Also, we hope that some day we may be able to run DOSEMU on other machines
than 386. At the time of writing this, the cpu emulators is very alpha and
you should not use it except you are willing to help us. So please, don't
even try to report 'bugs' except you have a patch for the bug too.
</para>

<para>
If you have a pentium, DOSEMU can make use of the pentium cycle counter
to do better timing. DOSEMU detects the pentium and will use the RDTSC
instruction for get time per default. To disable this feature use
</para>

<para>

<screen>
  rdtsc off
</screen>

</para>

<para>
Also, to use the pentium cycle counter correctly DOSEMU needs to know
the CPU-clock which your chip is running. This per default is calibrated
automatically, however, that may be not exact enough. In this case you
have to set it yourself via
</para>

<para>

<screen>
  cpuspeed 180
</screen>

</para>

<para>
or, for values like 166.6666 you may give two numbers such as
</para>

<para>

<screen>
  
  cpuspeed 500 3
</screen>

</para>

<para>
which will be calculated as 'cpuspeed=500/3'
</para>

<para>
If you have a PCI board you may allow DOSEMU to access the PCI configuration
space by defining the below
</para>

<para>

<screen>
  pci on | off
</screen>

</para>

<para>
PCI is assumed to be present on CPUs better then a pentium, otherwise
the default is 'pci off'
</para>

<para>
For "bootA"/"bootC", set this to the bootup drive you want to use.
It is strongly recommended you start with "bootA" to get DOSEMU
going, and during configuration of DOSEMU to recognize hard disks.
</para>

<para>

<screen>
  bootA
</screen>

</para>

<para>
During compile there will be a symbol map generated, this usually
then is ./bin/dosemu.map. You may wnt to save it to an other places
and let 'dosdebug' know where to find it:
</para>

<para>

<screen>
  dosemumap /var/lib/dosemu/dosemu.map
</screen>

</para>

<para>
Normally all debug logging is done _imediately_ (unbuffered). However,
when dumping big amounts of logdata, the dynamic behave of DOSEMU may
change, hence hiding the real problem (or causing a new one)
Using the below switches buffering on and sets the buffer size.
</para>

<para>

<screen>
  logbufsize 0x20000
</screen>

</para>

<para>
In addition, you may want to limit the file size of the log file, especially
when you expect huge amounts of data (such as with -D+e). This can be done
via

<screen>
  logfilesize 0x200000
</screen>

</para>

<para>
which (in this case) will limit the size to 2Mbytes. The default setting is
a file size of 10Mbytes.
</para>

<para>
When you want to abort DOSEMU from within a configuration file (because
you detected something weird) then do
</para>

<para>

<screen>
  abort
</screen>

or

<screen>
  abort "message text"
</screen>

</para>

<para>
When you want just to warn the user use the following (the message will
get printed to the log file via the debug-flag '+c')
</para>

<para>

<screen>
  warn "message text"
</screen>

</para>

<para>
When you want to use the CDrom driver and the Linux device is other
then /dev/cdrom you may define
</para>

<para>

<screen>
  cdrom { /dev/xxx }
</screen>

</para>

<para>
However, you need to include the DOSEMU supplied cdrom.sys into your config.sys
such as

<screen>
  device=cdrom.sys
</screen>

</para>

<para>
If you have more then one cdrom, you have to use the cdrom statement
multiple times such as

<screen>
  cdrom { /dev/cdrom }
  cdrom { /dev/cdrom2 }
</screen>

and have multiple instancies of the DOS driver too:

<screen>
  device=cdrom.sys
  device=cdrom.sys 2
</screen>

</para>

<para>
In any case you will need MSCDEX.EXE in your autoexe.bat refer to the
DOS devices MSCD0001, MSCD0002 respectively.
</para>

</sect3>

<sect3>
<title>Code page and character set</title>

<para>
To select the character set and code page for use with DOSEMU we now
(against earlier versions of DOSEMU) have a separate statement:

<screen>
  charset XXX
</screen>

where XXX is one of
<variablelist>

<varlistentry>
<term>ibm</term>
<listitem>
<para>
 the text is taken whithout translation, it is to the user
to load a proper DOS font (cp437.f16, cp850.f16 or cp852.f16 on the
console).
</para>
</listitem></varlistentry>
<varlistentry>
<term>latin</term>
<listitem>
<para>
 the text is processed using cp437-&#62;iso-8859-1 translation,
so the font used must be iso-8859-1 (eg iso01.f16 on console);
which is the default for unix in western languages countries.
</para>
</listitem></varlistentry>
<varlistentry>
<term>latin1</term>
<listitem>
<para>
 like latin, but using cp850-&#62;iso-8859-1 translation (the
difference between cp437 and cp850 is that cp437 uses some chars for
drawing boxes while cp850 uses them for accentuated letters)
</para>
</listitem></varlistentry>
<varlistentry>
<term>latin2</term>
<listitem>
<para>
 like latin1 but uses cp852-&#62;iso-8859-2 translation, so
translates the default DOS charset of eastern european countries to the
default unix charset for those countries.
</para>
</listitem>
</varlistentry>
</variablelist>
The default one is ``latin'' and if the string is empty, then an automatic
attempt is made: ``ibm'' for remote console and ``latin'' for anything else.
Depending on the charset setting the (below described) keyboard layouts
and/or the terminal behave may vary. You need to know the correct code page
your DOS is configured for in order to get the correct results.
For most western european countries 'latin' should be the correct setting.
</para>

</sect3>

<sect3>
<title>Keyboard settings</title>

<para>
For defining the keyboard layouts you are using there is the "keyboard"
statement such as
</para>

<para>

<screen>
  keyboard {  layout us  .... }
</screen>

or

<screen>
  keyboard {  layout us {alt 66=230} ... }
</screen>

</para>

<para>
The later modifies the US keyboard layout such that it will allow you to
type a character 230 (micro) with right ALT-M.
</para>

<para>
The same can be done via a "keytable" statement such as
</para>

<para>

<screen>
  keytable keyb-user {alt 66=230}
</screen>

</para>

<para>
The "keyb-user" is preset with an US layout and is intended to be used
as "buffer" for user defined keyboard tables.
</para>

<para>
The format of the "{}" modification list (either in the "keyboard" or the
"keytable" statement) is as follows:
</para>

<para>

<screen>
  [submap] key_number = value [,value [,...]]
</screen>

</para>

<para>
Given we call the above  a "definition" then it may be repeated 
(blank separated) such as
</para>

<para>

<screen>
  definition [definition [...]]
</screen>

</para>

<para>
"key_number" is the physical number, that the keybord send to the machine
when you hit the key, its the index into the keytable. "value" may be
any integer between 0...255, a string, or one of the following keywords
for "dead keys" (NOTE: deadkeys have a value below 32, so be carefull).
</para>

<para>

<screen>
  dgrave        (dead grave)
  dacute        (dead acute)
  dcircum       (dead circumflex)
  dtilde        (dead tilde)
  dbreve        (dead breve)
  daboved       (dead above dot)
  ddiares       (dead diaresis)
  dabover       (dead above ring)
  ddacute       (dead double acute)
  dcedilla      (dead cedilla)
  dogonek       (dead ogonek)
  dcaron        (dead caron)
</screen>

</para>

<para>
After a "key_number =" there may be any number of comma separated values,
which will go into the table starting with "key_number", hence all below
examples are equivalent
</para>

<para>

<screen>
  { 2="1" 3="2" }
  { 2="1","2" }
  { 2="12" }
  { 2=0x31,50 }
</screen>

</para>

<para>
"submap" tells in about something about the shift state for which the
definition is to use or wether we mean the numpad:
</para>

<para>

<screen>
  shift  16="Q"      (means key 16 + SHIFT pressed)
  alt    16="@"      (means key 16 + right ALT pressed (so called AltGr))
  numpad 12=","      (means numpad index 12)
</screen>

</para>

<para>
You may even replace the whole table with a comma/blank separated list of
values. In order to make it easy for you, you may use dosemu to create
such a list. The following statement will dump all current key tables out
into a file "kbdtables", which is directly suitable for inclusion into
global.conf (hence it follows the syntax):
</para>

<para>

<screen>
  keytable dump "kbdtables"
</screen>

</para>

<para>
However, don't put this not into your global.conf, because dosemu will
exit after generating the tablefile. Instead use the -I commandline option
such as
</para>

<para>

<screen>
  $ dosemu.bin -I 'keytable dump "kbdtables"'
</screen>

</para>

<para>
After installation of dosemu ("make install") you'll find the current dosemu
keytables in /var/lib/dosemu/keymap (and in ./etc/keymap, where they are
copied from). These tables are generated via "keytable dump" and split into
discrete files, such that you may modify them to fit your needs.
You may load them such as
</para>

<para>

<screen>
  $ dosemu.bin -I 'include "keymap/de-latin1"'
</screen>

</para>

<para>
(when an include file is starting with "keymap/" it is taken out of
/var/lib/dosemu). When there was a keytable previously defined (e.g.
in global.conf), they new one will be take anyway and a warning will
be printed on stderr.
</para>

<para>
Anyway, you are not forced to modify or load a keytable, and
with the "layout" keyword from the "keyboard" statement, you can specify
your country's keyboard layout.
The following builtin layouts are implemented:
</para>

<para>

<screen>
    finnish           us           dvorak       sf
    finnish-latin1    uk           sg           sf-latin1
    de                dk           sg-latin1    es
    de-latin1         dk-latin1    fr           es-latin1
    be                keyb-no      fr-latin1    po
    it                no-latin1    sw           jp106
    hu                hu-cwi       hu-latin2    keyb-user
    po                hr-cp852     hr-latin2
</screen>

</para>

<para>
The keyb-user is selected by default if the "layout" keyword is omitted,
and this in fact is identical to us-layout, as long as it got not
overloaded by the "keytable" statement (see above).
</para>

<para>
The keyword "keybint" allows more accurate of keyboard interrupts,
It is a bit unstable, but makes keyboard work better when set to "on".
</para>

<para>
The keyword "rawkeyboard" allows for accurate keyboard emulation for
DOS programs, and is only activated when DOSEMU starts up at the
console.  It only becomes a problem when DOSEMU prematurely exits
with a "Segmentation Fault" fatal error, because the keyboard would
have not been reset properly.  In that case, you would have to run
kbd_mode -a remotely, or use the RESET button.  In reality,
this should never happen.  But if it does, please do report to the
dosemu development team, of the problem and detailed circumstances,
we're trying our best!  If you don't need near complete keyboard
emulation (needed by major software package), set it to "off"
</para>

<para>
recommended:
</para>

<para>

<screen>
  keyboard {  layout us  keybint on  rawkeyboard off  }
</screen>

or

<screen>
  keyboard {  layout de-latin1  keybint on  rawkeyboard on  }
</screen>

</para>

<para>
If you want DOSEMU feed with keystrokes, that are typed in
automagically, then you may define them such as
</para>

<para>

<screen>
  keystroke "cd c:\\mysource\r"
</screen>

</para>

<para>
You may have any number of 'keystroke' statements, they all will be
concatenated.
</para>

<para>
This feature however doesn't make much sense _here_ in the
configuration file, instead together with the commandine option -I
you can start dosemu and execute any arbitrary dos command such as
</para>

<para>

<screen>
  # dosemu.bin -D-a -I 'keystroke "c:\rcd \\windows\rwinemu\r"'
</screen>

</para>

<para>
For more details please look at ./doc/README.batch
</para>

<para>
Ah, but _one_ sensible useage _here_ is to 'pre-strike' that damned F8
that is needed for DOS-7.0, when you don't want to edit the msdos.sys:
</para>

<para>

<screen>
 keystroke "\F8;"
</screen>

</para>

</sect3>

<sect3>
<title>Serial stuff</title>

<para>
You can specify up to 4 simultaneous serial ports here.
If more than one ports have the same IRQ, only one of those ports
can be used at the same time.  Also, you can specify the com port,
base address, irq, and device path!  The defaults are:
</para>

<para>

<itemizedlist>
<listitem>

<para>
    COM1 default is base 0x03F8, irq 4, and device /dev/cua0
</para>
</listitem>
<listitem>

<para>
    COM2 default is base 0x02F8, irq 3, and device /dev/cua1
</para>
</listitem>
<listitem>

<para>
    COM3 default is base 0x03E8, irq 4, and device /dev/cua2
</para>
</listitem>
<listitem>

<para>
    COM4 default is base 0x02E8, irq 3, and device /dev/cua3
</para>
</listitem>

</itemizedlist>

</para>

<para>
If the "com" keyword is omitted, the next unused COM port is assigned.
Also, remember, these are only how you want the ports to be emulated
in DOSEMU.  That means what is COM3 on IRQ 5 in real DOS, can become
COM1 on IRQ 4 in DOSEMU!
</para>

<para>
<emphasis>NOTE:</emphasis> You must have /usr/spool/uucp for LCK-file generation !
You may change this path and the lockfile name via the
below 'ttylocks' statement.
</para>

<para>
Also, as an example of defaults, these two lines are functionally equal:
</para>

<para>

<screen>
  serial { com 1  mouse }
  serial { com 1  mouse  base 0x03F8  irq 4  device /dev/cua0 }
</screen>

</para>

<para>
If you want to use a serial mouse with DOSEMU, the "mouse" keyword
should be specified in only one of the serial lines.  (For PS/2
mice, it is not necessary, and device path is in mouse line instead)
</para>

<para>
Use/modify any of the following if you want to support a modem:
(or any other serial device.)
</para>

<para>

<screen>
  serial { com 1  device /dev/modem }
  serial { com 2  device /dev/modem }
  serial { com 3  device /dev/modem }
  serial { com 4  device /dev/modem }
  serial { com 3  base 0x03E8  irq 5  device /dev/cua2 }
</screen>

</para>

<para>
If you are going to load a msdos mouse driver for mouse support
use/modify one of the following
</para>

<para>

<screen>
  serial { mouse  com 1  device /dev/mouse }
  serial { mouse  com 2  device /dev/mouse }
</screen>

</para>

<para>
What type is your mouse?  Use one of the following.
Use the 'internaldriver' option to try Dosemu internaldriver.
Use the 'emulate3buttons' for 3button mice.
</para>

<para>

<screen>
  mouse { microsoft }
  mouse { logitech }
  mouse { mmseries }
  mouse { mouseman }
  mouse { hitachi }
  mouse { mousesystems }
  mouse { busmouse }
  mouse { ps2  device /dev/mouse internaldriver emulate3buttons }
  mouse { mousesystems device /dev/mouse internaldriver cleardtr }
</screen>

</para>

<para>
For tty locking capabilities:
</para>

<para>
The serial lines are locked by dosemu via usual lock file technique,
which is compatible with most other unix apps (such as mgetty, dip,
e.t.c). However, you carefully need to check _where_ those other apps
expect the lock files. The most common used (old) place is
/usr/spool/uucp, but newer distributions following the FSSTND will have
it in /var/lock. The dosemu default one is /usr/spool/uucp.
The below defines /var/lock
</para>

<para>

<screen>
  ttylocks { directory /var/lock }
</screen>

</para>

<para>
<emphasis>Note:</emphasis> you are responsible for ensuring that the directory exists !
If you want to define the lock prefix stub also, use this one
</para>

<para>

<screen>
  ttylocks { directory /var/lock namestub LCK.. }
</screen>

</para>

<para>
If the lockfile should contain the PID in binary form (instead of ASCII},
you may use the following
</para>

<para>

<screen>
  ttylocks { directory /var/lock namestub LCK.. binary }
</screen>

</para>

</sect3>

<sect3>
<title>Networking Support</title>

<para>
Turn the following option 'on' if you require IPX/SPX emulation.
Therefore, there is no need to load IPX.COM within the DOS session.
The following option does not emulate LSL.COM, IPXODI.COM, etc.
<emphasis>NOTE: YOU MUST HAVE IPX PROTOCOL ENABLED IN KERNEL !!</emphasis>
</para>

<para>

<screen>
  ipxsupport off
</screen>

</para>

<para>
Enable Novell 8137-&gt;raw 802.3 translation hack in new packet driver.
</para>

<para>

<screen>
  pktdriver novell_hack
</screen>

</para>

</sect3>

<sect3>
<title>Terminals</title>

<para>
This section applies whenever you run DOSEMU remotely or in an xterm.
Color terminal support is now built into DOSEMU.  Skip this section for
now to use terminal defaults, until you get DOSEMU to work.
</para>

<para>
There are a number of keywords for the terminal { } configuration line.
</para>

<para>
<variablelist>

<varlistentry>
<term>color</term>
<listitem>
<para>
Enable or disable color terminal support. One of ``on'' (default) or 
``off''.
</para>
</listitem></varlistentry>
<varlistentry>
<term>updatefreq</term>
<listitem>
<para>
A number indicating the frequency of terminal updates of the screen.
The smaller the number, the more frequent.  A value of 20 gives a
frequency of about one per second, which is very slow.  However, more
CPU time is given to DOS applications when updates are less frequent.
A value of 4 (default) is recommended in most cases, but if you have a 
fast system or link, you can decrease this to 0.
</para>
</listitem></varlistentry>
<varlistentry>
<term>escchar</term>
<listitem>
<para>
A number (ascii code below 32) that specifies the control character
used as a prefix character for sending alt, shift, ctrl, and function
keycodes.  The default value is 30 which is Ctrl-^. So, for example,

<screen>
  F1 is 'Ctrl-^1', Alt-F7 is 'Ctrl-^s Ctrl-^7'.
  For online help, press 'Ctrl-^h' or 'Ctrl-^?'.
</screen>

</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>
Use the following to enable the IBM character set.
</para>

<para>

<screen>
  terminal { charset ibm  color on }
</screen>

</para>

<para>
Use this for color xterms or rxvt's with no IBM font, with only 8 colors.
</para>

<para>

<screen>
  terminal { charset latin  color on }
</screen>

</para>

<para>
Use this for color xterms or rxvt's with IBM font, with only 8 colors.
</para>

<para>

<screen>
  terminal { charset ibm  color on }
</screen>

</para>

<para>
More detailed line for user configuration:
</para>

<para>

<screen>
  terminal { charset latin  updatefreq 4  color on }
</screen>

</para>

</sect3>

<sect3>
<title>X Support settings</title>

<para>
If DOSEMU is running in its own X-window (not xterm), you may need
to tailor it to your needs. Valid keywords for the X { } config line:
</para>

<para>
<variablelist>

<varlistentry>
<term>updatefreq</term>
<listitem>
<para>
A number indicating the frequency of X updates of the screen.
The smaller the number, the more frequent.  A value of 20 gives a
frequency of about one per second, which is very slow.  However, more
CPU time is given to DOS applications when updates are less frequent.
The default is 8.
</para>
</listitem></varlistentry>
<varlistentry>
<term>display</term>
<listitem>
<para>
The X server to use. If this is not specified, dosemu will use
the DISPLAY environment variable. (This is the normal case) The default
is ":0".
</para>
</listitem></varlistentry>
<varlistentry>
<term>title</term>
<listitem>
<para>
What you want dosemu to display in the title bar of its window.
The default is "dosemu".
</para>
</listitem></varlistentry>
<varlistentry>
<term>icon_name</term>
<listitem>
<para>
Used when the dosemu window is iconified. The default is "dosemu".
</para>
</listitem></varlistentry>
<varlistentry>
<term>keycode</term>
<listitem>
<para>
Used to give Xdos access to keycode part of XFree86. The default is off.
</para>

<para>
<emphasis>NOTE:</emphasis>

<itemizedlist>
<listitem>

<para>
 You should _not_ use this when using X remotely
(the remote site may have other raw keyboard settings).
</para>
</listitem>
<listitem>

<para>
 <emphasis>If</emphasis> you use "keycode", you also <emphasis>must</emphasis> define an 
appropriate keyboard layout (see above).
</para>
</listitem>
<listitem>

<para>
 If you do <emphasis>not</emphasis> use "keycode" then under X a neutral keyboard
layout is forced ( <literal remap="tt">keyboard {layout us}</literal> ) regardless of
what you have set above.
</para>
</listitem>

</itemizedlist>

Anyway, a cleaner way than using "keycode" is to let the X-server
fiddle with keyboard translation and customize it via .xmodmaps.
</para>
</listitem></varlistentry>
<varlistentry>
<term>blinkrate</term>
<listitem>
<para>
A number which sets the blink rate for the cursor. The default is 8.
</para>
</listitem></varlistentry>
<varlistentry>
<term>font</term>
<listitem>
<para>
Used to pick a font other than vga (default). Must be monospaced.
</para>
</listitem></varlistentry>
<varlistentry>
<term>mitshm</term>
<listitem>
<para>
Use shared memory extensions. The default is ``on''.
</para>
</listitem></varlistentry>
<varlistentry>
<term>sharecmap</term>
<listitem>
<para>
Used to share the colormap with other applications in graphics mode.
If not set, a private colormap is used. The default is off.
</para>
</listitem></varlistentry>
<varlistentry>
<term>fixed_aspect</term>
<listitem>
<para>
Set fixed aspect for resize the graphics window. One of ``on'' (default)
or ``off''.
</para>
</listitem></varlistentry>
<varlistentry>
<term>aspect_43</term>
<listitem>
<para>
Always use an aspect ratio of 4:3 for graphics. The default is 
``floating''.
</para>
</listitem></varlistentry>
<varlistentry>
<term>lin_filt</term>
<listitem>
<para>
Use linear filtering for &gt;15 bpp interpolation. The default is off.
</para>
</listitem></varlistentry>
<varlistentry>
<term>bilin_filt</term>
<listitem>
<para>
Use bi-linear filtering for &gt;15 bpp interpolation. The default is off.
</para>
</listitem></varlistentry>
<varlistentry>
<term>mode13fact</term>
<listitem>
<para>
A number which sets the initial size factor for video mode 0x13 (320x200).
The default is 2.
</para>
</listitem></varlistentry>
<varlistentry>
<term>winsize</term>
<listitem>
<para>
A pair of numbers which set the initial width and height of the window to a fixed 
value. The default is to float.
</para>
</listitem></varlistentry>
<varlistentry>
<term>gamma</term>
<listitem>
<para>
Set value for gamma correction, a value of 100 means gamma 1.0. The default
is 100.
</para>
</listitem></varlistentry>
<varlistentry>
<term>vgaemu_memsize</term>
<listitem>
<para>
Set the size (in Kbytes) of the frame buffer for emulated vga under X. The
default is 1024.
</para>
</listitem></varlistentry>
<varlistentry>
<term>lfb</term>
<listitem>
<para>
Enable or disable the linear frame buffer in VESA modes. The default is ``on''.
</para>
</listitem></varlistentry>
<varlistentry>
<term>pm_interface</term>
<listitem>
<para>
Enable or disable the protected mode interface for VESA modes. The default is ``on''.
</para>
</listitem></varlistentry>
<varlistentry>
<term>mgrab_key</term>
<listitem>
<para>
String, name of KeySym name to activate mouse grab. Default is `empty'
(no mouse grab). A possible value could be "Home".
</para>
</listitem></varlistentry>
<varlistentry>
<term>vesamode</term>
<listitem>
<para>
Define a VESA mode. Two variants are supported: vesamode width height
and vesamode width height color_bits. The first adds the specified
resolution in all supported color depths (currently 8, 15, 16, 24 and 32
bit).
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>
Recommended X statement:
</para>

<para>

<screen>
  X { updatefreq 8 title "DOS in a BOX" icon_name "xdos" }
</screen>

</para>

</sect3>

<sect3>
<title>Video settings ( console only )</title>

<para>
<emphasis>!!WARNING!!: A LOT OF THIS VIDEO CODE IS ALPHA!  IF YOU ENABLE GRAPHICS
ON AN INCOMPATIBLE ADAPTOR, YOU COULD GET A BLANK SCREEN OR MESSY SCREEN
EVEN AFTER EXITING DOSEMU.  JUST REBOOT (BLINDLY) AND THEN MODIFY CONFIG.</emphasis>
</para>

<para>
Start with only text video using the following line, to get started.
then when DOSEMU is running, you can set up a better video configuration.
</para>

<para>

<screen>
  video { vga }                    Use this line, if you are using VGA
  video { cga  console }           Use this line, if you are using CGA
  video { ega  console }           Use this line, if you are using EGA
  video { mda  console }           Use this line, if you are using MDA
</screen>

</para>

<para>
Notes for Graphics:

<itemizedlist>
<listitem>

<para>
 If your VGA-Bios resides at E000-EFFF, turn off video BIOS shadow
for this address range and add the statement vbios_seg 0xe000
to the correct vios-statement, see the example below
</para>
</listitem>
<listitem>

<para>
 If your VBios size is only 32K you set it with  vbios_size 0x8000,
you then gain some space for UMB or hardware ram locations.
</para>
</listitem>
<listitem>

<para>
 Set "allowvideoportaccess on" earlier in this configuration file
if DOSEMU won't boot properly, such as hanging with a blank screen,
beeping, leaving Linux video in a bad state, or the video card
bootup message seems to stick.
</para>
</listitem>
<listitem>
<para>
 Video BIOS shadowing (in your CMOS setup) at C000-CFFF must be disabled.
</para>

<para>
<emphasis>CAUTION:</emphasis> TURN OFF VIDEO BIOS SHADOWING BEFORE ENABLING GRAPHICS!
This is not always necessary, but a word to the wise
shall be sufficient.
</para>
</listitem>
<listitem>
<para>
 If you have a dual-monitor configuration (e.g. MDA as second display),
you then may run CAD programs on 2 displays or let play your debugger
on the MDA while debugging a graphics program on the VGA (e.g TD -do ).
You also may switch to the MDA display by using the DOS command
mode mono (mode co80 returns to your normal display).
This feature can be enabled by the switch "dualmon" like this:

<screen>
      video { vga  console  graphics dualmon }
</screen>

and can be used on a xterm and the console, but of course not, if you
have the MDA as your primary display.
You also must set USE_DUALMON 1 in include/video.h.
<emphasis>NOTE:</emphasis> Make sure no more then one process is using this feature !
( you will get funny garbage on your MDA display. )
Also, you must NOT have the dualmon-patches for kernel applied
( having the MDA as Linux console )
</para>
</listitem>
<listitem>
<para>
 If you want to run dosemu in situations when human doesn't sit at console
(for instance to run it by cron) and want console option be enabled
you should use option forcevtswitch.

<screen>
           { vga console forcevtswitch }
</screen>

Without the option dosemu waits for becoming virtual terminal
on which dosemu is run active (i.e. user must press Alt-F?).
With this option dosemu perform the switch itself.
Be careful with this option because with it user sat at console
may face with unexpected switch.
</para>
</listitem>

</itemizedlist>

</para>

<para>
It may be necessary to set this to "on" if DOSEMU can't boot up properly
on your system when it's set "off" and when graphics are enabled.
<emphasis>Note:</emphasis> May interfere with serial ports when using certain video boards.
</para>

<para>

<screen>
  allowvideoportaccess on
</screen>

</para>

<para>
Any 100% compatible standard VGA card <emphasis>MAY</emphasis> work with this:
</para>

<para>

<screen>
  video { vga  console  graphics }
</screen>

</para>

<para>
If your VGA-BIOS is at segment E000, this may work for you:
</para>

<para>

<screen>
  video { vga  console  graphics  vbios_seg 0xe000 }
</screen>

</para>

<para>
Trident SVGA with 1 megabyte on board
</para>

<para>

<screen>
  video { vga  console  graphics  chipset trident  memsize 1024 }
</screen>

</para>

<para>
Diamond SVGA (not S3 chip)
</para>

<para>

<screen>
  video { vga  console  graphics  chipset diamond }
</screen>

</para>

<para>
Cirrus SVGA
</para>

<para>

<screen>
  video { vga  console  graphics  chipset cirrus }
</screen>

</para>

<para>
ET4000 SVGA card with 1 megabyte on board:
</para>

<para>

<screen>
  video { vga  console  graphics  chipset et4000  memsize 1024 }
</screen>

or

<screen>
  video { vga  console  graphics  chipset et4000  memsize 1024 vbios_size 0x8000 }
</screen>

</para>

<para>
S3-based SVGA video card with 1 megabyte on board:
</para>

<para>

<screen>
  video { vga  console  graphics  chipset s3  memsize 1024 }
</screen>

</para>

<para>
Avance Logic (ALI) 230x SVGA
</para>

<para>

<screen>
  video { vga  console  graphics  chipset avance }
</screen>

</para>

<para>
For ATI graphic mode
</para>

<para>

<screen>
  ports { 0x1ce 0x1cf 0x238 0x23b 0x23c 0x23f 0x9ae8 0x9ae9 0x9aee 0x9aef }
</screen>

</para>

<para>
Matrox millenium:
</para>

<para>

<screen>
  video { vga  console  graphics  chipset matrox }
</screen>

</para>

<para>
VGA-cards with a WD(Paradise) chip:
</para>

<para>

<screen>
  video { vga  console  graphics  chipset wdvga }
</screen>

</para>

</sect3>

<sect3>
<title>Memory settings</title>

<para>
These are memory parameters, stated in number of kilobytes.
If you get lots of disk swapping while DOSEMU runs, you should
reduce these values.
</para>

<para>
umb_max is a new parameter which tells DOSEMU to be more aggressive
about finding upper memory blocks.  The default is 'off'.
</para>

<para>
To be more aggressive about finding XMS UMB blocks use this:
</para>

<para>

<screen>
  umb_max on
</screen>

</para>

<para>
To be more secure use 'secure on'. If "on", then it disables DPMI access
to dosemu code and also disables execution of dosemu supplied 'system'
commands, which may execute arbitrary Linux-commands otherwise.
The background is, that DPMI clients are allowed to create selectors
that span the whole user space, hence may hack into the dosemu code,
and (when dosemu runs root or is suid root) can be a security hole.
"secure on" closes this hole, though this would very likely also disable
some dos4gw games :(.
Therfore <emphasis>NOTE:</emphasis> You may not be able to run some DPMI programs, hence,
before reporting such a program as 'not running', first try to set 'secure off'.
</para>

<para>

<screen>
  secure on                # "on" or "off"
</screen>

</para>

<para>
The below enables/disables DPMI and sets the size of DPMI memory.
</para>

<para>

<screen>
  dpmi 4086                # DPMI size in K, or "off"
</screen>

</para>

<para>
The best solution (security wise), however, is to run dosemu <emphasis>non-suid root</emphasis>
under X (which is possible since dosemu-0.97.10). Under X most of the
things we would need to run under root privilidges aren't needed, as the
X server supports them. And giving DPMI access to non-suid root dosemu
is <emphasis>not</emphasis> at all critical. You may forbid some users to use an eventually
available suid root binary by setting `nosuidroot' in /etc/dosemu.users.
</para>

<para>
XMS is enabled by the following statement
</para>

<para>

<screen>
  xms 1024		   # XMS size in K,  or "off"
</screen>

</para>

<para>
For ems, you now can set the frame to any 16K between 0xc800..0xe000
</para>

<para>

<screen>
  ems 1024		   # EMS size in K,  or "off"
</screen>

or

<screen>
  ems { ems_size 1024 ems_frame 0xe000 }
</screen>

or

<screen>
  ems { ems_size 2048 ems_frame 0xd000 }
</screen>

</para>

<para>
If you have adapters, which have memory mapped IO, you may map those regions
with <literal remap="tt">hardware_ram { .. }</literal>. You can only map in entities of 4k, you give the
address, not the segment.
The entry below maps 0xc8000..0xc8fff and 0xcc000..0xcffff:
</para>

<para>

<screen>
  hardware_ram { 0xc8000 range 0xcc000 0xcffff }
</screen>

</para>

<para>
With the entry below you define the maximum conventional RAM to show apps:
</para>

<para>

<screen>
  dosmem 640
</screen>

</para>

</sect3>

<sect3>
<title>IRQ passing</title>

<para>
The irqpassing statement accepts IRQ values between 3..15,
if using the { .. } syntax each value or range can be prefixed
by the keyword use_sigio to monitor the IRQ via SIGIO.
If this is missing the IRQ is monitored by SIGALRM.
</para>

<para>
Use/modify one of the below statements
</para>

<para>

<screen>
  irqpassing off    # this disables IRQ monitoring
  irqpassing 15
  irqpassing { 15 }
  irqpassing { use_sigio 15 }
  irqpassing { 10  use_sigio range 3 5 }
</screen>

</para>

</sect3>

<sect3>
<title>Port Access</title>

<para>
<emphasis remap="bf">WARNING: GIVING ACCESS TO PORTS IS BOTH A SECURITY CONCERN AND
SOME PORTS ARE DANGEROUS TO USE.  PLEASE SKIP THIS SECTION, AND
DON'T FIDDLE WITH THIS SECTION UNLESS YOU KNOW WHAT YOU'RE DOING.</emphasis>
</para>

<para>
These keywords are allowable on a "ports" line.
</para>

<para>
<variablelist>

<varlistentry>
<term>range <literal remap="tt">addr1 addr2</literal> </term>
<listitem>
<para>
This allows access to this range of ports
</para>
</listitem></varlistentry>
<varlistentry>
<term>ormask <literal remap="tt">value</literal> </term>
<listitem>
<para>
The default is 0
</para>
</listitem></varlistentry>
<varlistentry>
<term>andmask <literal remap="tt">value</literal></term>
<listitem>
<para>
The default is 0xffff
</para>
</listitem></varlistentry>
<varlistentry>
<term>rdonly|wronly|rdwr</term>
<listitem>
<para>
This specifies what kind of access to allow to the ports. The default
is "rdwr"
</para>
</listitem></varlistentry>
<varlistentry>
<term>fast</term>
<listitem>
<para>
Put port(s) in the ioperm bitmap (only valid for ports below 0x400)
An access doesn't trap and isn't logged, but as vm86() isn't interrupted, 
it's much faster. The default is not fast.
</para>
</listitem></varlistentry>
<varlistentry>
<term>device <literal remap="tt">name</literal> </term>
<listitem>
<para>
If the ports are registered, open this device to block access. The open()
must be successfull or access to the ports will be denied. If you know 
what you are doing, use <literal remap="tt">/dev/null</literal> to fake a device to block
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>

<screen>
  ports { 0x388 0x389 }   # for SimEarth
  ports { 0x21e 0x22e 0x23e 0x24e 0x25e 0x26e 0x27e 0x28e 0x29e } # for jill
</screen>

</para>

</sect3>

<sect3>
<title>Speaker</title>

<para>
These keywords are allowable on the "speaker" line:
</para>

<para>
<variablelist>

<varlistentry>
<term>native</term>
<listitem>
<para>
      Enable DOSEMU direct access to the speaker ports.
</para>
</listitem></varlistentry>
<varlistentry>
<term>emulated</term>
<listitem>
<para>
    Enable simple beeps at the terminal.
</para>
</listitem></varlistentry>
<varlistentry>
<term>off</term>
<listitem>
<para>
         Disable speaker emulation.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>
Recommended:
</para>

<para>

<screen>
  speaker off
</screen>

</para>

</sect3>

<sect3>
<title>Hard disks</title>

<para>
<emphasis remap="bf">WARNING: DAMAGE MIGHT RESULT TO YOUR HARD DISK (LINUX AND/OR DOS)
IF YOU FIDDLE WITH THIS SECTION WITHOUT KNOWING WHAT YOU'RE DOING!</emphasis>
</para>

<para>
The best way to get started with DOSEMU is to use use the bootdisk method
(see doc/README.txt, chapter "Disks, boot directories and floppies").
Fiddling with hdimages and real harddisk is obsolete now.
</para>

<para>
As a last resort, if you want DOSEMU to be able to access a DOS partition, the
safer type of access is "partition" access, because "wholedisk"
access gives DOSEMU write access to a whole physical disk,
including any vulnerable Linux partitions on that drive!
</para>

<para>
<emphasis>IMPORTANT</emphasis>
</para>

<para>
You must not have LILO installed on the partition for dosemu to boot off.
As of 04/26/94, doublespace and stacker 3.1 will work with wholedisk
or partition only access.  Stacker 4.0 has been reported to work with
wholedisk access.
</para>

<para>
Please read the documentation in the "doc" subdirectory for info
on how to set up access to real hard disk.
</para>

<para>
These are meanings of the keywords:
</para>

<para>
<variablelist>

<varlistentry>
<term>image</term>
<listitem>
<para>
 specifies a hard disk image file.
</para>
</listitem></varlistentry>
<varlistentry>
<term>partition</term>
<listitem>
<para>
 specifies partition access, with device and partition number.
</para>
</listitem></varlistentry>
<varlistentry>
<term>wholedisk</term>
<listitem>
<para>
 specifies full access to entire hard drive.
</para>
</listitem></varlistentry>
<varlistentry>
<term>readonly</term>
<listitem>
<para>
 for read only access.  A good idea to set up with.
</para>
</listitem></varlistentry>
<varlistentry>
<term>diskcyl4096</term>
<listitem>
<para>
 INT13 support for more then 1024 cylinders, bits 6/7 of
DH (head) used to build a 12 bit cylinder number.
</para>
</listitem></varlistentry>
<varlistentry>
<term>bootfile</term>
<listitem>
<para>
 to specify an image of a boot sector to boot from.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>
Use/modify one (or more) of the folling statements:
</para>

<para>

<screen>
  disk { image "/var/lib/dosemu/hdimage" }      # use diskimage file.
  disk { partition "/dev/hda1" readonly }       # 1st partition on 1st IDE.
  disk { partition "/dev/hda1" bootfile "/var/lib/bootsect.dos" }
                                                # 1st partition on 1st IDE
                                                # booting from the specified
                                                # file.
  disk { partition "/dev/hda6" readonly }       # 6th logical partition.
  disk { partition "/dev/sdb1" readonly }       # 1st partition on 2nd SCSI.
  disk { wholedisk "/dev/hda" }                 # Entire disk drive unit
</screen>

</para>

<para>
Recommended:
</para>

<para>

<screen>
  disk { image "/var/lib/dosemu/hdimage" }
</screen>

</para>

</sect3>

<sect3>
<title>DOSEMU boot</title>

<para>
Use the following option to boot from the specified file, and then
once booted, have bootoff execute in autoexec.bat. Thanks Ted :-).
Notice it follows a typical floppy spec. To create this file use:
</para>

<para>

<screen>
dd if=/dev/fd0 of=/var/lib/dosemu/bdisk bs=16k
</screen>

</para>

<para>

<screen>
  bootdisk { heads 2 sectors 18 tracks 80 threeinch file /var/lib/dosemu/bdisk }
</screen>

</para>

<para>
Specify extensions for the CONFIG and AUTOEXEC files.  If the below
are uncommented, the extensions become CONFIG.EMU and AUTOEXEC.EMU.
NOTE: this feature may affect file naming even after boot time.
If you use MSDOS 6+, you may want to use a CONFIG.SYS menu instead.
</para>

<para>

<screen>
  EmuSys EMU
  EmuBat EMU
</screen>

</para>

</sect3>

<sect3>
<title>Floppy disks</title>

<para>
This part is fairly easy.  Make sure that the first (/dev/fd0) and
second (/dev/fd1) floppy drives are of the correct size, "threeinch"
and/or "fiveinch".  A floppy disk image can be used instead, however.
</para>

<para>
<emphasis remap="bf">FOR SAFETY, UNMOUNT ALL FLOPPY DRIVES FROM YOUR FILESYSTEM BEFORE
STARTING UP DOSEMU!  DAMAGE TO THE FLOPPY MAY RESULT OTHERWISE!</emphasis>
</para>

<para>
Use/modify one of the below:
</para>

<para>

<screen>
  floppy { device /dev/fd0 threeinch }
  floppy { device /dev/fd1 fiveinch }
  floppy { heads 2  sectors 18  tracks 80
           threeinch  file /var/lib/dosemu/diskimage }
</screen>

</para>

<para>
If floppy disk speed is very important, uncomment the following
line.  However, this makes the floppy drive a bit unstable.  This
is best used if the floppies are write-protected.
Use an integer value to set the time between floppy updates.
</para>

<para>

<screen>
  FastFloppy 8
</screen>

</para>

</sect3>

<sect3>
<title>Printers</title>

<para>
Printer is emulated by piping printer data to a file or via a unix
command such as "lpr".  Don't bother fiddling with this configuration
until you've got DOSEMU up and running already.
</para>

<para>
NOTE: Printers are assigned to LPT1:, LPT2:, and LPT3: on a one for
one basis with each line below.  The first printer line is assigned
to LPT1:, second to LPT2:, and third to LPT3:.  If you do not specify
a base port, the emulator will setup the bios to report 0x378, 0x278,
and 0x3bc for LPT1:, LPT2:, and LPT3: respectively.
</para>

<para>
To use standard unix lpr command for printing use this line:
</para>

<para>

<screen>
  printer { options "%s"  command "lpr"  timeout 20 }
</screen>

</para>

<para>
And for any special options like using pr to format files,
add it to the options parameter:
</para>

<para>

<screen>
  printer { options "-p %s"  command "lpr"  timeout 10 }     pr format it
</screen>

</para>

<para>
To just have your printer output end up in a file, use the following line:
</para>

<para>

<screen>
  printer { file "lpt3" }
</screen>

</para>

<para>
If you have a DOS application that is looking to access the printer
port directly, and uses the bios LPT: setting to find out the port to use,
you can modify the base port the bios will report with the following:
</para>

<para>

<screen>
  printer { options "%s"  command "lpr"  base 0x3bc }
</screen>

</para>

<para>
Be sure to also add a port line to allow the application access to
the port:
</para>

<para>

<screen>
  ports { device /dev/lp0 0x3bc 0x3bd 0x3be }
</screen>

</para>

<para>
NOTE: applications that require this will not interfere with applications
that continue to use the standard bios calls.  These applications will
continue to send the output piped to the file or unix command.
</para>

</sect3>

<sect3>
<title>Sound</title>

<para>
The sound driver is more or less likely to be broken at the moment.
</para>

<para>
<variablelist>

<varlistentry>
<term>sb_base</term>
<listitem>
<para>
  base address of the SB (HEX)
</para>
</listitem></varlistentry>
<varlistentry>
<term>sb_irq</term>
<listitem>
<para>
 IRQ for the SB
</para>
</listitem></varlistentry>
<varlistentry>
<term>sb_dma</term>
<listitem>
<para>
 DMA channel for the SB
</para>
</listitem></varlistentry>
<varlistentry>
<term>sb_dsp</term>
<listitem>
<para>
 Path the sound device
</para>
</listitem></varlistentry>
<varlistentry>
<term>sb_mixer</term>
<listitem>
<para>
 path to the mixer control
</para>
</listitem></varlistentry>
<varlistentry>
<term>mpu_base</term>
<listitem>
<para>
 base address for the MPU-401 chip (HEX) (Not Implemented)
</para>
</listitem>
</varlistentry>
</variablelist>
</para>

<para>
Use this to disable sound support even if it is configured in
</para>

<para>

<screen>
  sound_emu off
</screen>

</para>

<para>
Linux defaults
</para>

<para>

<screen>
  sound_emu { sb_base 0x220 sb_irq 5 sb_dma 1 sb_dsp /dev/dsp
               sb_mixer /dev/mixer mpu_base 0x330 }
</screen>

</para>

<para>
NetBSD defaults
</para>

<para>

<screen>
  sound_emu { sb_base 0x220 sb_irq 5 sb_dma 1 sb_dsp /dev/sound
              sb_mixer /dev/mixer mpu_base 0x330 }
</screen>

</para>

</sect3>

</sect2>

</sect1>

