interface menus. Parallel port #1 is implemented, and I left stubs for
parallel port #2 in case we want to ever add it. If the parallel port
is enabled, the init method of parallel.cc does an fopen() on the output
file. If disabled, or if the fopen fails, the file handler remains
NULL and no characters are printed. There is no attempt to enable/disable
the operation of the parallel port, only the output to a file.
removed! I used this trick sometimes to check that a function returned
what I expected, like assert (func () == 0), but this caused the
func() to never get called. Oops.
will dump core, and the core can sometimes be loaded into the debugger
to give some hints as to what is going on. This could be especially
useful when the bochs debugger is off.
- try to do something reasonable when abort() doesn't exist on the system.
which were generated with gcc -MM to the end of each Makefile.in
so that make understands which files depend on which. Basically,
everything depends on bochs.h, which depends on everything, which
is not ideal.
- rework the order of initialization with and without the control panel.
The thing that was bothering me most was the command line options were
being processed after the user had set everything in the control panel.
This is clearly not what's expected--the command line options should
affect the startup defaults of the control panel, but whatever the user
chooses in the cpanel menus is the final choice.
- if the control panel (config interface) is not wanted, the user can
put "-nocp" or "-nocontrolpanel" as the FIRST argument on the command
line. Also, the "-psn" option which is automatically passed in by
MacOS X when you doubleclick the application causes the control panel
to be disabled. In this case, the order of operations is:
1. read bochsrc
2. parse command line options.
- if the control panel is enabled (default), the command line options are
parsed to provide the startup defaults for the control panel, but the
control panel settings are the final answer. So the order is:
1. parse command line options
2. run control panel (if user chooses, he can read bochsrc from menus)
- I haven't tested command line options with the debugger yet.
--with-amigaos is allowed and sets up the makefiles correctly. It
defines a symbol called BX_WITH_AMIGAOS, which should be used in
#if..#endif constructs that are specific to amigaos.
- if --enable-cdrom is used with --with-amigaos, the cdrom_amigaos.o
object file will be added to CDROM_OBJS in the iodev makefile.
X servers that I've seen, however on other X servers it makes all
key mappings into absolute junk. We need to continue to work on this
patch to support all X servers and all key maps.
<dieter.mittelmaier@freenet.de> which fixes X11 keyboard mapping
on German keyboards using Keycodes instead of Keysyms.
His comments are:
> I mapped your BX_KEY-defines in gui.h to values from XFree
> ../keycodes/Xfree86. Keysyms in x.cc would now translated
> to keycodes. Now I can use german or us keyboard-layout in
> win95 and all works well.
> Note: Changing keyboard layout in win95 to en works too
> Also you must change keyboard setup in win95 to AT-Enhanced 101/102 keyboard
which notifies them that the mouse_enabled bit has changed. Now that
mouse_enabled can be initialized or modified by parameter events in
addition to GUI events, the guis must be prepared for it. I have pasted
empty method definitions into mouse_enabled_changed_specific for all
guis except for X11, which I did the right way. The implementation
of this function must use the argument "val" rather than reading the
parameter.
goes in/out of mouse capture mode. This is critical because
bx_options.Omouse_enabled is used to control whether the mouse
events are sent into the hardware queue or not (keyboard.cc).
This is only a partial fix though, because changing the mouse
enabled setting in the control panel has no effect on the gui.
