mirrors/Bochs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
92f54faa01
Bochs/bochs/README-wxWindows
Bryce Denney 30aaf4088e - commit patch.wxwindows.gz in the main branch. Now you can try out 
the wxwindows interface by just "configure --with-wx; make"

  Modified Files:
    Makefile.in bochs.h config.h.in configure configure.in
    load32bitOShack.cc logio.cc main.cc cpu/cpu.cc cpu/cpu.h
    debug/dbg_main.cc gui/Makefile.in gui/control.cc gui/gui.cc
    gui/siminterface.cc gui/siminterface.h gui/x.cc iodev/cdrom.cc
    iodev/keyboard.cc memory/misc_mem.cc
  Added Files:
    README-wxWindows wxbochs.rc gui/wx.cc gui/wxmain.cc
    gui/wxmain.h gui/bitmaps/cdromd.xpm
    gui/bitmaps/configbutton.xpm gui/bitmaps/copy.xpm
    gui/bitmaps/floppya.xpm gui/bitmaps/floppyb.xpm
    gui/bitmaps/mouse.xpm gui/bitmaps/paste.xpm
    gui/bitmaps/power.xpm gui/bitmaps/reset.xpm
    gui/bitmaps/snapshot.xpm
  Removed Files:
    patches/patch.wxwindows.gz
2002-04-18 00:22:20 +00:00

443 lines
18 KiB
Plaintext
Raw Blame History

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:
+---------------------------------------------------------------+
| |
| Bochs can use a real floppy drive as Disk A, or use an |
| image file. |
| |
| [X] Physical A: drive |
| [ ] Physical B: drive |
| [ ] Disk image: [_____________________________] [Browse] |
| Capacity: [1.44 MB] |
| |
| Hint: To create a disk image, choose the name and capacity |
| above, then click Ok. |
| |
| [ 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
--------------------------------------------------------------------
Reference in New Issue View Git Blame Copy Permalink