user.dbk

Bochs这个虚拟机的源代码。学习虚拟机的编写和操作系统的编写有帮助。

  U bochs/patches/patch.seg-limit-real
  user$ <command>cd bochs</command>
  user$ <command>ls</command>
  Bochs.proj.hqx  bxversion.h   fpu/                osdep.cc
  CHANGES         config.h.in   gui/                osdep.h
  COPYING         configure*    install-x11-fonts*  patches/
  CVS/            configure.in  instrument/         pc_system.cc
  Makefile.in     cpu/          iodev/              pc_system.h
  README          bx_debug/     load32bitOShack.cc  state_file.cc
  TESTFORM.txt    disasm/       logio.cc            state_file.h
  bios/           doc/          macintosh.txt       win32.txt
  bochs.h         docs-html/    main.cc
  bochs.rsrc.hqx  dynamic/      memory/
  build/          font/         misc/
  user$ _
</screen>
</figure>
</para>


<tip>
<para>
If you have write access to the Bochs CVS tree, the checkout
command is different for you.  See the Developers Guide<footnote>
<para>
&FIXME; not written yet.  For now, look at http://sourceforge.net/cvs/?group_id=12580 for instructions. See "Developer CVS access using SSH."
</para>
</footnote> for details.
</para>
</tip>

<tip>
<para>
If you use remote CVS for other projects, you might have already set
the environment variable <varname>CVS_RSH</varname> in your configuration
files.  For the CVS checkout to work as shown above, the
<varname>CVS_RSH</varname> variable should either be empty or set to
<constant>rsh</constant>.
</para>
</tip>

<para>
The CVS checkout process (above) gives you a directory called bochs that
contains the very latest source code.  I will refer to this directory
as &bochsdir;.  In each subdirectory directory there's also a
directory called "CVS" which tells the cvs software where the code was checked
out, what version you have, and where to go for future updates.
</para>
</section>

<section><title>Getting the Latest Version</title>
<para>
Most developers use CVS to always give them the latest source code.  The minute
that any developer checks in a change, they are available to everyone else
through  CVS.  You just have to type <command>cvs update -d -A</command> in the
&bochsdir; directory, and CVS will retrieve any files and directories that have
been changed since you did a checkout.  If you update regularly, each update
takes a short time because it downloads only the files that changed.  The
<command>-d</command> option tells cvs to download new directories that
have been checked in, not just files.  The <command>-A</command> option means
to get the most recent version of each file, as opposed to a release version.
See <link linkend="cvs-release-version">Getting a release version</link>
Both <command>-d</command> and <command>-A</command> can be omitted in many
cases, once you are familiar with the process.  </para>

<para>
The <command>cvs update -A -d</command> command tells you if any new files have
been downloaded from the server, and it also tells you if you have modified any
of the CVS-controlled files.  As it checks through the source directories, it
will list files that have changed, with a single letter before the name that
tells the status of that file.  The most common status letters are listed
below.

<table frame="all">
<title>Status letters in a CVS update</title>
  <tgroup cols="3">
    <thead>
      <row>
        <entry>Letter</entry>
        <entry>Meaning</entry>
        <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>2.0.2 (bugfix2)</entry>
        <entry>REL_2_0_2_FINAL</entry>
      </row>
      <row>
        <entry>2.0.1 (bugfix1)</entry>
        <entry>REL_2_0_1_FINAL</entry>
      </row>
      <row>
        <entry>2.0</entry>
        <entry>REL_2_0_FINAL</entry>
      </row>
      <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.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>
<para>
The Bochs binaries for Windows are distributed in two different package types:
EXE and ZIP. Both package types contain all files you need to run Bochs. The EXE
version can be started like any other Windows program and it brings up the
installation wizard. Here you can select the destination folder and the
installation options. The wizard installs the files and creates the registry
keys, start menu and desktop links. We recommend to use the EXE package unless
you are a Bochs expert.
</para>
<para>
If you choose the ZIP package you need a tool like WinZip to unpack the archive.
Note that you have to create a registry key for Bochs if you want to use the
environment variable $BXSHARE in your config file. The name of the key is
"HKEY_LOCAL_MACHINE\Software\Bochs 2.1.pre3" (the Bochs version may differ).
For more information on environment variables see the section <link
linkend="bochsrc">bochsrc</link>.
</para>
<para>
If you are new to Bochs you should try out the DLX Linux demo distributed with
Bochs. The installation wizard has created a link on the desktop if you decided
to install the demo. If you doubleclick the icon two windows will appear:
one is the Bochs Display window, and the other is text window that is used for
the runtime configuration and for log messages if no logfile is specified.
</para>
<para>
You can find more information on the DLX Linux demo in the next section below the
DLX Linux screenshot.
</para>

<table><title>Files in Bochs directory (Windows version)</title>
<tgroup cols="2" align="left" colsep="1" rowsep="1">
<thead> <row> <entry>File</entry> <entry>Description</entry> </row>
</thead>
<tbody>

<row><entry>BIOS-bochs-* </entry> <entry> ROM BIOS images for Bochs.  Normally you would only use BIOS-bochs-latest unless you are simulating multiple processors. </entry> </row>
<row><entry>bochs.exe </entry> <entry> the main Bochs executable </entry> </row>
<row><entry>bochs.ico </entry> <entry> the Bochs icon (used for links in start menu and on the desktop) </entry> </row>
<row><entry>bochsdbg.exe </entry> <entry> the main Bochs executable with debugger enabled </entry> </row>
<row><entry>bochsrc-sample.txt </entry> <entry> sample Bochs configuration file </entry> </row>