- moved ne2k presence check to devices.cc
- added special make rules for the ne2k and the lowlevel network support
- added macro for the debug feature of the ne2k
- leave just the two configurations that I plan to build binary RPMs with:
one is conservative with just X11 and the options we used before,
and the other includes plugins, lots of display libraries, etc.
- My previous rev to dbg_main.cc caused the debugger to fail when readline
was disabled. With these changes I have tested more thoroughly and it works
with readline enabled or disabled, and with wxWindows enabled and disabled.
- The Bochs debugger uses BX_WITH_WX to decide to change to wxWindows debugger
behavior: sending a synchronous message to the config interface to get a new
command, sending all dbg_printf output to the config interface, deciding
whether to trap control-C, etc. But now that it's possible to compile with
BX_WITH_WX and BX_WITH_other_things, this isn't quite right anymore. With
this change, we now use calls to a new method SIM->is_wx_selected() to decide
which behavior to use. This method is equivalent to checking if the display
library variable is set to "wx", but it's implemented in such a way that it
only has to check a boolean for each call to SIM->is_wx_selected().
- in siminterface.cc, init some local variables to 0 to avoid compile
warnings.
Modified Files:
debug/dbg_main.cc gui/siminterface.cc gui/siminterface.h
For a whole lot of configure options, I put #if...#endif around code that
is specific to the option, even in files which are normally only compiled
when the option is on. This allows me to create a MS Visual C++ 6.0
workspace that supports many of these options. The workspace will basically
compile every file all the time, but the code for disabled options will
be commented out by the #if...#endif.
This may one day lead to simplification of the Makefiles and configure
scripts, but for the moment I'm leaving Makefiles and configure scripts
alone.
Affected options:
BX_SUPPORT_APIC (cpu/apic.cc)
BX_SUPPORT_X86_64 (cpu/*64.cc)
BX_DEBUGGER (debug/*)
BX_DISASM (disasm/*)
BX_WITH_nameofgui (gui/*)
BX_SUPPORT_CDROM (iodev/cdrom.cc)
BX_NE2K_SUPPORT (iodev/eth*.cc, iodev/ne2k.cc)
BX_SUPPORT_APIC (iodev/ioapic.cc)
BX_IODEBUG_SUPPORT (iodev/iodebug.cc)
BX_PCI_SUPPORT (iodev/pci*.cc)
BX_SUPPORT_SB16 (iodev/sb*.cc)
Modified Files:
cpu/apic.cc cpu/arith64.cc cpu/ctrl_xfer64.cc
cpu/data_xfer64.cc cpu/fetchdecode64.cc cpu/logical64.cc
cpu/mult64.cc cpu/resolve64.cc cpu/shift64.cc cpu/stack64.cc
debug/Makefile.in debug/crc.cc debug/dbg_main.cc debug/lexer.l
debug/linux.cc debug/parser.c debug/parser.y
disasm/dis_decode.cc disasm/dis_groups.cc gui/amigaos.cc
gui/beos.cc gui/carbon.cc gui/macintosh.cc gui/rfb.cc
gui/sdl.cc gui/term.cc gui/win32.cc gui/wx.cc gui/wxdialog.cc
gui/wxmain.cc gui/x.cc iodev/cdrom.cc iodev/eth.cc
iodev/eth_arpback.cc iodev/eth_fbsd.cc iodev/eth_linux.cc
iodev/eth_null.cc iodev/eth_packetmaker.cc iodev/eth_tap.cc
iodev/eth_tuntap.cc iodev/eth_win32.cc iodev/ioapic.cc
iodev/iodebug.cc iodev/ne2k.cc iodev/pci.cc iodev/pci2isa.cc
iodev/sb16.cc iodev/soundlnx.cc iodev/soundwin.cc
reports that on some Linux systems, once you restart the font server
you have to restart X as well. At least with this change it only happens
once, not every time you install.
For a whole lot of configure options, I put #if...#endif around code that
is specific to the option, even in files which are normally only compiled
when the option is on. This allows me to create a MS Visual C++ 6.0
workspace that supports many of these options. The workspace will basically
compile every file all the time, but the code for disabled options will
be commented out by the #if...#endif.
This may one day lead to simplification of the Makefiles and configure
scripts, but for the moment I'm leaving them alone.
More details inside the file itself.
- configure script adds -DBX_PLUGIN_PATH="${plugdir}" to CFLAGS/CXXFLAGS
in the Makefile.
- in main.cc, if plugins enabled and the environment variable LTDL_LIBRARY_PATH
is not set, then it gets set to the value supplied by BX_PLUGIN_PATH.
Modified Files:
main.cc Makefile.in configure.in config.h.in configure
- argc was returning the wrong number of args. Now I treat null and space
the same way, except that null causes the loop to exit.
- change "extern "C" int WinMain" to "int WINAPI WinMain".
- in WinMain pause for the user to read the screen before making it disappear.
This is very useful when there was an error during startup because otherwise
you can't read it. However we'll probably want to disable it when the
user actually asked for Bochs to quit.
> Dlltool creates a useless file called 'mingwex'.
> I think the first dlltool call should only contain bochs object files and
> no link options or external libraries.
For years we have been writing beyond the end of this array in the VGA code:
bx_bool vga_tile_updated[BX_NUM_X_TILES][BX_NUM_Y_TILES];
and doing who-know-how-much damage to other memory structures in the process.
I changed every reference to vga_tile_updated[][] into calls to two macros
GET_TILE_UPDATED and SET_TILE_UPDATED, and defined the macros to check
the bounds of the array before referencing it. At first I used an
assert, then a panic, then an error, and now I'm not printing any message
at all because there were thousands and thousands of messages during
a boot of win95 when it's updating the win95 logo screen.
- I couldn't resist cleaning up a few confusing-looking things like
"if (condition) { // }". There are no functional changes except for
bounds checking on the vga_tile_updated array.
needs to include the .o's and .a's that are part of the Bochs source code
so that it can create a list of Bochs symbols that need to be exported.
I started out using the same list as the link line, but dlltool
doesn't accept all the same options as the link such as -I and -L.
it's easier to find. The other one is for wxWindows on win32 only.
- for wxWindows on win32, I added a function called RedirectIOToConsole() from
an article in the Windows Developers Journal that creates a console window
and sets up stdin,stdout,stderr to operate on the console. This works,
except for a console freezing problem that I described on the mailing list
earlier today.
- Once it is working better, we may want to use the WinMain definition for
other types of compiles on win32, and maybe even for all win32 compiles. In
particular when we compile with SDL we should create a console window too.
- comment out some debug output from the command line parser, add \n's in
a few places. (I'm using stderr instead of BX_PANIC because I don't think
the logging system is ready to be used at this early stage.)
textconfig.cc. I can't quite explain why it wasn't a problem before,
but it's certainly a problem now. In fact VC++ does define off_t, so
I removed the #define entirely.
the bochsrc is loaded by default.
- if you asked for quick start, but the config file could not be loaded,
print a warning "Switching off quick start, because no configuration file
was found".
- now the behavior looks like this:
. no command line arg (most common)
-> .bochsrc is loaded
-> if found defaults to "5. Begin simulation"
-> if not found defaults to "2. Read options from..."
. command line arg -q (user want to quick start from .bochsrc)
-> .bochsrc is loaded
-> if found, run the simulation
-> if not found defaults to "2. Read options from..."
. command line arg -f (user specifies which conf file to load)
-> conf file is loaded
-> if found defaults to "5. Begin simulation"
-> if not found, print error message on console:
>>PANIC<< reading from bochsrc2.txt failed
. command line arg -qf (user want to quick start from a conf file)
-> conf file is loaded
-> if found, run the simulation
-> if not found, print error message on console:
>>PANIC<< reading from other failed
. after selection of "2. Read options from..."
-> defaults to "5. Begin simulation"
. if user wants to create a new conf file:
-> run bochs with no args
-> .bochsrc is loaded by default
-> choose 1. Restore factory default configuration
-> default is changed to "3. Edit options"
- See bug #625696 "text config menu: default can be wrong" for
more discussion of this issue.
- since rombios.c also supports 8 processors, go ahead and build an 8 cpu
bios as well.
Modified Files:
BIOS-bochs-2-processors BIOS-bochs-4-processors
BIOS-bochs-latest
Added Files:
BIOS-bochs-8-processors
Instead, just build all 4 bioses for 1,2,4,8 processors all the time.
Now they should all stay in sync without any special effort.
Modified Files:
rombios.c Makefile.in
- plugins are installed into ${plugdir} which is defined to be
${libdir}/bochs-${VERSION}/plugins.
Modified Files:
Makefile.in plugin.cc configure.in configure gui/Makefile.in
iodev/Makefile.in
The cmos function get_timeval is only used by the pc_system
to print the last system time on exit. We should remove the
STUBFUNC() macro and simply return 0.
. if BX_GUI_SIGHANDLER is true and the term gui is selected at run time,
a new global boolean (bx_gui_sighandler) variable is set to true.
Special signal handling is done if bx_gui_sighandler is true.
. if BX_GUI_SIGHANDLER is not true, bx_gui_sighandler is not compiled in.
New behaviour is:
. No command line arg (user want to load or create a new conf file)
-> no .bochsrc is loaded
-> defaults to "2. Read options from..."
. command line arg -q (user want to quick start from .bochsrc)
-> .bochsrc is loaded
-> if found Run the simulation
-> if not found defaults to "2. Read options from..."
. command line arg -f (user want to edit a conf file)
-> conf file is loaded
-> if found defaults to "3. Edit options"
-> if not found defaults to "2. Read options from..."
. command line arg -qf (user want to quick start from a conf file)
-> conf file is loaded
-> if found Run the simulation
-> if not found defaults to "2. Read options from..."
. After selection of "2. Read options from..."
-> defaults to "5. Begin simulation"
- fix "enable-control-panel" behaviour in configure.in.
- check if a romimage was supplied in the conf file.
If not, print a hint about a missing/corrupt conf file.
I hope I did not break anything, notably the Carbon gui
interface at runtime. The behaviour of the button handlers was wrong if bochs
is configured with plugins and all display libs enabled, wxWindows is present
and a gui using textconfig is selected.
The wx cdrom button still doesn't work since get_first_cdrom() always returns
NULL.
I am somewhat unhappy about the fact that this patch relies (at the
top) on finding rpmbuild in /usr/bin/. A better patch would search the
user's path properly, or perhaps be generated via configure to know
the correct rpmbuild path.
by default.
Rearranged the output to make the output instructions always appear in
the same column, which makes them considerably easier to read.
I have *not* done the physical address display changes -- plan to do
that separately.
stack limits. This is needed for EROS, and probably for L4, as both
rely on this SS fault (and the corresponding GP fault) to trigger the
switch from small address spaces to large address spaces. The
push_16() code was already correct, and I find the inconsistency a bit
odd.
I'm not 100% sure about the push_64() change, so I made the change
with a comment but left it a BX_PANIC() rather than switching it to
BX_INFO. I'll ask Peter momentarily to have a look and let me know.
While I was added, changed the push_16() BX_INFO message to be
consistent with the others -- all now say 'push outside stack limits'.
- add new keyboard init code from Adam Sulmicki
- changed last cli() to #asm cli #endasm
- remove unused cli() function
- don't panic on shutdown status 0x09. just do the normal post
- Now compiles for plain ia-32
- Fixed some printf formatting for ia32 only.
- Update to latest Win32 DLL
- Added an ICEBP (Undoc 0xF8, INT 01) facility.
- updated to use latest VGA refresh routine
Changed "License" to "Bochs License"
Added "Third Party License" section, taken from old docs.
Authored "Will it Work for Me?" section according to instructions in user.dbk comments.
- add a new global struct bx_startup_flags which stores argc,argv and
when necessary, the WinMain arguments hInstance, hPrevInstance, etc.
The new struct is defined in gui/siminterface.h because it is needed in
both the main.cc code and in wxmain.cc and textconfig.cc (which don't
include bochs.h).
- rename main() to bxmain() and create new main() and WinMain().
main() and WinMain() just fill in the bx_startup_flags and then
call bxmain(). Only one is defined at a time, of course.
- so far, WinMain is ONLY used when compiling with wxWindows on win32.
It may be useful in other contexts as well, but I don't want to enable
it in any other situation without some serious testing of different
configurations.
- modified:
main.cc gui/siminterface.cc gui/siminterface.h
gui/textconfig.cc gui/wxmain.cc
I believe that if we had correct BOCHSAPI macros on everything then it
would not be necessary, and on my cygwin box it isn't necessary. However
it seems that on other versions of cygwin it is necessary. The trouble with
--export-all-symbols is that it's making bochs.exp much bigger so the binary
grows by 900k, compared to exporting only the symbols that are marked. If
someone with that "other" version of cygwin can figure out where BOCHSAPI is
needed, this can be removed.
a control panel, but now we're calling it a text configuration interface.
Modified:
.bochsrc Makefile.in bochs.h main.cc cpu/Makefile.in
debug/Makefile.in disasm/Makefile.in fpu/Makefile.in
gui/Makefile.in iodev/Makefile.in memory/Makefile.in
Update Makefile.in to compile it that way.
This fixes a VisualAge problem which prevented bximage from compiling.
I still use the C++ linker for bximage since I don't think it
makes any difference. If it does, that should be changed also.
These files are part of the wx plugin, and they should not be linked
into a separate plugin. I have changed gui/Makefile.in and configure.in
to correct this.
- This fixes bug [ 628667 ] don't build plugin for wxdialog, wxmain
- modified: gui/Makefile.in configure.in configure
- if translation=auto :
. translation=none if cylinders <=1024 and heads <=16
. translation=large if cylinders * heads <= 131072
. transaltion=lba otherwise
- changes default translation value to "auto"
- add example in .bochsrc
- implement "large" "r-echs" "lba" disk translations
- fix if ( (sc==0x01) && (sn=0x01) ) bug
- fix option field in int13 function 0x48 for harddisks
- fix option field in int13 function 0x48 for cdrom
- add "%u" in printf to handle unsigned values
- remove UDIV
- asm helper asm function ldivul idiv_ and idiv_u
one for --disable-cdrom, and one for the defalt if it's not specified. The
enabled action and default are supposed to be the same, but they were
slightly different, and Bochs on BeOS was able to compile with --enable-cdrom
but not with the default action. Solution: now the autoconf actions only
sets bx_cdrom=0 or bx_cdrom=1. Then afterward, it tests $bx_cdrom and does
the enable or disable action. This will be easier to maintain because there
is just one copy of each action, instead of two copies that are supposed to
be kept identical to each other.
there to offer a way to substitute more efficient code
to do the RMW cases. At the moment, they just map to
the normal functions.
Sorry, restored the previous version ...
"bx_bool" which is always defined as Bit32u on all platforms. In Carbon
specific code, Boolean is still used because the Carbon header files
define it to unsigned char.
- this fixes bug [ 623152 ] MacOSX: Triple Exception Booting win95.
The bug was that some code in Bochs depends on Boolean to be a
32 bit value. (This should be fixed, but I don't know all the places
where it needs to be fixed yet.) Because Carbon defined Boolean as
an unsigned char, Bochs just followed along and used the unsigned char
definition to avoid compile problems. This exposed the dependency
on 32 bit Boolean on MacOS X only and led to major simulation problems,
that could only be reproduced and debugged on that platform.
- On the mailing list we debated whether to make all Booleans into "bool" or
our own type. I chose bx_bool for several reasons.
1. Unlike C++'s bool, we can guarantee that bx_bool is the same size on all
platforms, which makes it much less likely to have more platform-specific
simulation differences in the future. (I spent hours on a borrowed
MacOSX machine chasing bug 618388 before discovering that different sized
Booleans were the problem, and I don't want to repeat that.)
2. We still have at least one dependency on 32 bit Booleans which must be
fixed some time, but I don't want to risk introducing new bugs into the
simulation just before the 2.0 release.
Modified Files:
bochs.h config.h.in gdbstub.cc logio.cc main.cc pc_system.cc
pc_system.h plugin.cc plugin.h bios/rombios.c cpu/apic.cc
cpu/arith16.cc cpu/arith32.cc cpu/arith64.cc cpu/arith8.cc
cpu/cpu.cc cpu/cpu.h cpu/ctrl_xfer16.cc cpu/ctrl_xfer32.cc
cpu/ctrl_xfer64.cc cpu/data_xfer16.cc cpu/data_xfer32.cc
cpu/data_xfer64.cc cpu/debugstuff.cc cpu/exception.cc
cpu/fetchdecode.cc cpu/flag_ctrl_pro.cc cpu/init.cc
cpu/io_pro.cc cpu/lazy_flags.cc cpu/lazy_flags.h cpu/mult16.cc
cpu/mult32.cc cpu/mult64.cc cpu/mult8.cc cpu/paging.cc
cpu/proc_ctrl.cc cpu/segment_ctrl_pro.cc cpu/stack_pro.cc
cpu/tasking.cc debug/dbg_main.cc debug/debug.h debug/sim2.cc
disasm/dis_decode.cc disasm/disasm.h doc/docbook/Makefile
docs-html/cosimulation.html fpu/wmFPUemu_glue.cc
gui/amigaos.cc gui/beos.cc gui/carbon.cc gui/gui.cc gui/gui.h
gui/keymap.cc gui/keymap.h gui/macintosh.cc gui/nogui.cc
gui/rfb.cc gui/sdl.cc gui/siminterface.cc gui/siminterface.h
gui/term.cc gui/win32.cc gui/wx.cc gui/wxmain.cc gui/wxmain.h
gui/x.cc instrument/example0/instrument.cc
instrument/example0/instrument.h
instrument/example1/instrument.cc
instrument/example1/instrument.h
instrument/stubs/instrument.cc instrument/stubs/instrument.h
iodev/cdrom.cc iodev/cdrom.h iodev/cdrom_osx.cc iodev/cmos.cc
iodev/devices.cc iodev/dma.cc iodev/dma.h iodev/eth_arpback.cc
iodev/eth_packetmaker.cc iodev/eth_packetmaker.h
iodev/floppy.cc iodev/floppy.h iodev/guest2host.h
iodev/harddrv.cc iodev/harddrv.h iodev/ioapic.cc
iodev/ioapic.h iodev/iodebug.cc iodev/iodev.h
iodev/keyboard.cc iodev/keyboard.h iodev/ne2k.h
iodev/parallel.h iodev/pci.cc iodev/pci.h iodev/pic.h
iodev/pit.cc iodev/pit.h iodev/pit_wrap.cc iodev/pit_wrap.h
iodev/sb16.cc iodev/sb16.h iodev/serial.cc iodev/serial.h
iodev/vga.cc iodev/vga.h memory/memory.h memory/misc_mem.cc
cvs upd -p -r1.1 patches/patch.final-from-BRANCH_PLUGINS.gz > patch.gz
Then gunzip it and read it!
If all you are looking for is the change log, I will save you the trouble
and paste it in right here...
----------------------------------------------------------------------
Patch name: patch.plugins
Date: Thu Oct 24 16:19:04 EDT 2002
Authors:
Bryce Denney
Christophe Bothamy
Kevin Lawton (we grabbed a lot of plugin code from plex86)
Testing help from:
Volker Ruppert
Don Becker (Psyon)
Jeremy Parsons (Br'fin)
GENERAL NOTES
- All the work on this patch was done in a CVS branch called BRANCH_PLUGINS.
It was made into a patch mostly for documentation purposes. You can find
more details on many things mentioned here in the CVS logs for
BRANCH_PLUGINS.
- Generally, this patch touches so many files and so many important variables
that any file that has NOT been test-compiled might not compile anymore.
We have tried to test every file, but there are some that we just can't
test without help from others because we don't have every platform avaiable.
During the bugfix/release process for 2.0 I hope we can get somebody to
compile every file so that we don't release a broken 2.0.
- WARNING: I didn't diff the configure script, since it will almost always be
rejected. You must run autoconf after applying this patch.
USING PLUGINS
- add new configure option --enable-plugins, which turns on plugin support
- added 2 new bochsrc options that let you select which configuration
interface and which display library you want to use:
config_interface: control
display_library: sdl
There is one restriction though: if you want to use wxWindows at all,
then it must be selected as both the config_interface and the
display_library. These two are not separable. There could be
strange interactions between other combinations of libraries that we
haven't discovered yet.
- now you can configure with several different --with-* options at once,
and select between them at runtime. This works with or without plugins
enabled. Example: configure --with-x11 --with-sdl --with-term.
To choose between them use "display_library: name" in the bochsrc
- add new configure options --with-all-libs which tries to detect all the
display libraries that can be compiled on your machine, and enables them
all. If the detection fails, you can always write a bunch of
--with-PACKAGE options yourself.
- when you run Bochs, it needs to know where to find its plugins. For now
if the plugins are not stored in a default system library path, you need to
set the LTDL_LIBRARY_PATH environment to a colon-separated list of
directories to search in to find the plugins. When you first build
Bochs, all the plugins are in gui/* and iodev/*. So this command would
work (sh syntax):
LTDL_LIBRARY_PATH=`pwd`/gui:`pwd`/iodev; export LTDL_LIBRARY_PATH
There is a slight variation for win32: use a semicolon instead of a
colon to separate the directories in the list, and the directories should
start with a drive letter and colon. Example
d:/bochs/plugins;d:/bochs-2.0/plugins
PLATFORMS
- on Win32 platforms, plugins currently work in Cygwin/MinGW but some more
work is needed to support VC++. The makefiles build .DLL files for
the plugins using gcc and a program called dlltool. Remember to
use semicolons to separate dir names in LTDL_LIBRARY_PATH, and to
list absolute directories starting with a drive letter.
- on MacOS X, plugins will only work correctly if you install the
"dlcompat" library. Dlcompat is part of the OpenDarwin project.
- Bochs plugins work on Linux and Solaris without any extra work.
CONFIGURE AND MAKE
- makefiles in gui and iodev directories have some new options and targets
for building plugins. First the object files are sorted into two groups,
pluggable and non-pluggable. When you are compiling with plugins, each of
the pluggable object files is added to the list to compile as plugins.
If plugins are disabled, all objects are put into a list to compile
normally.
- remove MDEFINES from top level makefile
- add LDFLAGS to the @LINK@ variable that is set by configure
- add several plugin-related make targets in toplevel, gui, and iodev
makefiles
- use libtool to build libraries: both static and shared. Except on win32,
libtool doesn't do the job so we just use gcc directly with help from
a program called dlltool.
- use libtool's tiny LTDL library to provide a cross-platform interface
to the functions that load shared libraries. The LTDL sources are included
in the Bochs source code now (ltdl.h and ltdl.c), and also the configure
script generates ltdlconf.h. Bryce has done some minor-to-medium intensity
hacking on LTDL to make it work at all. To see the changes, do cvs diff
-r1.1.2.1 -r1.1.2.2 ltdl.c or look at the CVS logs of
bochs-testing/plugin-test/libltdl/ltdl.c for details.
- add "BOCHSAPI" to every variable, function, and class that any plugin
will need, for building win32 DLLs. The BOCHSAPI macro is used
for DLL building on win32 platforms. In config.h it is defined as
__declspec(dllexport), or __declspec(dllimport), or empty. Config.h
knows if it should be importing or exporting symbols by the BX_PLUGGABLE
macro which is defined in all plugin files.
PLUGIN CONFIGURATION INTERFACES AND DISPLAY LIBRARIES
- a configuration interface is a set of menus that lets you change Bochs's
settings. You can choose between two configuration interfaces:
the text mode menus, and the wxWindows graphical interface.
- A display library is the code that shows text and graphics on the
virtual Bochs screen. There are many different display libraries
to choose from, for example X11, win32, BeOS, Carbon(MacOSX), SDL, etc.
Except for wxWindows, all display libraries look pretty similar. They
create a window with a toolbar full of buttons at the top.
- The wxWindows port is BOTH a configuration interface and a display library.
It has menus and dialog boxes (the config interface) and also a toolbar and
virtual Bochs screen.
- now the standard main() is used ALL the time, even for wxWindows which
used to define its own main in the IMPLEMENT_APP macro. Now we always
start in main(), and wxWindows uses the IMPLEMENT_APP_NO_MAIN macro. It
parses the command line and possibly the configuration file, then according
to the setting of the param BXP_SEL_CONFIG_INTERFACE it starts the text
config interface (control) or the wxWindows config interface (loading a
plugin if necessary). Now the config interface is responsible for
starting the simulation at the appropriate time (by calling
SIM->begin_simulation()), instead of returning and letting main start the
simulation. See cvs log for main.cc 1.156.2.14 for more details.
- wxmain.cc's MyApp::OnInit function is called later in the startup
process than it used to be. Now main() does the first few steps, such
as calling bx_init_main(), and starts up the configuration interface
when it's ready. This means that the config interface does not get
to control the messages that appear during command line parsing or
loading of the .bochsrc. It may have to change in the future.
- configuration interfaces now must define an initialization function that
calls SIM->register_configuration_interface with a callback function.
The callback function is called whenever Bochs needs a simulation
interface. This allows us to easily select between them, even when
support for multiple config interfaces is compiled in. wxWindows
has been made into a plugin, but so far control.cc (the text config
interface) has not due to some difficulties linking bochs without it.
- Bryce intends to rename control.cc to textconfig.cc or something more
appropriate when the branch merge is done. When it was created, it was
called a "control panel" but now that term has been replaced by a
"configuration interface".
- Each display library file (gui/win32.cc, gui/x.cc, etc.) defines a C++ class
that descends from bx_gui_c. bx_gui_c declares some of its methods virtual
so that the child class can redefine the methods. The virtual methods are:
specific_init, text_update, graphics_tile_update, handle_events, flush,
clear_screen, palette_change, dimension_update, create_bitmap,
headerbar_bitmap, replace_bitmap, show_headerbar, get_clipboard_text,
set_clipboard_text, mouse_enabled_changed_specific, and exit. Also,
each file needed a plugin_init, which creates an object of the right
type and sets the global "bx_gui" to it, and a plugin_fini which
(theoretically) cleans up afterward. These turned out to be so similar
that they are defined in a macro called IMPLEMENT_GUI_PLUGIN_CODE(gui_name).
(As usual, wxWindows is different and needs its own plugin_init and fini
since it provides both a configuration interface and a display. It
registers a config interface and calls MyPanel::OnPluginInit, which is
in wx.cc, to create a bx_wx_gui_c and set the bx_gui pointer.)
- removed the first argument of bx_gui::specific_init method because it
is no longer static. In a virtual method, you always know who "this" is.
- bx_gui::get_sighandler_mask() and bx_gui::sighandler() are always present,
defined as virtual methods that do nothing. In term.cc only, they are
redefined to do whatever term needs to do with them. This solves problems
with undefined symbols when you enable term support.
- The various display libraries used to all redefine bx_gui methods instead
of virtual methods of their own subclass. This made it impossible to
compile multiple guis at once. Because they are all child classes with
different names, any number can be linked into a binary at once. This was
important for plugins, but even without plugins it allows us to compile
in support for many display libraries and select them at runtime.
- in siminterface, added register_configuration_interface and
configuration_interface. The register method is called by the
init function of a configuration interface (control.cc or wxmain.cc)
to tell siminterface what function to call when someone wants to start
the config interface. To start it, you call configuration_interface(),
which calls the callback function set up by that init function.
- in siminterface, is_sim_thread, set_sim_thread_func. These replace the
global isSimThread function. I had to make something that was
1) available if wxWindows was compiled in, compiled as a plugin and
either loaded, or not., and 2) did not have any link time references
to wxWindows files. As with other things, when wxWindows initializes
it calls SIM->set_sim_thread_func() with a callback function. When
anyone calls SIM->is_sim_thread() it calls the callback function, or if
it hasn't been installed yet it always returns true.
PLUGIN DEVICES
- Plugin devices are not as uniform as plugin display libraries. There
are many of them that interact, some provide special functions that other
devices can call like bx_pic::raise_irq(), and some have to be initialized
before or after others. Our implementation of plugin devices works like
this:
- each device provides a plugin_init method and a plugin_fini method
- the plugin_init method can initialize any number of devices and they
should be "registered" by calling BX_REGISTER_DEVICE_DEVMODEL().
- all plugin devices descend from a class called bx_devmodel_c. The devmodel
class is made up of virtual functions which tell the operations that we
should be able to do on ANY device. The real implementation of a device,
in a child class, will override these methods to implement the real
behavior of that device. As an example, the C++ class heirarchy for the
keyboard device looks like this:
logfunctions
|
+-- bx_devmodel_c
|
+-- bx_keyb_stub_c
|
+-- bx_keyboard_c
Logfunctions provides logging capabilities. bx_devmodel_c provides a
uniform interface for dealing with any device without even knowing which
one it is. bx_keyb_stub_c defines the interfaces that all external
functions and objects can use, but the implementation of those interfaces
just does a panic saying that you forgot to load the keyboard plugin.
Finally, bx_keyboard_c implements all of the missing methods.
- for devices that provide special functions that other devices can call, we
make a "stub" class in iodev/iodev.h which has virtual functions that just
print a panic or warning message. The real device will create a subclass
of the stub, which redefines the virtual methods with the actual
implementation. This means that we can install an instance of the stub if
the plugin is not loaded to catch any calls to the device (it's that
or a segfault). When the plugin is loaded, we replace the stub with a
pointer to the real class. Virtual functions are equivalent in performance
to setting up function pointers, but the syntax is cleaner and the compiler
helps to enforce correct usage.
- because of limitations of shared libraries on some systems such as
Solaris, it is not safe to rely on global variable constructors being
called. So if you write "bx_my_device device;" as a global variable,
on Solaris the constructor(s) for bx_my_device will not ever be called.
That's why in the plugin_init function we explictly create the object
with the "new" operator.
- every file that can be compiled as a plugin should define BX_PLUGGABLE
before including config.h. This is used when building win32 DLLs.
- in plugin.h, define macros for basically every inter-device function,
for example DEV_dma_register_8bit_channel, BX_MEM_READ_PHYSICAL,
DEV_hd_read_handler, etc. The macros are used everywhere instead
of the direct call to the device, because the macros are designed to
do the right thing even if the plugin is not loaded. This is necessary
even for devices that will always be loaded, but we want to make them
into a plugin. Otherwise we can't link bochs because of references to
undefined symbols.
- in iodev/devices.cc, device plugins are loaded if they are needed. At
the moment we still load almost all of them all the time, but it doesn't have
to be that way. Serial and Parallel devices are loaded only if they
are enabled in the bochsrc/config interface. Devices that can be compiled
as plugins are called plugin*. Devices that have not been converted to
plugins still have their old names like sb16, pit, ne2k. At the end
of the bx_devices::init() function we call bx_init_plugins() which
calls the init function of devices created in plugins. (Not every
device, see core plugins vs. optional plugins.) At the end of
bx_devices::reset() we call bx_reset_plugins() which calls the reset
function of devices created in plugins.
- core plugins vs. optional plugins vs. user plugins
- core plugin: These are so fundamental that Bochs can't even initialize
without them, for example the CMOS. The user can substitute his own
equivalent plugin to replace the CMOS, but he cannot say "Don't load the
CMOS at all." Core plugin devices are initialized and reset explictly by
code in iodev/devices.cc, since the initialization order for some of them
is critical. They are currently NOT added to the device list in
pluginRegisterDevice and pluginRegisterDeviceDevmodel, so that the plugin
system does not call init() and reset(). If a core plugin cannot be found,
Bochs will panic.
(NOT DONE) In the bochsrc we could easily provide a way for the user to
replace a core plugin with a different plugin that implements the same C++
interface. This is not implemented yet. Example bochsrc line:
replace_core_plugin: old=pic, new=mypic
- optional plugin: These can be loaded or not, without affecting Bochs's
ability to start up and simulate. Initialization and reset for all
optional plugins are handled by bx_init_plugins() and bx_reset_plugins(),
which are now called from bx_devices_c::init() and bx_devices_c::reset().
Bochs knows how to configure optional plugins at compile time, and they are
loaded only if the configuration settings enables the device. Examples:
serial, parallel. See the call to is_serial_enabled() in iodev/devices.cc.
There are some "optional" plugins that you might not ever want to leave
out, like vga. Maybe the term optional is not clear and we need to think
of a better name. Bochs will panic if an optional plugin cannot be found.
If the plugin was compiled, then it should be available at runtime too!
- (NOT DONE) user plugin: These are plugins that Bochs does not know
anything about at compile time. The user asks Bochs to load a plugin
using just its filename. It loads the plugin and (somehow) gets
information about what settings the user can configure. The settings are
adjusted by either bochsrc lines or the user interface, and then the
device can be used. User plugins will probably not be supported until
after v2.0.
- These categories might change over time, and more may be added. We have
to start somewhere.
- the keyboard timer handler used to control all sorts of things that had very
little to do with the keyboard! For example, it would call SIM->periodic()
and bx_gui->handle_events() to make the gui update when it was supposed to.
This has been moved into iodev/devices.cc instead. It didn't really belong
in the keyboard model, and what if you wanted to simulate with no keyboard
one day?
- in devices.cc, added the concept of a default I/O handler. Before, the
"unmapped" device was initialized first and it would register every single
I/O port in the whole 64k address space, then other devices would claim the
ones that they needed. Now it works differently. Now, the unmapped device
registers the default I/O read handler and the default I/O write handler,
which are represented by BX_DEFAULT_IO_DEVICE. This is from an email
conversation with Christophe
> Sooner or later, we will need to unregister some ioport handler, because
> some ports can be moved around the io architecture (for example the PCI
> IDE Bus Master ioports). Bochs can not do this at the moment.
> ...
> When another device claims the io address, we change the handler
> number to the one of the new function. This behaviour is compatible with
> the old one.
> But when we'll need to unregister an io address handler, we will just
> reset the handler number to BX_DEFAULT_IO_HANDLER so unmapped is called
> again when the io port is accessed.
> This way, we can have Bochs devices register/unregister/re-register
> their handlers.
- device init() methods no longer have an argument. We used to pass in
a pointer to the global variable bx_devices, which each device would
(usually) dutifully store and use instead of using the global symbol,
but it wasn't helping much. If we start to simulate more than one
PC at once (who knows? it might happen) then maybe we'll add it back.
BUG FIXES THAT ENDED UP IN THE PLUGIN BRANCH
(maybe should be checked in separately?)
- gdbstub should not call bx_parse_cmdline anymore
- check SIM->get_init_done before calling DEV_kbd_paste_delay_changed.
- in all makefiles move $(BX_INCDIRS) to the front. Otherwise you can
accidently get config.h or other important includes from libraries
when they put -Ipath into CFLAGS.
- add semicolon to the end of a BX_INFO for XADD_EdGd in arith32.cc
- make control.cc ignore BX_ASYNC_EVT_REFRESH and BX_ASYNC_EVT_DBG_MSG
instead of sending them to default: which prints a warning.
- remove memset(&s, 0, sizeof(s)) in bx_keyb_c constructor. This memset
was wiping out some of the fields of the parent class (logfunctions).
Patch was created with:
cvs diff -u
Apply patch to what version:
cvs checked out on DATE, release version VER
Instructions:
To patch, go to main bochs directory.
Type "patch -p0 < THIS_PATCH_FILE".
----------------------------------------------------------------------
and a very detailed description of what was changed. These changes will
be checked into the CVS trunk momentarily.
Then I will remove the patch, but it will stay around in CVS history
forever as documentation of what we have done.
such as bx_cpu and bx_mem. I changed them to BX_CPU(0) and BX_MEM(0).
- we still don't have correct support for debugging with multiple processors,
so I added a check in bochs.h that will abort the compile if you try
on GDBstub and processors>1. If/when gdbstub supports multiple processors
we can remove this check.
- also I brought attention to, but did not fix, the line that sets
sockaddr.sin_len = sizeof(sockaddr). On Linux, sockaddr.sin_len does
not exist so we have to remove the line. Since Stu Grossman added this line,
I've asked him to test without the line and let me know if it works.
- modified: gdbstub.cc, bochs.h
Patch name: patch.macosx-console-launch-script
Author: Jeremy Parsons <brefin@mac.com>
Date: Wed Oct 16 2002
Detailed description:
Since the Carbon gui does not yet have a console window of its own, then it
can't be configured from the gui (only the command line) and stdout/stderr both
go to the console. As a shortcut, I offer this patch consisting of this file and
build/macosx/script.data
build/macosx/script.r
build/macosx/bochs.applescript
script.data and script.r are taken from a script compiled into an application.
Flattened out to be checked in. (osacompile can produce runnable scripts, but
wants to create them for the classic environment, so I use these files as part
of a workaround)
When bochs.app is built, it also builds bochs.scpt. To use bochs.scpt you put
both bochs.app and bochs.scpt into the directory with your bochsrc.txt.
bochs.scpt is an applescript that when run notes the current directory, then
tells the terminal application to open a window, cd to the current directory,
and run bochs from the commandline.
----------------------------------------------------------------------
Modified Files:
Makefile.in
Added Files:
build/macosx/bochs.applescript build/macosx/script.data
build/macosx/script.r
when making windows releases, and copy it into the build directory.
However, since some make programs (e.g. freebsd) are giving errors when
bochsdbg is not found (in Linux it just gives a little warning), I have tried
to do it in a more clean way. I put bochsdbg into an "optional" install
list, and put a minus before the line that installs optional files. This
should cause make to ignore any errors that occur while trying to install the
optional ones.
empty pathnames, zero cylinders, etc. It doesn't seem fair to allow
people to write out bochsrcs that they cannot read back in without
patching them up by hand!
- in harddrv.cc add the equivalent checks with BX_PANICs so that at least
we don't start simulating with incomplete device configuration.
- make a few error messages more clear
- modified: main.cc iodev/harddrv.cc
constructors around. The min,max that were being passed to the parent
class constructor had junk in them. In config.h.in, I defined the minimum
and maximum values for each integer datatype so now we pass correct
min and max values to the parent class. These replace the BX_MAX_[U]INT
and BX_MIN_[U]INT values.
- modified: main.cc config.h.in gui/siminterface.cc
value instead of a 32 bit value. Unfortunately there were many uses
of bx_param_num_c::get() which depended on its size, and they were
all broken by this change. So in this rev I am changing get() to
return a 32bit unsigned again. If you really want a 64bit value (which
is quite rare) you should call get64() instead.
- modified: gui/siminterface.h gui/siminterface.cc
decided to make bx_param_num_c::get() return 32bit integers again
instead of trying to find every single case that was broken when
I changed bx_param_num_c::get() to return a 64bit integer.
- as soon as get() returns 32 bit values again, the changes in the previous
rev is are unnecessary.
- change int 15 function to get a pushad_regs_t parameter
instead of the registers enumeration
- change in int 15 references to 32bits,16bits and 8 bits
registers to their pushad_regs_t counterpart
Patch name: patch.macosx-ui-polishing
Author: Jeremy Parsons <brefin@mac.com>
Date: Wed Oct 16 2002
Detailed description:
A number of changes to the Carbon Code to improve how well it meshes with the
MacOS X user experience as well as to make sure that all of more recently added
toolbar buttons actually work.
Specific changes include:
Added partial keymap support. (Keymaps don't yet affect what the user types
but an X11 keymap can be used to enable pasting)
Copying of text screens added
Pasting of text as keyboard input added
Copy, Paste, Reset, and Snapshot menu items now work the same as the
corresponding toolbar elements
Revamped icon handling to use Control Manager IconControls,
thus removing icon display code and greatly simplifying icon click handling code
while adding better behaviours (icons that darken when clicked, track mouse movement,
and only do something if the mouse is released atop of them as well as gaining
the ability to be disabled)
Tweaked Paste toolbar and menu items to only be enabled if key mapping is in use AND the
clipboard contains text
Tweaked Copy and Snapshot toolbar and menu elements to only be enabled if
the screen mode is text.
Tweaked User Keys toolbar element to only be enabled if there are user keys
defined to be sent
Tweaked Configure toolbar element to only be enabled if a tty is available
(as in the emulator was started from a terminal)
Respaced toolbar icons to match Aqua Toolbars
Disabled menu items that are not currently handled (undo, clear, cut, disk eject)
Full screen backdrop resettled all across the screen
Fixed the callback interface so that when a Panic needs to ask the user about continuing
it actually works appropriately.
----------------------------------------------------------------------
