Bochs/bochs/doc/docbook/misc.txt

$Id: misc.txt,v 1.25 2003-05-03 16:39:35 cbothamy Exp $

This is a temporary place to paste in stuff that should go into the docs one
day.  When it is transferred into docbook, let's remove it from misc.txt.

--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Date: Thu, 15 Nov 2001 13:31:34 -0800
From: David Christy <davidc@davidc.biz>
To: bryce@tlw.com
Subject: usefull info for mounting 


I didn't see this in the doc's so I thought you might like a
short description of how to mount a disk image file into
loopback filesystem for maintenance purposes.

--------------------------------------------

1) First run

fdisk -l <image_name>

... and it should print out a partition table (with a few
complaints requesting the drive geometry, and I don't know
if older versions require a block device) In fact fdisk will
even work to modify partitions in an image, but you must
specify the drive geometry that's in the bocsrc first.

2) Whatever it says the starting partition is, subtract 1
and multiply by 512

3) Type

mount -o loop,offset=<insert number here> <image_name>
/mount/dir

or if it's just a floppy image, just

mount -o loop floppy.img /mount/dir

---------------------------------------------------

I would recommend putting -o ro for read only access if
bochs is in use.  For unusual filesystems you may need to
add a -t <fstype> flag to the mount command to specify the
filesystem type.

see man mount, losetup, and fdisk for more info



BOCHS Rocks!!!



-------------macintosh.txt-----------------
BBD Mon Nov 25 08:23:28 EST 2002
This file has been in our main directory for years and years, and has not
been updated since nobody has tried to compile for MacOS pre-10 in a long
time.  I didn't want to leave it sitting there since it is so incredibly
obsolete.  I think it would be good to put it into the documentation
with proper warnings about the fact that it hasn't been updated in 4 years
and may need significant hacking to make it work again.
------------------

Changes by Bryce Denney 4/5/2001:
I moved the contents of macutils.h into osdep.h, and macutils.c 
into osdep.cc.  There are functions missing on other platforms too, 
so I wanted to bring them all into the same place.

The original macintosh.txt follows.

STATUS OF THE MAC PORT:
-----------------------

23 Dec 1998

Contents:

	Status
	How to Set up MacBochs
	Problems
	Other Issues
	New Files
	Changed Files


Status
------

This is an experimental Macintosh port of Bochs. The Mac port compiles fine
under CodeWarrior Pro R1 (CW12) and is capable of booting Win95 in command-
line mode and running DOS programs. A CodeWarrior project ("Bochs.proj") is
included (you may need to edit the type and creator information with ResEdit
in order for CodeWarrior to recognise it as a project file).

NOTE: MacBochs is very much a "work in progress", and much of the code is
incomplete. This preliminary version is being made available mainly to
interested developers who may want to contribute to the development of
MacBochs by contributing some code or testing it on their own Macs.

If anyone can test with some "clean" Windows installer disks, it would be
useful. I've been testing MacBochs with my SoftWindows HD image and disk
images derived from it, and I'm not sure if the various SoftWindows-specific
drivers are interfering.

23 Dec 98 - updated MacBochs to bochs-981222. The new version seems
noticeably faster. Finished implementing the Bochs headerbar. Added support
for ejecting floppy disks from within Bochs (click the Drive A: icon on the
headerbar or press Cmd-E).

17 Dec 98 - added real floppy disk support. Also optimized the graphics
screen drawing a bit more. Keyboard support still broken and in need of a
major overhaul. Does anyone have experience with KCHR resources and
KeyTranslate()?


How to Set up MacBochs
----------------------

This is a very brief, step-by-step guide on setting up MacBochs. More
detailed documentation will be available later.

- Step 1. Compile the version of Bochs you want to use (PPC, 68k or FAT) or
obtain a pre-compiled binary. There is a CodeWarrior project included with
the source distribution.

- Step 2. Create a hard disk image.
Bochs ALWAYS needs a hard disk image available to it, otherwise it won't
boot. To create a hard disk image on the Mac, you need to use a recent
version of DiskCopy.

First, create an untitled, empty folder anywhere on your Mac hard disk. Then,
launch DiskCopy and choose to create a folder image of that folder.

DO NOT ENTER THE DISK SIZE IN MEGABYTES. In the file "install.html" in the
"docs-html" folder you will find a table of disk sizes and geometries. Make a
note of the number of total SECTORS required for your desired hard disk size,
as well as the cylinders, heads and sectors per track (spt).

In DiskCopy, you need to choose "Custom..." from the menu of image sizes, and
choose to enter the size in "blocks" (on the Mac, a block is pretty much the
same as a sector). Then enter the number of total sectors you need.

Make sure the image is "Read/Write", not "Read Only", and make sure you have
entered the correct cyl=, heads= and spt= settings in your bochsrc file. Your
image file should now be accessible to Bochs.

You'll eventually need to use a utility like "fdisk" to make the image
readable.

- Step 3. Obtain a bootable PC floppy or floppy image.
You'll need to install an operating system in order to do anything useful
with Bochs. If you have installer floppies for a PC operating system (eg.
Windows or MS-DOS) you can use those. Otherwise you can download disk images
for FreeDOS or one of the many variants of Linux.

MacBochs now supports real PC floppy disks. To use the Mac floppy drive
instead of a disk image, use the special filename "[fd:]" in the appropriate
line of your bochsrc.

- Step 4. Set up your bochsrc file.
You set up your Bochs preferences by editing the "bochsrc" file. You'll need
to set up your bochsrc to work with your floppy and hard disk images, as well
as telling Bochs how many megs of PC RAM you want.

Problems
--------

There are some so far unresolved problems in the "macintosh.cc" GUI file:

- Keyboard support is VERY rudimentary; ie. it only supports alphanumerics
and a couple of special keys like Enter. The keyboard-related code is full of
holes and I'm going to completely rehash it.

- Mouse support hasn't been tested, but probably isn't fully working either.


Other Issues
------------

- The Mac port uses a ready-made config file (configmac.h), like the Win32
port used to. Macs are pretty homogeneous, so the settings should be
appropriate for most machines.

- The Mac port has an extra source file: "macutils.c" (with header file
"macutils.h"), which is used for Mac floppy drive support, among other
things.

- Like the Win32 port, the Mac port expects the "bochsrc" file to be in the
same directory as the Bochs application.

- Be sure to use Mac pathname conventions when editing the bochsrc file (ie
':' instead of '/' or '\').


New files
---------

The following are new, Mac-specific files:

gui/macintosh.cc
configmac.h
macutils.h
macutils.c
Bochs.proj


Changed Files
-------------

The following files from the main bochs distribution have been modified to
compile properly on the Mac:

bochs.h
main.cc
memory/memory.cc
memory/misc_mem.cc
iodev/floppy.cc
iodev/harddrv.cc

The changes are just conditional compilations which won't affect other
platforms (search for "#ifdef macintosh" and "#ifndef macintosh" if you want
to see what the changes are). These changes will need to be integrated into
the main distribution if the MacOS port is going to go ahead seriously.

-- David Batterham <drbatter@socs.uts.edu.au> or <drbatter@yahoo.com>

--------------------win32.txt----------------------
BBD Mon Nov 25 08:27:24 EST 2002
The win32 build instructions are out of date too.  The --with-win32-vcpp
has been deprecated since at least March 2002.  More current instructions
are already in the docs, so this info may not be of much use.

Building Bochs for Win32
------------------------

This has only been tested with MS Visual C++ 6.0.

The normal build process on a unix system is to run configure to build all the
makefiles and config.h, and then run make to compile Bochs.  Configure takes a
large number of command line arguments, for example to disable floating point
or to enable sound blaster emulation.  Configure works beautifully on unix
systems to help make the code portable, however it cannot run on Windows.
(Maybe, if you have cygwin.)  Therefore, you need to either 1) run configure
on a unix box and copy the makefiles and config.h, or 2) download the
makefiles which are distributed in a separate ZIP file.

If you want to run configure yourself, consider using the shell script
".conf.win32-vcpp" since it has been tested.  Look at it to make sure
the options make sense for you.  You can always run configure by hand too,
just be sure to include the option --with-win32-vcpp so that it creates
makefiles for win32.  Copy config.h, Makefile, and the Makefiles in all
subdirectories over to your windows box into the same directory as the Bochs
source.

If you download the makefiles in a ZIP, just extract them into the
same directory as the Bochs source.  The config.h and top level Makefile
should end up in the same directory as Bochs.h.

Once the makefiles are installed, building Bochs is easy.  Start up an MSDOS
window, run the .BAT file that sets up the environment variables
(C:\vc98\bin\vcvars32.bat on my system), and then run NMAKE in the Bochs
source directory.  You will get lots of compile warnings, but hopefully no
fatal errors!  At the end, you should see Bochs.exe in the source directory.




--------------------------------------------------
Steps for building a Bochs release
Thu Dec  5 14:23:20  2002
Bryce Denney

Make sure that README and configure.in have the correct version number.
Run autoconf to regenerate configure and check them in.  Create a 
CVS tag to mark which revision of each file was used in the release.

For prereleases I make a normal CVS tag like this:
  cvs tag REL_2_0_pre3_FINAL

But for a real release, I make a CVS branch tag AND a normal tag.
  cvs tag REL_2_0_BASE
  cvs tag -b REL_2_0
The base tag marks where the branch split off of the main trunk.
This is very useful in maintaining the branch since you can do diffs
against it.
   cvs diff -r REL_2_0_BASE -r HEAD
   cvs diff -r REL_2_0_BASE -r REL_2_0
   cvs upd -j REL_2_0_BASE -j HEAD file
   etc.
The release and all bugfix releases after it are on the REL_2_0 branch.
When the release is actually finalized,
  cvs tag REL_2_0_FINAL

Building the release on win32.
These instructions require cygwin and MSVC++.

In Cygwin:
  sh .conf.win32-vcpp         # runs configure 
  make win32_snap             # unzip workspace, make a win32 source ZIP

Copy the source ZIP to a windows machine, if necessary.

Open up Visual C++ and load the workspace file Bochs.dsw.  Check
the Build:Set Active Project Configuration is set the way you want it.
For releases I use "Win32 Release".

make install_win32 prefix=/tmp/bochs-2.0.pre3

OPTIONAL: Build bochsdbg.exe.
|  To create "bochsdbg.exe" with Bochs debugger support, manually change two
|  lines in config.h to turn on the debugger.
|	#define BX_DEBUGGER 1
|	#define BX_DISASM 1
|
|  VC++ will rebuild bochs with debugger and overwrite bochs.exe.  To avoid
|  trashing the non-debug version, move it out of the way while the debugger
|  version is being built.  Then rename the debugger version to bochsdbg.exe.
|	cd obj-release
|	mv bochs.exe bochs-normal.exe
|	<<build again with BX_DEBUGGER=1 this time>>
|	mv bochs.exe bochsdbg.exe
|	mv bochs-normal.exe bochs.exe
+---

Do make install_win32 into /tmp or someplace.

make install_win32 prefix=/tmp/bochs-2.0.pre3
This copies all the files into /tmp/bochs-2.0.pre3 and then creates a
binary ZIP at /tmp/bochs-2.0.pre3.zip.  Rename that 
bochs-2.0.pre3.win32-bin.zip


NOTE: To get the docbook installed, you need to do  something like this
make dl_docbook
make install_win32 prefix=$PREFIX
make install_docbook prefix=$PREFIX docdir=$PREFIX/docs
make install_win32 prefix=$PREFIX

This will get cleaned up some day.  I did install_win32 twice because the
install_docbook target doesn't know to create $(prefix).  This can be fixed
pretty easily, but not right now.

Now make the NSIS installer package.
cd build/win32/nsis

Unzip the binary ZIP file into bochs-$VERSION (must match Makefile) and 
then run make.

unzip ~/bochs-2.0.pre3.zip
make

That gives an installer called 'Bochs-2.0.pre3.exe'.
Test and upload.

--------------
Building the release on Linux

Do a clean checkout using anonymous cvs, so that the source tarball
will be all set up for anonymous cvs.  First I'll create a clean
directory called "clean-anon".

cvs -d:pserver:anonymous@cvs.bochs.sourceforge.net:/cvsroot/bochs login
cvs -z3 -d:pserver:anonymous@cvs.bochs.sourceforge.net:/cvsroot/bochs \
  checkout -d clean-anon bochs

Start with clean-anon which tracks the CVS head.  Change its sticky tag
so that it sticks to the release tag.

cp -a clean-anon bochs-2.0.pre3
cd bochs-2.0.pre3
cvs upd -r REL_2_0_pre3_FINAL
cd ..
tar czvf bochs-2.0.pre3.tar.gz bochs-2.0.pre3

The source TAR file bochs-2.0.pre3.tar.gz is ready to upload.

The RPM will be building using the configuration in .conf.linux with
a few parameters from build/redhat/make-rpm.  Make any last minute changes
to .conf.linux.  Any changes will go into the source RPM.

./build/redhat/make-rpm | tee ../build.txt

This produces two rpm files in the current directory.  Test and upload.

------

<!-- *************************************************************** -->

Wed Dec 11 13:56:20 EST 2002
this text came from build/linux/DOC-linux.html.
Originally it was an intro to Bochs for Linux users.  I converted it all to
docbook.  I moved most of the info from DOC-linux.html into different
sections of the user guide, and the rest I put here in misc.txt.  Maybe these
paragraphs will be useful in some kind of introduction to something, or maybe
not.

<section><title>Quick Start for Linux users</title>
<!--much text removed, put into user guide -->

<para>
This file is an introduction to Bochs for Linux users.  It assumes that you
have just installed a Bochs binary distribution, and now you want to see what
Bochs can do!
</para>

<section><title>How can I try out Bochs in 10 minutes or less?</title>
<para>
This RPM package includes a sample disk image containing DLX Linux, which you
can boot within Bochs.  To start up DLX linux, just type "bochs-dlx" in an
xterm.  The first time it runs, it creates a disk image in a directory
called <filename>$HOME/.bochsdlx</filename>.  Then it creates a Bochs Display
window and prints some log messages into the xterm.  The display window is the
most interesting, but if something goes wrong the log messages should give an
idea of what has happened.
</para>
<para>
Meanwhile, the Bochs display screen should look like a PC booting...and in
fact it is!  Bochs begins simulating a PC from the time the power turns on.
You will see the VGA BIOS message, and it begins loading Linux from the disk
image.  The disk image is just a big file that Bochs uses as if it were a
real hard drive.  After a while, you see Linux boot messages and eventually a
login prompt.  You are now running DLX Linux in a window!
</para>
<para>
Bochs simulates every instruction of an x86 CPU, so it is very memory- and
compute-intensive.  The speed of your real CPU will make a big difference in
how fast the DLX Linux image boots.  On a 1GHz Pentium, the sample Linux 
image takes about 10 seconds to boot.
</para>

<para>
In this brief introduction you saw how Bochs can boot and run an x86 operating
system in a window.  It doesn't have to be Linux, of course!  Various people
have been able to install and run DOS, Windows 3.1, Windows 95/98/ME/NT/XP,
Linux, FreeBSD, NetBSD, OpenBSD, and probably others that we've never even
heard of.  In fact Bochs is used by many operating system developers to test
out their software in a controlled environment without having to reboot their
development machine.
</para>

<para>
If you are learning about Bochs for the first time, you might want to
download a few other prebuilt disk images of other operating systems from the
Bochs website.  They range from very small (1.44 meg floppy disk images) to
hundreds of megabytes.  Most disk images on the web site come with a
working configuration file (often called bochsrc.txt) so they should work
without much effort.  This will give you an idea of what Bochs can do,
and how it might be useful to you.
</para>

</section>

------------------------------------------
Windows 3.1 install hints

Date: Fri, 13 Dec 2002 09:56:48 -0700
From: Ben Lunt <fys@cybertrails.com>
To: bochs-devel <bochs-developers@lists.sourceforge.net>

I was playing with bochs a bit last night and successfully
got windows 3.1 installed on a c.img file and run with
almost no errors.

I first started with three original DOS 5.0 720k images,
FDISKed, FORMATed, and then install.

Then changed to seven 1_44m disks and installed Win16.
Each time either OS asked for a new disk, I simply
copied the expected image to a.img and continued.


------------------------------------------
WinNT4 guest network problems

From: Jeremy Wilkins <jeb at jeremywilkins.freeserve.co.uk>
To: bochs-developers@lists.sourceforge.net
Subject: [Bochs-developers] Odd network errors with NT4 Guest OS

I'm having trouble transferring files over the network to the guest OS 
(NT4 SP1). If I'm using SMB then the it errors out early on with a 
session cancelled. The file is 36Mb (SP6). I've tried with various file 
sizes, 3Meg files work, 5 meg files do not.

I've also tried shuffling the files over http with similar problems, 
small files are fine (can browse websites) but large files just error out.

The system is a 1Ghz Windows XP SP1 box with bochs 2.02, guest OS is 
allocated 64Mb of RAM and running Windows NT4 SP1.

Any clues, anyone experiencing similar problems?

--

From: didier <dgautheron at magic.fr>
To: Jeremy Wilkins <jeb at jeremywilkins.freeserve.co.uk>
Cc: bochs-developers@lists.sourceforge.net
Subject: Re: [Bochs-developers] Odd network errors with NT4 Guest OS

Did you try with a big IPS? start the guest clock applet and try to get 
a more or less accurate time, with 1 Ghz should be in the 50 000 000 range.
IIRC NT timeout and abort before it send the whole packet.

--

From: Jeremy Wilkins <jeb at jeremywilkins.freeserve.co.uk>
To: didier <dgautheron at magic.fr>, bochs-developers@lists.sourceforge.net
Subject: Re: [Bochs-developers] Odd network errors with NT4 Guest OS

Thanks, 60 000 000 seems to have done the trick (I can copy sp6 across 
anyway). My original guess of 4000000 IPS was probably a bit low :)

thanks again

------------------------------------------
TAP under FreeBSD 

Date: Fri, 14 Feb 2003 02:12:38 +0100
From: Ronald Klop <ronald at echteman.nl>
To: bochs-developers at lists.sourceforge.net

I've made eth_tap.cc working under FreeBSD 4.7, because the fbsd network driver
didn't work for me.
It's not a very clean patch, but the changes are minimal.

Some notes:
- I found that some of the includes aren't used at all (on FreeBSD).
- The socket which is created before /dev/tap0 is opened doesn't work, because
tap0 is created after opening the device.
- Maybe the eth_tap device can use a configure script like the eth_tuntap
device, because the device must be configured after opening.
- The padding of the ethernet frame with 2 bytes isn't needed in FreeBSD.
- I didn't do any work to check for this in configure, because I don't know how
configure works and don't have the time work it out now.
- the guest os must set (maybe this can be documented somewhere):
kldload if_tap (if tap is not compiled in the kernel)
ifconfig tap0 inet 10.0.1.1 netmask 255.255.255.0
sysctl net.inet.ip.forwarding=1
sysctl net.link.ether.inet.proxyall=1


--------------------------------------------------
This should be included in the user doc
// This option enables "split hard drive" support, which means
// that a series of partial hard disk images can be treated
// as a single large image.  If you set up the partition sizes and
// file sizes correctly, this allows you to store each partition
// in a separate file, which is very convenient if you want to operate
// on a single partition (e.g. mount with loopback, create filesystem,
// fsck, etc.).
// [[Provide example of partitioning]]

----------------------------------------------------------------------
Patch name: patch.sparsedisk-justinsb
Author: Justin SB
Date: 27 Jan 2003

Detailed description:

  This patch enables "sparse hard drive" support:

  1) A large hard drive can be created, and only used space will be stored
      in the file.  In practice this is not a large gain as Unix does this
      anyway.
  2) Multiple sparse drive images can be mounted on top of each other.
      Writes go to the top image.  This allows several similar configurations
      to share a master "base" file, and also allows filesystem rollback or
      no-write options.  Up to 10 disk images can be layered on top of each other.

  There is a need for supporting utilities:
    1) to merge two sparse disk images into a single image
    2) to defragment a sparse disk image and remove unused space

  Examples:
  Space Saving
    1) Create a sparse disk image using bximage.  Set size to eg 10GB.  Only allocated space will be stored,
      so your drive image should be only about as large as the files stored on it.

  Disk Rollback:
    1) Create a sparse disk image called "c.img.0".  Point .bochsrc at "c.img.0".
        In bochs, install your favourite OS.  Switch off bochs.
    2) Create a sparse disk image (of the same size) and name it "c.img.1".  Point .bochsrc at "c.img.1"
        "c.img.0" is visible, but all writes go to "c.img.1".  After using bochs, you can simply delete
        "c.img.1" to undo changes and go back to a clean OS install.

  Disk Optional Commit:
    1) Create a sparse disk image called "c.img.0".  Point .bochsrc at "c.img.0".
        In bochs, install your favourite OS.  Switch off bochs.
    2) Create a sparse disk image (of the same size) and name it "c.img.1".  Point .bochsrc at "c.img.1"
        "c.img.0" is visible, but all writes go to "c.img.1".  After using bochs, if you want to keep the
        changes, use the (currently non-existant) merge utility to make a single unified drive image.
        Alternatively simply create a new partition on top called "c.img.3".

  Common Base:
    1) Create a sparse disk image called "base.img".  Point .bochsrc at "base.img".
        In bochs, install your favourite OS.  Switch off bochs.
    2) Create a sparse disk image (of the same size) and name it "www.img.1".  Make "wwww.img.0" a symlink to
        "base.img".  Point .bochsrc at "www.img.1". Using bochs, install a webserver.
    3) Create a symlink to "base.img" called "db.img.0".  Create a sparse disk image (of the same size)
      and name it "db.img.1".  Point .bochsrc at "db.img.1".  Using bochs, install a database server.

      Now both a database server and webserver can be run in separate virtual machines, but they share
        the common OS image, saving drive space.



  Disk Rollback and Optional Commit will probably be the most used of these options.