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.
----------------------------------------------------------------------
bx_shadow_num_c able to handle pointers to 64 bit values. This
allows x86-64 and wxWindows to coexist.
- I had a number of duplicate constructors for bx_shadow_num_c,
with an without the description arg. I eliminated the ones
that had no description, and also removed the min/max arg from
all. I still need a bunch of constructors though, for
Bit64u*, Bit64s*, Bit32u*, Bit32s*, Bit16u*, Bit16s*, Bit8u*, Bit8s*.
Having all these constructors allows us to write
new bx_shadow_num (bxid, name, description, &value)
for basically any integer variable. They are all handled by the same class.
- these changes led to minor touchups in cpu/init.cc and iodev/keyboard.cc
- modified:
configure main.cc cpu/init.cc iodev/keyboard.cc
gui/siminterface.cc gui/siminterface.h
X11 keymap files. This okay since the keysym values are identical. The "AltGr"
key on European keyboards doesn't work with wxGTK 2.3.3 because the keysym
GDK_Mode_switch is not handled in wxGTK.
- German keymap table for wx and wxgtkkeys.h are no longer needed
There was a POTENTIAL RISK for your HARDDISKS with the previous
patch because it updated the concat_image_t object (BX_SPLIT_HD is on
by default). The behaviour of BX_SPLIT_HD is to open all filenames
incrementing the last letter. Guess what follows /dev/hda ?
You may now access block devices from within bochs, only
if --disable-split-hd is configured.
It has only been tested on linux and a WinNT guest.
There are issues with the current bios CHS translating scheme and
the guest OS translating scheme. For example my compaq system translates
a physical 38792/16/63 20GiB harddrive to
a logical 2586/240/63, which does not follow the bitshift algorithm.
I had to find a different PCHS that would translate in a compatible LCHS
I still have to investigate further, but I'm afraid everything I can do
will break some systems or the others.
Those issues should be explained in the documentation.
