Bochs

History

Bryce Denney d1196d1996 - clean up the command line argument parsing. Before, we had two slightly different versions of the code for wxWindows and non-wxWindows and the GDB stub did not accept any command line options at all. - IMPORTANT CHANGE: the quick start option used to cause two things: 1) read the bochsrc immediately, 2) start simulation immediately without going into the config interface. This has changed in a subtle way. Now, we always try to read the bochsrc immediately. Then if the quick start option is on, we start the simulation immediately. - add "Restore Factory Default Configuration" in text config menu. It was already there in wx. Now the default choice is always "5. Begin simulation" and because the bochsrc is always read now, this works. - When the user chooses "Read configuration file" from either text mode or wx interfaces, reset all bochs parameters first, then read in the new file. This means that every time you read a configuration file you are starting from a consistent "blank slate". - move much of the code from bx_do_text_config_interface into bx_init_main so that wxWindows and non-wxWindows code uses the same logic. There was only a tiny bit left in bx_do_text_config_interface so I eliminated it. - move the "help" message into a separate function print_usage() - detect all flags (cmdline args that start with -) in a loop, instead of a big if/else. This makes it easy to add others. - fix problem with Carbon gui, so that -psn arg gets ignored - print usage if you type -h, --help, or if flags are not recognized - code that called io->set_log_action (that sets the log action for all devices) was only called if the configuration interface was on; I'm not sure why. Now it is called all the time. - the wxWindows equivalent of main() is called MyApp::OnInit. Now OnInit and main() are very similar. They both call bx_init_siminterface, then bx_init_main (and quit if it fails), then show the config interface if quickstart is off, and then simulate. - modified: main.cc gui/control.cc gui/wxmain.cc		2002-10-14 13:37:20 +00:00
..
bios
build
cpu
debug
disasm
doc
docs-html
dynamic
font
fpu
gui	- clean up the command line argument parsing. Before, we had two slightly	2002-10-14 13:37:20 +00:00
instrument
iodev
memory
misc
patches
.bochsrc
.conf.AIX.4.3.1
.conf.amigaos
.conf.beos
.conf.linux
.conf.macos
.conf.macosx
.conf.sparc
.conf.win32
.conf.win32-cygwin
.conf.win32-vcpp
aclocal.m4
bochs.h
bochs.rsrc.hqx
bxversion.h.in
CHANGES
config.guess
config.h.in
config.sub
configure
configure.in
COPYING
gdbstub.cc
install-sh
install-x11-fonts.in
load32bitOShack.cc
logio.cc
macintosh.txt
main.cc	- clean up the command line argument parsing. Before, we had two slightly	2002-10-14 13:37:20 +00:00
Makefile.in
osdep.cc
osdep.h
pc_system.cc
pc_system.h
README
README-wxWindows
state_file.cc
state_file.h
test-x11-fonts
TESTFORM.txt
win32.txt
wxbochs.rc

README

Bochs x86 Pentium Emulator
Updated: Wed Mar 27 20:02:41  2002
Version: 1.4

WHAT IS BOCHS?

Bochs is a highly portable open source IA-32 (x86) PC emulator
written in C++, that runs on most popular platforms.  It includes
emulation of the Intel x86 CPU, common I/O devices, and a custom
BIOS.  Currently, bochs can be compiled to emulate a 386, 486 or
Pentium CPU.  Bochs is capable of running most Operating Systems
inside the emulation including Linux, Windows 95, DOS, and 
Windows NT 4.  Bochs was written by Kevin Lawton and is currently 
maintained by the Bochs project at "http://bochs.sourceforge.net".

Bochs can be compiled and used in a variety of modes, some which are
still in development.  The 'typical' use of bochs is to provide
complete x86 PC emulation, including the x86 processor, hardware
devices, and memory.  This allows you to run OS's and software within
the emulator on your workstation, much like you have a machine
inside of a machine.  Bochs will allow you to run Win '95
applications on a Solaris machine with X11, for example.

Bochs is distributed under the GNU LGPL.  See COPYING for details.

GETTING CURRENT SOURCE CODE 

Source code for Bochs is available from the Bochs home page at
http://bochs.sourceforge.net.  You can download the most recent
release, use CVS to get the latest sources, or grab a CVS
snapshot which is updated nightly.  The releases contain the most
stable code, but if you want the very newest features try the
CVS version instead. 

WHERE ARE THE DOCS?

The Bochs documentation has been overhauled, and it is now
distributed in a separate package called bochsdoc-VERSION.tar.gz.
A copy is also online at 
  http://bochs.sf.net/doc/docbook/alldocs.html
For now, the old documentation can still be found at
  http://bochs.sf.net/docs-html

WHERE CAN I GET MORE INFORMATION?  HOW DO I REPORT PROBLEMS?

Both the documentation and the Bochs website have instructions on how 
to join the bochs-developers mailing list, which is the primary
forum for discussion of Bochs.  The main page of the website also
has links to bug reports and feature requests.  You can browse and
add to the content in these areas even if you do not have a (free)
SourceForge account.  We need your feedback so that we know what
parts of Bochs to improve.  

There is a patches section on the web site too, if you have made
some changes to Bochs that you want to share.

HOW CAN I HELP?

If you would like contribute to the Bochs project, a good first step
is to join the bochs-developers mailing list, and read the archive
of recent messages to see what's going on.  

If you are a technical person (can follow hardware specs, can write
C/C++) take a look at the list of open bug reports and feature
requests to see if you are interested in working on any of the
problems that are mentioned in them.  If you check out the CVS
sources, make some changes, and create a patch, one of the
developers will be very happy to apply it for you.  Developers who
frequently submit patches, or who embark on major changes in the
source can get write access to CVS.  Be sure to communicate with the
bochs-developers list to avoid several people working on the same
thing without realizing it.

If you are a Bochs user, not a hardware/C++ guru, there are still
many ways you could help out.  For example:
  - improving win32 binary releases
  - building up a set of useful tools to include in those releases
  - writing/cleaning up documentation
  - testing out Bochs on every imaginable operating system and 
    reporting how it goes.