474 lines
20 KiB
Plaintext
474 lines
20 KiB
Plaintext
Readme for wxWindows Interface
|
|
updated Wed Apr 17 19:59:17 EDT 2002
|
|
Bryce Denney
|
|
|
|
-------------
|
|
April 17, 2002: The wxwindows interface is now checked into the main
|
|
branch. Known problems
|
|
|
|
TO DO:
|
|
- disk change dialogs for floppy and cdrom need work.
|
|
http://sourceforge.net/tracker/index.php?func=detail&aid=545414&group_id=12580&atid=112580
|
|
- with --with-wx and debugger, control-C in the terminal window kills the
|
|
process instead of just interrupting the simulation.
|
|
- tons of dialogs need to be written
|
|
- debugger interface
|
|
-------------
|
|
|
|
wxWindows Configuration Interface
|
|
|
|
The wxWindows port began in June 2001 around the time of Bochs 1.2.1. Dave
|
|
Poirier and Bryce Denney started adding a wxWindows configuration interface.
|
|
We made some progress, but stopped after a while. Then in March/April 2002
|
|
Bryce and Psyon revived the wxWindows branch and turned it into a (mostly)
|
|
usable interface. Psyon did most of the work to get text and graphics
|
|
working, and Bryce worked on event passing between threads, and keyboard
|
|
mapping.
|
|
|
|
The wxWindows window appears first. This WILL BE where you can choose a preset
|
|
configuration or create one from scratch, then edit the bochsrc options using
|
|
the GUI. Then, by clicking on Simulate:Start, you can start up the Bochs
|
|
simulation. The VGA display is implemented in wxWindows.
|
|
|
|
WARNING: Don't expect perfect code yet!
|
|
|
|
Bryce has tested in linux, where a "configure --with-wx;make" should work fine.
|
|
To build in VC++:
|
|
|
|
- in cygwin, do "sh .conf.win32-vcpp". If you want different configure
|
|
options from the default, edit .conf.win32-vcpp first.
|
|
- in cygwin, do "unzip build/win32/workspace.zip", or use winzip. Now
|
|
you should have bochs.dsw and bochs.dsp in the main directory.
|
|
- open up bochs.dsw, the workspace file.
|
|
- edit project settings so that VC++ can find the wxWindows include
|
|
files and libraries on your system. I installed them in
|
|
d:/wx/wx232/include and d:/wx/wx232/lib. Specifically, edit
|
|
- Project>Settings>C/C++>Preprocessor: include directories.
|
|
- Project>Settings>Link>Input: additional library path.
|
|
- build
|
|
|
|
Note that the project is set up for wxWindows 2.3.2, and the only
|
|
configuration that I've used is called Win32 Debug. To use on
|
|
other wxwindows versions, you will have to change some of the names
|
|
of the libraries to include. Use the samples that came with that
|
|
version of wxwindows for reference.
|
|
|
|
What works right now:
|
|
- cd to a directory with a bochsrc and disk images in it (I use dlxlinux)
|
|
- start up bochs. You get a small wxwindows window with a File menu.
|
|
- choose "Start" on the Simulate menu.
|
|
- a new window pops up with is the normal bochs window. Bochs starts running.
|
|
You can pause it, resume it, or kill it on the Simulate menu.
|
|
- the only visible change is that I've made several of the toolbar
|
|
icons bring up wxwindows dialog boxes. There is a lot going on behind
|
|
the scenes to make this possible--trust me! The 2 floppy icons, CDROM
|
|
icon, and snapshot icon all bring up appropriate dialog boxes to let
|
|
you choose a file.
|
|
- That's all. The other menu options are not implemented except for quit.
|
|
|
|
To do:
|
|
- sketch the GUI pieces that need to be made, with text description of
|
|
basically what they should do. See README.gui-sketch for latest ideas.
|
|
- have a few people look over the sketches so that we don't waste lots of
|
|
time building dialogs that people will hate.
|
|
- code some dialog boxes in wxwindows. Just get it looking right at first, and
|
|
Bryce can help you to get it connected to the simulator using the event
|
|
infrastructure that he has made. Again, after one or two is done there will
|
|
be some good examples to look at.
|
|
- implement ASK_PARAM gui event for all types of parameters. Currently only
|
|
string params are supported, meaning that when you call ask_param() on
|
|
a string parameter, the GUI gives the user a chance to edit that parameter's
|
|
value. We will need to implement boolean, enum, numerical parameters, and
|
|
lists. Lists should probably be displayed as a table or a dialog box
|
|
with several things to select.
|
|
- debugger interface. There's lots of demand for a debugger interface
|
|
to Bochs: possibly more demand than for a configuration interface. We
|
|
should talk about what this will look like, and when we have a plan we
|
|
can start sketching and coding dialogs for the debugger interface too.
|
|
- clean up the biggest memory leaks and init/cleanup code. The gui allows you
|
|
to kill the simulator and restart, but it doesn't do well after the first
|
|
time. Valgrind should help with memory leak debugging, though it doesn't run
|
|
multithreaded programes.
|
|
------------------------------------------------------
|
|
|
|
Random notes follow
|
|
|
|
Added some sketches in README.gui-sketch. I'm thinking that the control
|
|
panel will be able to basically show one of these screens at a time. When
|
|
you first start you would see ChooseConfigScreen which chooses between the
|
|
configurations that you have loaded recently (which it would remember
|
|
by the pathname of their bochsrc). Whether you choose an existing
|
|
configuration to be loaded or a new one, when you click Ok you go to
|
|
the first configuration screen, ConfigDiskScreen.
|
|
|
|
Each of the configuration screens takes up the whole control panel window.
|
|
We could use tabs on the top and/or "<-Prev" and "Next->" buttons to make
|
|
it quick to navigate the configuration screens. Each screen should
|
|
probably have a Prev, Next, Revert to Saved, and Accept button.
|
|
The menu choices like Disk..., VGA..., etc. just switch directly to
|
|
that tab.
|
|
|
|
|
|
------------------------------------------------------
|
|
Notes:
|
|
|
|
events from gui to sim:
|
|
- [async] key pressed or released
|
|
- [async] mouse motion with button state
|
|
- [sync] query parameter
|
|
- [sync] change parameter
|
|
- [async] start, pause, stop, reset simulation. Can be implemented
|
|
as changing a parameter.
|
|
- [async] request notification when some param changes
|
|
|
|
events from sim to gui:
|
|
- [async] log message to be displayed (or not)
|
|
- [async] ask user how to proceed (like panic: action=ask)
|
|
- [async] param value changed
|
|
- make my thread sleep for X microseconds (call wxThread::sleep then return)
|
|
|
|
In a synchronous event, the event object will contain space for the entire
|
|
response. The sender allocates memory for the event and builds it. The
|
|
receiver fills in blanks in the event structure (or could overwrite parts)
|
|
and returns the same event pointer as a response. For async events, probably
|
|
the sender will allocate and the receiver will have to delete it.
|
|
|
|
implement the floppyA and floppyB change buttons using new event
|
|
structure. How should it work?
|
|
|
|
vga gui detects a click on floppyA bitmap
|
|
construct a BxEvent type BX_EVT_ASK_PARAM
|
|
post the event to the wxwindows gui thread (somehow) and block for response
|
|
when it arrives in the gui thread, show a modal dialog box
|
|
get the answer back to the simulator thread
|
|
|
|
|
|
right now, this is working ok within the simulator thread using
|
|
wxMutexGuiEnter/Leave. Still I'm going to change it so that the
|
|
siminterface.cc code builds an event structure and the gui code
|
|
fills in the blank in the structure, instead of the stupid
|
|
notify_get_int_arg stuff.
|
|
|
|
|
|
Starting and Killing Threads
|
|
|
|
When a detachable (default) thread finishes (returns from its Entry()
|
|
function), wxwindows frees the memory associated with that thread.
|
|
Unless the thread is never going to end, it is potentially dangerous to have a
|
|
pointer to it at all. Even if you try to "check if it's alive" first, you may
|
|
be dereferencing the pointer after it has already been deleted, leading to it
|
|
claiming to be alive when it's not, or a segfault. To solve this, the approach
|
|
used in the wxwindows threads example is to have code in the thread's OnExit()
|
|
method remove the thread's pointer from the list of usable threads. In
|
|
addition, any references or changes to the list of threads is controlled by a
|
|
critical section to ensure that it stays correct. This post finally
|
|
explained what I was seeing.
|
|
|
|
+-----------------------
|
|
| From: Pieter van der Meulen (pgmvdm@yahoo.com)
|
|
| Subject: Re: Thread Sample program - bug
|
|
| Newsgroups: comp.soft-sys.wxwindows
|
|
| Date: 2001-06-28 17:51:35 PST
|
|
|
|
|
|
|
|
| At 06:24 PM 6/28/2001, you wrote:
|
|
| >Hi,
|
|
| >I have wxWindows 2.2.7 (wxMSW) installed.
|
|
| >
|
|
| >I just found in the thread.cpp sample code this section:
|
|
| >
|
|
| ><code>
|
|
| >void MyFrame::OnQuit(wxCommandEvent& WXUNUSED(event) )
|
|
| >{
|
|
| > size_t count = wxGetApp().m_threads.Count();
|
|
| > for ( size_t i = 0; i < count; i++ )
|
|
| > {
|
|
| >===> wxGetApp().m_threads[0]->Delete(); <=====
|
|
| > }
|
|
| >
|
|
| > Close(TRUE);
|
|
| >}
|
|
| ></code>
|
|
| >The indecated line should probably rather have a
|
|
| >m_threads[i] rather than m_threads[0] .
|
|
|
|
|
| No, it should not, although it is not immediately obvious. When Delete() is
|
|
| called, the thread will eventually delete itself, but not before it calls
|
|
| MyThread::Exit(), which will remove itself from m_threads[] using
|
|
| wxArray::Remove(this). wxArray::Remove (RemoveAt) will compact the array to
|
|
| remove the element, it is now size-1. After this wxThread::Delete() returns.
|
|
|
|
|
|
|
|
| >I have have a further question to this:
|
|
| >Does this mean that a detached thread created with new
|
|
| >HAS to be deleted manually ? Or is this only in case it might still
|
|
| >be running?
|
|
|
|
|
| Firstly, you must create every detached thread using new since it will
|
|
| delete itself, literally calling delete this.
|
|
| Calling wxThread::Delete() is a correct way to terminate a thread, but
|
|
| manually deleting (using delete) a detached wxThread object is not.
|
|
| wxThread::Delete() will ask the thread to exit, the thread should check for
|
|
| this in wxThread::Entry() regularly using wxThread::TestDestroy() and exit
|
|
| when asked to do so.
|
|
|
|
|
| >(In general I have a unsatisfied felling about when delete is
|
|
| >neccessary and when not -- "I only know, it's not , if the class is
|
|
| >derived from wxWindows")
|
|
|
|
|
| For wxThreads: joinable threads must be deleted (when allocated on the
|
|
| heap), detached threads may never be deleted. For other classes, consult
|
|
| the documentation ;)
|
|
|
|
|
|
|
|
| >Thanks for some feedback,
|
|
| >Sebastian
|
|
|
|
|
| Regards,
|
|
|
|
|
| Pieter.
|
|
+-----------------------
|
|
|
|
tracking some kind of deadlock bug in Linux.
|
|
|
|
seems to be in ReadMailcap, src/unix/mimetypes.cpp in wxwindows sources
|
|
src/unix/mimetype.cpp:2312
|
|
|
|
SOLUTION: compile with -pthread on every compile and link line.
|
|
|
|
|
|
---------------------------------------------------------------------------
|
|
Here are some quick ASCII sketches of what different parts of the interface
|
|
look like. Nothing is implemented yet, and everything is open for debate.
|
|
Whoever writes the wxwindows code for any of these screens gets several
|
|
thousand votes.
|
|
|
|
|
|
Menus:
|
|
- Configuration
|
|
+----------------------+
|
|
| New Configuration |
|
|
| Read Configuration |
|
|
| Save Configuration |
|
|
+----------------------+
|
|
| Quit |
|
|
+----------------------+
|
|
- Edit
|
|
+----------------------+
|
|
| Disks... |
|
|
| Boot -----------> Floppy, Hard disk, or Cdrom
|
|
| VGA... |
|
|
| Memory... |
|
|
| Sound... |
|
|
| Networking... |
|
|
| Keyboard... |
|
|
| Other... |
|
|
+----------------------+
|
|
- Simulate
|
|
+----------------------+
|
|
| Start |
|
|
| Pause/Resume |
|
|
| Stop |
|
|
+----------------------+
|
|
| Speed... |
|
|
+----------------------|
|
|
- Debug
|
|
+----------------------|
|
|
| Show CPU |
|
|
| Show Memory |
|
|
| ? what else ? |
|
|
+----------------------|
|
|
- Event Log
|
|
+----------------------+
|
|
| View |
|
|
| Preferences... |
|
|
| By Device... |
|
|
+----------------------+
|
|
- Help
|
|
+----------------------+
|
|
| About Bochs... |
|
|
+----------------------+
|
|
|
|
What should show up on the control panel when it first comes up?
|
|
I think the standard thing should be to choose a configuration and
|
|
start simulating.
|
|
|
|
|
|
ChooseConfigScreen:
|
|
+--------------------------------------------------------+
|
|
| |
|
|
| Choose a configuration for the Bochs simulator: |
|
|
| |
|
|
| +---+ |
|
|
| | O | DLX Linux Demo |
|
|
| | | | Boot 10MB Hard Disk |
|
|
| +---+ |
|
|
| |
|
|
| +---+ |
|
|
| | O | Redhat Linux Image |
|
|
| | | | Boot 10MB Hard Disk |
|
|
| +---+ |
|
|
| |
|
|
| +---+ |
|
|
| | O | FreeDOS |
|
|
| | | | Boot 40MB Hard Disk |
|
|
| +---+ |
|
|
| |
|
|
| |
|
|
| ?? Create new configuration |
|
|
| |
|
|
| |
|
|
| [ |
|
|
+--------------------------------------------------------+
|
|
|
|
ConfigDisksScreen:
|
|
+---------------------------------------------------------------+
|
|
| |
|
|
| /----+ |
|
|
| |= =| A Drive +----+ |
|
|
| [ ] | __ | Raw Floppy Drive |Edit| |
|
|
| || || A: +----+ |
|
|
| ++--++ |
|
|
| |
|
|
| /----+ |
|
|
| |= =| B Drive +----+ |
|
|
| [ ] | __ | Floppy Disk Image |Edit| |
|
|
| || || C:\Bochs\Images\A.img +----+ |
|
|
| ++--++ |
|
|
| |
|
|
| +-----+ C Drive |
|
|
| |=====| Hard Disk Image +----+ |
|
|
| [BOOT] | o| C:\Bochs\Images\HD30meg.img |Edit| |
|
|
| +-----+ +----+ |
|
|
| |
|
|
| ___ |
|
|
| / \ D Drive +----+ |
|
|
| [ ] | O | ISO CD Image |Edit| |
|
|
| \___/ C:\Bochs\Images\BootCD.img +----+ |
|
|
| |
|
|
| |
|
|
+---------------------------------------------------------------+
|
|
|
|
EditFloppyScreen: (DONE)
|
|
+-----Configure Floppy Drive A----------------------------------+
|
|
| |
|
|
| Bochs can use a real floppy drive as Disk A, or use an |
|
|
| image file. |
|
|
| |
|
|
| [X] Physical floppy drive A: |
|
|
| [ ] Physical floppy drive B: |
|
|
| [ ] Disk image file: [________________________] [Browse] |
|
|
| |
|
|
| What is the capacity of this disk? [1.44 MB] |
|
|
| |
|
|
| Hint: To create a disk image, choose the name and capacity |
|
|
| above, then click Ok. |
|
|
| |
|
|
| [ Help ] [ Cancel ] [ Ok ] |
|
|
+---------------------------------------------------------------+
|
|
|
|
EditHardDisk:
|
|
+-----Configure Hard Disk-------------------------------------------+
|
|
| |
|
|
| Disk image: [______________________________] [Browse] |
|
|
| Geometry: cylinders [____] heads [____] sectors/track [____] |
|
|
| Size in Megabytes: _____ |
|
|
| |
|
|
| [ Help ] [ Cancel ] [ Ok ] |
|
|
+-------------------------------------------------------------------+
|
|
|
|
EditCdrom:
|
|
+-----Configure CDROM-----------------------------------------------+
|
|
| |
|
|
| [ ] Use physical CD-ROM drive [_____________] |
|
|
| [ ] Use disk image [________________________] [Browse] |
|
|
| |
|
|
| [ Help ] [ Cancel ] [ Ok ] |
|
|
+-------------------------------------------------------------------+
|
|
|
|
ConfigVgaScreen:
|
|
FIXME
|
|
|
|
ConfigMemoryScreen:
|
|
romimage: file=bios/BIOS-bochs-latest, address=0xf0000
|
|
megs: 32
|
|
vgaromimage: bios/VGABIOS-elpin-2.40
|
|
FIXME
|
|
|
|
ConfigSoundScreen:
|
|
sb16: midimode=1, midi=/dev/midi00, wavemode=1, wave=/dev/dsp, loglevel=2, log=sb16.log, dmatimer=600000
|
|
FIXME
|
|
|
|
ConfigNetworkingScreen:
|
|
+---------------------------------------------------------------+
|
|
| |
|
|
| Bochs can emulate an NE2000-compatible network card. Would |
|
|
| you like to enable it? |
|
|
| |
|
|
| Enable networking? [X] |
|
|
| |
|
|
| NE2000 I/O address: [ 0x280 ] |
|
|
| IRQ: [ 9 ] |
|
|
| MAC address: [ b0:c4:00:00:00:00 ] |
|
|
| Connection to the OS: [ Linux Packet Filter ] |
|
|
| Physical NIC to use: [ eth0 ] |
|
|
| NE2000 Debug messages: [ ] |
|
|
| |
|
|
+---------------------------------------------------------------+
|
|
|
|
ConfigKeyboardScreen:
|
|
keyboard_mapping: enabled=1, map=US,France,Germany,Spain
|
|
keyboard_type: xt,at,mf
|
|
keyboard_serial_delay: 250
|
|
|
|
FIXME
|
|
|
|
ConfigOtherScreen:
|
|
FIXME
|
|
|
|
ConfigSpeedScreen:
|
|
explain what the heck ips is
|
|
adjust ips with a slider?
|
|
FIXME
|
|
|
|
EventLogPreferences:
|
|
FIXME
|
|
panic: action=ignore,report,fatal,ask
|
|
error: action=ignore,report,fatal,ask
|
|
info: action=ignore,report,fatal,ask
|
|
debug: action=ignore,report,fatal,ask
|
|
|
|
EventLogPrefByDevice:
|
|
FIXME
|
|
keyboard panic=ask error=report info=report debug=ignore
|
|
vga panic=ask error=report info=report debug=ignore
|
|
network panic=ask error=report info=report debug=ignore
|
|
cpu panic=ask error=report info=report debug=ignore
|
|
sound panic=ask error=report info=report debug=ignore
|
|
etc. for about 20 devices.
|
|
|
|
DebugShowCpuRegisters:
|
|
show standard cpu registers and state
|
|
values will update in real time
|
|
this is sort of the start of the debugger interface
|
|
when debugging, maybe highlight values that change between sim steps
|
|
|
|
DebugShowMemory:
|
|
let use choose memory ranges to display
|
|
when debugging, maybe highlight values that change between sim steps
|
|
|
|
|
|
|
|
LogMsgAskDialog:
|
|
---------------------------------------------------------
|
|
Simulation Panic
|
|
|
|
Context: Hard Drive
|
|
Message: could not open hard drive image file '30M.sample'
|
|
|
|
[ ] Don't ask about future messages like this
|
|
|
|
[Continue] [Die] [Dump Core] [Debugger] [Help]
|
|
|
|
-------------------------------------------------------------
|