user.dbk

bochs

        <entry>Description</entry>
      </row>
    </thead>
    <tbody>
      <row>
        <entry>?</entry>
        <entry>unknown</entry>
        <entry>
        This file is in your bochs directory, but CVS does not know anything
        about it.  For example, when you compile Bochs, any files created
        during the build process appear as ?.
        </entry>
      </row>
      <row>
        <entry>U</entry>
        <entry>update</entry>
        <entry>
        cvs downloaded a new version of this file because it changed on the
        server, usually because someone else did a checkin.
        </entry>
      </row>
      <row>
        <entry>P</entry>
        <entry>-</entry>
        <entry>
        P is the same as U, as far as I can tell
        </entry>
      </row>
      <row>
        <entry>M</entry>
        <entry>modified</entry>
        <entry>
        You have changed this file on your disk, so it no longer matches the
        version on the server.  This is not a problem; it's just for your 
        information.  If you want, you can discard your changes and
        get a fresh copy by deleting the file and running cvs update again.
        </entry>
      </row>
      <row>
        <entry>C</entry>
        <entry>conflict</entry>
        <entry>
        You have changed this file on your disk, but this change conflicts with
        a change that was checked in.  Conflicts occur when two people change
        the same line of code in different ways.  You need to edit the
        conflicting file(s) and clean it up by hand.  Or, sometimes it's
        easiest to discard your own edits and download a fresh copy, by
        deleting the conflicting file and running cvs update again.
        </entry>
      </row>
    </tbody>
   </tgroup>
</table>
</para>

<para>
If you have been using <command>cvs update</command> with "sticky tags" to
retrieve other versions, as described later, cvs will remember which version
you were looking at.  In this case, a <command>cvs update</command> will keep
your sources consistent with that version.  If you want to get back to looking
at the latest code again, be sure to use the <command>-A</command> option to
clears the sticky tags.  </para>

</section>

<section id="cvs-release-version"><title>Getting a Release Version</title>
<para>
Once you have a CVS checkout, you can also use the update command to
get the Bochs source code for any release since March 2000.  The command
is <command>cvs update -d -r <replaceable>tagname</replaceable></command>.
The tag tells which release you want, and it can be one of the following:

<table frame="all">
<title>CVS Release Tags</title>
  <tgroup cols="2">
    <thead>
      <row>
        <entry>Bochs version</entry>
        <entry>Release tag for CVS</entry>
      </row>
    </thead>
    <tbody>
      <row>
        <entry>1.4.1 (bugfix1)</entry>
        <entry>REL_1_4_1_FINAL</entry>
      </row>
      <row>
        <entry>1.4</entry>
        <entry>REL_1_4_FINAL</entry>
      </row>
      <row>
        <entry>1.3</entry>
        <entry>REL_1_3_FINAL</entry>
      </row>
      <row>
        <entry>1.2.1 (bugfix1)</entry>
        <entry>REL_1_2_1_FINAL</entry>
      </row>
      <row>
        <entry>1.2</entry>
        <entry>REL_1_2_FINAL</entry>
      </row>
      <row>
        <entry>1.1 (bugfix1)</entry>
        <entry>REL_1_1_BASE</entry>
      </row>
      <row>
        <entry>1.1.2 (bugfix3)</entry>
        <entry>REL_1_1_2_BASE</entry>
      </row>
      <row>
        <entry>1.1.1 (bugfix2)</entry>
        <entry>REL_1_1_1_BASE</entry>
      </row>
      <row>
        <entry>1.1 (bugfix1)</entry>
        <entry>REL_1_1_BASE</entry>
      </row>
      <row>
        <entry>March 25, 2000</entry>
        <entry>REL-bochs-2000-03-25</entry>
      </row>
    </tbody>
   </tgroup>
</table>

<tip>
<para>
To get a complete list of allowed tags, type <command>cvs stat -v README</command>.  Many of the tags are not generally useful.
</para>
</tip>

Once you have done an update with <command>-r <replaceable>tagname</replaceable></command>, you have made a "sticky tag."  The stickiness refers to the fact
that CVS remembers which tag you have used most recently.  The tag is stored
in the CVS subdirectory, so it stays around even if you log off and
return later.  After creating a sticky tag, any future cvs updates will
try to keep your directory in sync with the version you chose.  In other
words, when developers check in changes you will not
see them because your directory is "stuck" looking at an old version.
To clear the sticky tag, use <command>cvs update -A</command>.
</para>

<para>
A variation on the sticky tag concept is a sticky date<footnote>
<para>
According to some sources, this is when you eat dinner with someone, and
accidentally spill a drink on him/her.
</para>
</footnote>.  If some feature was working at some time in the past, but
is no longer working, you can ask CVS to give you the sources from any
date.  <command>cvs update -D 2001-06-14</command> will download the
Bochs source as they were on June 14, 2001.  Again, use <command>-A</command>
to clear the sticky date and track the current sources.
</para>
</section>

<section><title>More about CVS</title>
<para>
Entire books have been written on CVS, so there's no sense in duplicating
it all here in the Bochs documentation.  Some sources of additional
information are listed below.
</para>
<itemizedlist>
<listitem><para>The <ulink url="http://www.cvshome.org">cvshome.com
site</ulink> has tons of CVS FAQs and documentation, including the official CVS
manual by Per Cederqvist.</para></listitem>
<listitem><para>
Another <ulink url="http://www.cs.utah.edu/dept/old/texinfo/cvs/FAQ.txt">CVS FAQ</ulink> is available at University of Utah.
</para></listitem>
</itemizedlist>

</section>


</section> <!-- End of Installation:Getting the source code with CVS -->


<section id="install-binary"><title>Installing a Binary</title>

<para>
This section is divided up by platform, since installing a binary package
is different on different platforms.
</para>

<section><title>Windows</title>
<!--
unzip into some directory.  Look for DOC-win32.html
for more instructions.  Quick start: find dlxlinux/start.bat and
double click
-->
<para>
&FIXME;
Someone needs to write this.
</para>
</section> <!-- end of Installing a Binary:Windows -->

<section id="linuxrpm">
<title>Linux RPM</title>
<para>
RPM stands for "RedHat Package Manager."  An RPM is a compressed file
containing files to be installed on your system.  Many Linux distributions,
not just RedHat ones, can install files from an RPM.  First, download the
Bochs RPM for your architecture to your computer.  For example, if you have an
Intel-compatible computer, be sure to get the RPM that says "for Linux x86
distributions" or "i386".  Once you have the package on your local disk, you
should become the root user and install it as follows<footnote>
<para>
Many distributions have their own RPM installer program, often graphical, and
they should work ok.  It is helpful to be able to see the text output from
RPM, so if you use a fancy RPM installer, be sure to find the text output and
check that it looks correct.
</para>
</footnote>:

<figure><title>Installing an RPM in Linux</title>
<screen>
  user$ <command>su</command>
  Password: 
  root# <command>ls -l bochs-1.2.1.i386.rpm</command>
  -rw-rw-r--    1 user     user      1877515 Sep 14 09:02 bochs-1.2.1.i386.rpm
  root# <command>rpm -i bochs-1.2.1.i386.rpm</command>
  Looking for fonts to install... /usr/local/bochs/latest/
  Looking for X11 Font Path... /usr/lib/X11/fonts
  Installing vga.pcf... ok    (it was already there)
  Running mkfontdir...
  Done installing Bochs fonts for X11.
  root# exit
  user$ _
</screen>
</figure>
</para>

<para>
All RPM installations are done as the root user because they require
permission to update system files and directories.  If you do not have root
access you need to compile Bochs in your home directory.
</para>

<para>
RPM installation can fail for a few reasons.  It will fail if you already
have a Bochs package installed.  In this case, try upgrading the old package
to the new package with <command>rpm --upgrade NAME.i386.rpm</command>.
Another potential problem is missing RPM dependencies.  If you are getting
errors about missing files or RPMs, then first you should try to 
install the RPMs that provide the missing pieces.  If that cannot be done,
download the source RPM and build a new binary RPM that is appropriate
for your platform.  The command is <command>rpmbuild --rebuild
NAME.src.rpm</command>.  As a last resort, you can run rpm with the
<command>--nodeps</command> option to ignore dependencies and install it
anyway, but if it is missing important pieces it may not run properly.
</para>

<para>
The RPM installation is supposed to install the VGA font for you, if
necessary.  But if you are seeing errors like "Could not open vga font", then
please read <xref linkend="vgafont">.
</para>

<para>
The Bochs RPM installs three new commands and associated manual pages: bochs,
bochs-dlx, and bximage.  First, let's try out the DLX Linux demo by typing
<command>bochs-dlx</command>.  

<screen>
  user$ bochs-dlx
  ---------------------------------------------------------------
	      DLX Linux Demo, for Bochs x86 Emulator
  ---------------------------------------------------------------
  Checking for bochs binary...ok
  Checking for DLX linux directory...ok
  Checking for /bin/gzip...ok
  Checking for /usr/users/bryce/.bochsdlx directory...
  ---------------------------------------------------------------
  To run the DLX Linux demo, I need to create a directory called
  /usr/users/bryce/.bochsdlx, and copy some configuration files
  and a 10 megabyte disk image into the directory.
  ---------------------------------------------------------------
  Is that okay? [y/n]
  y
  Copying /usr/share/bochs/dlxlinux/bochsrc.txt -> /usr/users/bryce/.bochsdlx/.
  Copying /usr/share/bochs/dlxlinux/README -> /usr/users/bryce/.bochsdlx/.
  Copying /usr/share/bochs/dlxlinux/testform.txt -> /usr/users/bryce/.bochsdlx/.
  Uncompressing /usr/share/bochs/dlxlinux/hd10meg.img.gz -> /usr/users/bryce/.bochsdlx/hd10meg.img
  Entering /usr/users/bryce/.bochsdlx
  Running bochs
  ========================================================================
			Bochs x86 Emulator 2.0.pre3
		Build from CVS snapshot on December 4, 2002
  ========================================================================
</screen>

Then you get a new X11 window containing the VGA display of the simulated
machine.  First you see the VGA BIOS screen, then Linux uncompresses and
boots, and you get a login prompt.  Type "root" and ENTER to log in to
DLX linux.
<figure>
<title>Screenshot of Bochs running DLX Linux</title>
<graphic format="GIF" fileref="../images/dlxlinux-in-linux.gif">
</figure>
</para>

<para>
Booting is complete when you see "dlx login:" and a cursor.  At this login
prompt, type "root".  On UNIX systems, root is the system admin user.
There is no password for root on this sample disk image, so it lets you log 
in without typing any password.  Now you should see a UNIX prompt, and you 
can begin to type UNIX commands.
</para>

<screen>
  Welcome to DLX V1.0 (C) 1995-96 Erich Boehm
                      (C) 1995    Hannes Boehm

  dlx login: <command>root</command>
  Linux 1.3.89.
  dlx:~# <command>pwd</command>
  /root
  dlx:~# <command>cd /</command>
  dlx:~# <command>ls</command>
  bin/       etc/       lost+found/       root/       usr/
  boot/      fd/        mnt/              sbin/       var/
  dev/       lib/       proc/             tmp/        zip/
  dlx:/# <command>df</command>