mirrors/Bochs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

- rewrite header to describe what's in this file.

Browse Source 
- marked one thing as done
- remove the remnants of the v1.4 readme
This commit is contained in:
Bryce Denney 2002-12-21 16:23:52 +00:00
parent cfba32103e
commit 675335904c
1 changed files with 12 additions and 98 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

110
bochs/README-plugins
View File

@ -1,15 +1,10 @@
README-plugins README-plugins
This is the README file from the CVS branch called BRANCH_PLUGINS. This is the README file that came from the CVS branch called BRANCH_PLUGINS.
It will be hanging around in the main trunk for a short time while It's not intended to be user documentation for plugins. It's more like a
we get things cleaned up. By version 2.0 it should be gone. bunch of to-do lists that the developers used to coordinate their efforts
while working on plugins. At the bottom are some miscellaneous notes by the
Anything that needs to be done, but cannot be done by 2.0 should plugin developers and some references to useful usenet articles.
be written as a bug report/feature request on Source Forge.
------------------------------------------------------------------------- -------------------------------------------------------------------------
BRANCH_PLUGINS BRANCH_PLUGINS
@ -56,7 +51,7 @@ changes:
- a device registration mechanism was set up - a device registration mechanism was set up
- the biosdev and unmapped devices were plugin-ized - the biosdev and unmapped devices were plugin-ized
TO DO BEFORE RELEASE 2.0: TO DO:
- (LATER) some plugins, such as the GUI, PIT, SB, and NE2000, have several different - (LATER) some plugins, such as the GUI, PIT, SB, and NE2000, have several different
possible implementations. In this case, all implementations should be possible implementations. In this case, all implementations should be
children of a single stub class. The stub's methods produce errors or children of a single stub class. The stub's methods produce errors or
@ -77,12 +72,12 @@ TO DO BEFORE RELEASE 2.0:
I don't see any value in this for plugins. If the platform cannot I don't see any value in this for plugins. If the platform cannot
support dlopen or some equivalent, let the configure script crash and support dlopen or some equivalent, let the configure script crash and
tell the user to configure without plugins instead. tell the user to configure without plugins instead.
- to support plugins on MacOSX, the user must install dlcompat. Otherwise - (DONE) to support plugins on MacOSX, the user must install dlcompat.
libtool's configure script will discover that no dlopen() or equivalent Otherwise libtool's configure script will discover that no dlopen() or
function is found, and it will not be able to build/load plugins. equivalent function is found, and it will not be able to build/load
The configure script should bomb in this case, with an error that says plugins. The configure script should bomb in this case, with an error
where to find dlcompat. dlcompat IS installed on SF compile farm in that says where to find dlcompat. dlcompat IS installed on SF compile
/sw/include and /sw/lib. farm in /sw/include and /sw/lib.
- Understand/resolve simulation differences between CVS head and - Understand/resolve simulation differences between CVS head and
BRANCH_PLUGINS. Simulation is slightly different. BRANCH_PLUGINS. Simulation is slightly different.
@ -360,84 +355,3 @@ function table too, even in abstract classes...)
Hope this helps.... Hope this helps....
------------------------------------------------
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/index.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.