mirror of https://github.com/bochs-emu/Bochs
1930 lines
160 KiB
HTML
1930 lines
160 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<TITLE>bochs: The Open Source IA-32 Emulation Project (IRC Chat Transcript)</TITLE>
|
|
|
|
<!--#include virtual="includes/header.txt" -->
|
|
|
|
<!--content starts here-->
|
|
<img src="images/logo.gif" alt="A Window, Tux, and the BSD Daemon" width="160" height="175" align="right">
|
|
|
|
<BR><font face="arial, helvetica" color="#1e029a" size="4"><b>Transcript of 5/30/2001 Bochs Chat</b></font><BR><BR> <b>Those in
|
|
attendance were:</b> Bryce Denney (bryce), Greg Alexander (yakovlev), Donald
|
|
Becker (psyon), Mark Knecht (Markk), Tim Butler (uninet), eks|x, nolu, and
|
|
smapnipss<BR>
|
|
<B>Elapsed Time:</b> 4.5 Hours (6:00PM - 10:30 PM PDT)<BR><BR><BR>
|
|
<tt>
|
|
*** Topic for #Bochs: Bochs Pentium Emulator .:. How is the latest release
|
|
working on different platforms? .:. Who uses Bochs anyway? .:. Bugs and
|
|
features! bochs is cool come here
|
|
<br><b>bryce:</b> first thing on my list is: how is the Bochs pre-release working for
|
|
people?
|
|
<br><b>yakovlev:</b> no comment.
|
|
<br><b>bryce:</b> anybody tried it?
|
|
<br><b>uninet:</b> I haven't done a lot of testing yet, but so far so good. The RPM
|
|
loads flawlessly.
|
|
<br><b>MarkK:</b> Is the prerelease the RPM?
|
|
<br><b>uninet:</b> Yes.
|
|
<br><b>MarkK:</b> I've loaded it under RH
|
|
<br><b>MarkK:</b> worked fine
|
|
<br><b>bryce:</b> I heard someone say "I couldn't find bochs because I didn't have
|
|
/usr/local/bin in my path"
|
|
<br><b>MarkK:</b> ran the Linux model
|
|
<br><b>MarkK:</b> that was me!
|
|
<br><b>bryce:</b> some docs will fix that
|
|
<br><b>bryce:</b> :)
|
|
<br><b>uninet:</b> Mark - you have SuSE too, right? That problem doesn't show up
|
|
there...
|
|
<br><b>MarkK:</b> And shucks.....I'm a hardware guy....and I still figured it out! ;-)
|
|
<br><b>bryce:</b> haha
|
|
<br><b>MarkK:</b> No, SuSE is my email server at work....
|
|
<br><b>MarkK:</b> so I haven't tried it there
|
|
<br><b>uninet:</b> Ah.
|
|
<br><b>MarkK:</b> I use RH for my Linux work
|
|
<br><b>uninet:</b> Gotcha. I wasn't sure...
|
|
<br><b>bryce:</b> I was hoping to get some bug reports on 1.2.pre1 to know what needs to
|
|
be fixed before 1.2
|
|
<br><b>MarkK:</b> yes...
|
|
<br><b>bryce:</b> here's what's already been fixed since 1.2.pre1:
|
|
<br><b>bryce:</b> - fixed compile problems in gui/nogui.cc, iodev/pci.cc
|
|
<br><b>bryce:</b> - removed extra paren that broke SHOW_IPS
|
|
<br><b>bryce:</b> - HALT macro in rombios.c causes a bochs panic (which can be
|
|
turned off
|
|
<br><b>bryce:</b> in .bochsrc) instead of actually halting.
|
|
<br><b>bryce:</b> - added additional check for null pointer in debugger exit routine
|
|
<br><b>bryce:</b> - now font/vga.pcf will be installed in the RPM package. Some
|
|
systems
|
|
<br><b>bryce:</b> don't have it.
|
|
<br><b>bryce:</b> mostly really minor stuff
|
|
<br><b>uninet:</b> What about Mark's problem? Perhaps a symlink to /usr/bin would be
|
|
good.
|
|
<br><b>yakovlev:</b> We should put in a fix for the timing.
|
|
<br><b>yakovlev:</b> No, it belongs in /usr/local/bin on linux.
|
|
<br><b>MarkK:</b> I would have been happy with finding it in a readme...
|
|
<br><b>bryce:</b> timing? as in bochs takes 100% cpu?
|
|
<br><b>uninet:</b> It seems that it is rather bad it installs outside the path of RH
|
|
though...
|
|
<br><b>yakovlev:</b> and sometimes runs faster than real time.
|
|
<br><b>yakovlev:</b> I had an idea on that one.
|
|
<br><b>bryce:</b> I agree that's important, but I think not for the 1.2
|
|
<br><b>bryce:</b> I'm thinking bug fixes only, basically, but let's get the timing fixes
|
|
into CVS for the next
|
|
<br><b>yakovlev:</b> Well, what is 1.2?
|
|
<br><b>yakovlev:</b> Are we calling it a bugfix release of any existing feature
|
|
improvements?
|
|
<br><b>yakovlev:</b> essentially?
|
|
<br><b>bryce:</b> right. here's what I was thinking with 1.2.pre1
|
|
<br><b>uninet:</b> I thought it was a feature release
|
|
<br><b>bryce:</b> we had lots of features that only the authors have tried
|
|
<br><b>bryce:</b> and finally the ability to make RPMS and win32 binaries
|
|
<br><b>bryce:</b> so I wanted as many people as possible to be able to try the features
|
|
<br><b>MarkK:</b> So I'll ask the question.....
|
|
<br><b>bryce:</b> but wasn't so sure of stability, so I called it a pre-1.2 release
|
|
<br><b>MarkK:</b> What features?
|
|
<br><b>MarkK:</b> (Where do I find a list?)
|
|
<br><b>yakovlev:</b> SMP, for one.
|
|
<br><b>bryce:</b> CHANGES.txt in the source TAR file
|
|
<br><b>bryce:</b> I'll paste them in now if you want.
|
|
<br><b>yakovlev:</b> bochs-RFB I think is new in 1.2 also.
|
|
<br><b>MarkK:</b> not necessary....I can't run tonight anyway
|
|
<br><b>MarkK:</b> I'll look at the tar file
|
|
<br><b>bryce:</b> there are some important ones, esp in the area of I/O (log file
|
|
output)
|
|
<br><b>bryce:</b> and what you see on stderr
|
|
<br><b>yakovlev:</b> Oh yeah, the code maintenance issues like that one.
|
|
<br><b>uninet:</b> http://bochs.sourceforge.net/docs-html/changelog.html has the log of
|
|
changes too.
|
|
<br><b>yakovlev:</b> Ugh, I'd really like to get my pit changes in, but Abigail has had
|
|
different ideas... Babies do that. :)
|
|
<br><b>MarkK:</b> I'm there now reading
|
|
*** smapnipss (rooot@cs6668169-151.austin.rr.com) has joined channel #Bochs
|
|
<br><b>bryce:</b> so I think 1.2 OFFICIAL should be 1.2.pre1 with a few bug fixes
|
|
<br><b>uninet:</b> Sounds reasonable.
|
|
<br><b>bryce:</b> and anything major should go into CVS snapshots and wait for 1.3 or
|
|
something
|
|
<br><b>yakovlev:</b> Wow, already doing a feature freeze.
|
|
<br><b>bryce:</b> :)
|
|
<br><b>uninet:</b> Bochs going big time. :-)
|
|
<br><b>yakovlev:</b> here's a stupid question:
|
|
<br><b>yakovlev:</b> What kind of release schedule are we expecting here?
|
|
<br><b>yakovlev:</b> 1.2 definitely is NOT ready for the big stuff.
|
|
<br><b>yakovlev:</b> but, it's an incremental improvement.
|
|
<br><b>bryce:</b> I should say pretty early on, I have only worked on projects of 2-3
|
|
people before and have not done this kind of thing before, so I'm learning as
|
|
I go.
|
|
<br><b>MarkK:</b> so far I must say I'm REALLY impressed here though
|
|
<br><b>MarkK:</b> I'm participating on some much larger projects
|
|
<br><b>MarkK:</b> and they're no where as organized
|
|
<br><b>MarkK:</b> (of course I don't really know how many are participating here!!)
|
|
<br><b>bryce:</b> I hope to get more people involved in making decisions like when to do
|
|
releases, but here's what I was thinking for the 1.2 thing
|
|
<br><b>bryce:</b> I wanted to get binary releases out as soon as possible
|
|
<br><b>bryce:</b> since that will allow the most people to try it out, and potentially
|
|
bring in more develoeprs
|
|
<br><b>bryce:</b> first thought was to do binaries of bugfix3 but the I/O improvements
|
|
made such a difference that it seemed like a waste of time.
|
|
<br><b>yakovlev:</b> Well, with the HALT bugfix in the bios... could we do a binary
|
|
release of 1.1.2 also?
|
|
<br><b>bryce:</b> sure, but what about the stderr cleanup, the .bochsrc cleanup, the I/O
|
|
cleanup?
|
|
<br><b>uninet:</b> What would be the advantage of a 1.1.2 binary release?
|
|
<br><b>bryce:</b> there's too much that should be backported IMHO to make it worth it
|
|
<br><b>yakovlev:</b> It would potentially run when the main problem is that HALT bugfix.
|
|
<br><b>bryce:</b> ?
|
|
<br><b>bryce:</b> what would run better in 1.1.2?
|
|
<br><b>yakovlev:</b> What if we independently did a release of just the bios?
|
|
<br><b>yakovlev:</b> I guess that's really what I'm advocating.
|
|
<br><b>bryce:</b> anything is possible. we can backport anything we want.
|
|
<br><b>bryce:</b> given enough time.
|
|
<br><b>yakovlev:</b> We had at least a few messages on the list about people getting
|
|
HALT messages when things used to run fine.
|
|
<br><b>uninet:</b> Can't that be stopped in bochsrc?
|
|
<br><b>bryce:</b> the bug fix to HALT causes errors to be reported correctly, that's
|
|
all.
|
|
<br><b>yakovlev:</b> from the bios fixes you recently added.
|
|
*** Signoff: nolu (Read error: Connection timed out)
|
|
<br><b>yakovlev:</b> yup, that's the problem.
|
|
<br><b>bryce:</b> anything that has STOPPED working because of that was always producing
|
|
error conditions but they weren't being reported.
|
|
<br><b>bryce:</b> so fixing the error reporting is causing people to see the errors that
|
|
before were silent. Does that make sense?
|
|
<br><b>yakovlev:</b> Okay, then what about a bios version that possibly reports but
|
|
continues to run after errors occur.
|
|
<br><b>yakovlev:</b> right
|
|
<br><b>uninet:</b> I thought Bryce said the Bochsrc config allowed for this...
|
|
<br><b>bryce:</b> that's easy enough, although we should eventually fix those errors
|
|
instead of ignore them :)
|
|
<br><b>yakovlev:</b> of course
|
|
<br><b>yakovlev:</b> but once reported, it's a possibly easy workaround.
|
|
<br><b>bryce:</b> Tim, the HALTs now produce a bochs panic. In 1.2 all panics can be
|
|
turned non-fatal by changing the .bochsrc.
|
|
<br><b>yakovlev:</b> but I don't trust any code executing after a HALT.
|
|
<br><b>uninet:</b> So, that would include the ones Greg is referring to, right?
|
|
<br><b>bryce:</b> Tim, yes
|
|
<br><b>yakovlev:</b> Unles you guys are sure that wouldn't make a difference.
|
|
<br><b>bryce:</b> we should distinguish between the rombios code calling the HALT macro
|
|
and a HLT x86 instruction.
|
|
<br><b>MarkK:</b> I agree with that
|
|
<br><b>uninet:</b> That'd be very nice.
|
|
<br><b>yakovlev:</b> I just mean have a version of the bios with HALT defined to be nop.
|
|
<br><b>bryce:</b> the HALT macro was broken until 1.2.pre1, it did absolutely nothing
|
|
<br><b>yakovlev:</b> Which was good from a user perspective, bad from a debugging one.
|
|
<br><b>bryce:</b> the hlt instruction halts the bochs simulation, no question.
|
|
<br><b>yakovlev:</b> doesn't HALT do a hlt?
|
|
<br><b>bryce:</b> in 1.2.pre1, it does.
|
|
<br><b>bryce:</b> I've been working on cvs, and here's what it does now:
|
|
<br><b>yakovlev:</b> Right, and I'm just saying I don't want to have to disable all
|
|
hlts, just the one in HALT.
|
|
<br><b>bryce:</b> the HALT macro causes bochs to call panic
|
|
<br><b>bryce:</b> with the line number of the HALT macro (in rombios.c)
|
|
<br><b>bryce:</b> and then it does NOT call the x86 hlt
|
|
<br><b>yakovlev:</b> oh, that's somewhat better.
|
|
<br><b>bryce:</b> this lets you control what happens through the bochsrc by saying
|
|
"panic: action=fatal" or "panic: action=report"
|
|
<br><b>bryce:</b> do you think that's an ok behavior for a 1.2 release?
|
|
<br><b>yakovlev:</b> Not too bad.
|
|
<br><b>bryce:</b> :)
|
|
<br><b>yakovlev:</b> You guys had talked about being able to isolate panic behavior to a
|
|
particular unit.
|
|
<br><b>yakovlev:</b> well, a particular section of code.
|
|
<br><b>bryce:</b> right
|
|
<br><b>yakovlev:</b> Sorry, work slipping in there.
|
|
<br><b>yakovlev:</b> Is that doable from .bochsrc?
|
|
<br><b>bryce:</b> Todd's I/O code has the capability of having a different action for
|
|
each of panic,error,info,debug for each "module"
|
|
<br><b>bryce:</b> where module is something like "HD", "CPU", "PIT"
|
|
<br><b>bryce:</b> but there is not yet any .bochsrc syntax to specify this
|
|
<br><b>yakovlev:</b> could we define the panics caused by the bios to be a specific
|
|
macro?
|
|
<br><b>yakovlev:</b> macroXXXXX module
|
|
<br><b>bryce:</b> I think you mean something like: panic: facility=cdrom, action=fatal
|
|
<br><b>bryce:</b> panic: facility=bios, action=report
|
|
<br><b>bryce:</b> ?
|
|
<br><b>yakovlev:</b> yup.
|
|
<br><b>bryce:</b> panic: facility=default, action=fatal
|
|
<br><b>yakovlev:</b> although that's a little awkward.
|
|
<br><b>bryce:</b> yes, needs work
|
|
<br><b>yakovlev:</b> but yes, basically that.
|
|
<br><b>bryce:</b> the I/O functions are all ready to do that, we just need a syntax!
|
|
<br><b>bryce:</b> any suggestion?
|
|
<br><b>yakovlev:</b> PIT: panic=fatal
|
|
<br><b>yakovlev:</b> default: panic=fatal
|
|
<br><b>bryce:</b> what about debug,info, and error though?
|
|
<br><b>bryce:</b> PIT: panic=fatal, error=report, info=report, debug=ignore
|
|
<br><b>yakovlev:</b> HD: debug=ignore
|
|
<br><b>yakovlev:</b> sure.
|
|
<br><b>bryce:</b> that seems good enough
|
|
<br><b>yakovlev:</b> it has the added advantage of giving us some direction for
|
|
additional "module parameters"
|
|
<br><b>bryce:</b> I have a feeling it will be better if the thing left of the colon can
|
|
be the same for all such statements, but I'm not sure how to make it look ok.
|
|
<br><b>yakovlev:</b> It seems to me that the only issue for panics, etc. is the action.
|
|
<br><b>yakovlev:</b> hmmmm...
|
|
<br><b>yakovlev:</b> well...
|
|
<br><b>bryce:</b> true but what if you wanted to log HD messages to a different file?
|
|
<br><b>yakovlev:</b> panic: action=fatal <br><b>insert char here:</b> PIT
|
|
<br><b>bryce:</b> log: obj=HD, file="hdlog.txt", panic=fatal, error=report, info=report,
|
|
debug=ignore
|
|
<br><b>bryce:</b> it's getting LONG
|
|
<br><b>bryce:</b> :)
|
|
<br><b>bryce:</b> but soon the GUI will do this for us.
|
|
<br><b>bryce:</b> :)
|
|
<br><b>yakovlev:</b> yup.
|
|
<br><b>yakovlev:</b> just a minute, I like the log idea.
|
|
<br><b>yakovlev:</b> hmmmm...
|
|
<br><b>yakovlev:</b> what if we viewed these more as commands.
|
|
<br><b>yakovlev:</b> so, we could use:
|
|
<br><b>yakovlev:</b> log: filename="outfile", panic=fatal, error=report
|
|
<br><b>yakovlev:</b> log: obj=PIT, filename="outfile2", panic=report, info=report
|
|
<br><b>yakovlev:</b> that's cleaner.
|
|
<br><b>yakovlev:</b> we'd have to decide just how to parse different things.
|
|
<br><b>bryce:</b> so if you have no obj=X then it means the default?
|
|
<br><b>bryce:</b> is that your point?
|
|
<br><b>yakovlev:</b> yup.
|
|
<br><b>bryce:</b> makes sense
|
|
<br><b>yakovlev:</b> no, not just that.
|
|
<br><b>bryce:</b> and later lines override settings from earlier lines
|
|
<br><b>yakovlev:</b> we only have to specify part on a line,
|
|
<br><b>bryce:</b> right
|
|
<br><b>yakovlev:</b> right.
|
|
<br><b>bryce:</b> ok, that sounds like a good start.
|
|
<br><b>yakovlev:</b> filename would apply either only to the module.
|
|
<br><b>yakovlev:</b> or even only to the reporting specified on that line.
|
|
<br><b>MarkK:</b> Is there something easy you could do to keep separate runs in separate
|
|
files?
|
|
<br><b>MarkK:</b> So that if you wanted to run regression it would be easy
|
|
<br><b>bryce:</b> (let's continue the .bochsrc syntax on email, so that we can get to
|
|
other things too)
|
|
<br><b>MarkK:</b> sure
|
|
<br><b>bryce:</b> mark, maybe you could put in a %d or something
|
|
<br><b>bryce:</b> into the filename, and then sprintf some time stamp into the %d
|
|
<br><b>MarkK:</b> that's an idea
|
|
<br><b>yakovlev:</b> there are several ways to do it.
|
|
<br><b>yakovlev:</b> the calling program could just change the value in .bochsrc between
|
|
runs.
|
|
<br><b>yakovlev:</b> at any rate, next topic...
|
|
<br><b>bryce:</b> I had a little survey written up
|
|
<br><b>yakovlev:</b> Maybe the GUI interface would be appropriate?
|
|
<br><b>yakovlev:</b> oh, go ahead.
|
|
<br><b>bryce:</b> but given that we have only 5-6 people...
|
|
<br><b>bryce:</b> let's just take a peek at it but try to get more people to answer it
|
|
later on
|
|
<br><b>yakovlev:</b> K.
|
|
<br><b>bryce:</b> it's at http://bochs.sourceforge.net/ircsurvey.html
|
|
<br><b>bryce:</b> or if it's easier I'll just paste it in
|
|
<br><b>bryce:</b> let's add any number of possible responses that you can think of, and
|
|
maybe we can make this into a web survey instead (or maybe SourceForge
|
|
survey)
|
|
<br><b>uninet:</b> Should I post my response here?
|
|
<br><b>bryce:</b> sure!!
|
|
<br><b>yakovlev:</b> I write bochs as a hobby. I'm more interested in getting it right
|
|
than using it.
|
|
<br><b>bryce:</b> Educator/Student: to see how the computer works
|
|
<br><b>yakovlev:</b> However, I'm also interested in getting x86 programs to run on
|
|
other OSes.
|
|
<br><b>uninet:</b> For the first question (What do you use bochs for): Initially to try
|
|
out Win32, although now just for the enjoyment of running a PC in my PC. :-)
|
|
<br><b>uninet:</b> Future Bug fixes: bug 1. Feature Request: feature 8.
|
|
<br><b>bryce:</b> also to be able to watch the OS working (esp Linux since I can see the
|
|
source too)
|
|
<br><b>uninet:</b> (Mouse problems, and emulation speed respectively)
|
|
<br><b>MarkK:</b> Chip Designer: Inteested in interfacign it to my new design.
|
|
<br><b>MarkK:</b> bad spelling. ;-)
|
|
<br><b>bryce:</b> mark, are you allowed to say what you're designing? :)
|
|
<br><b>MarkK:</b> Sort of....
|
|
<br><b>smapnipss:</b> i use bochs for os development
|
|
<br><b>MarkK:</b> I'm working on some leading edge 1394 stuff
|
|
<br><b>bryce:</b> I understand, I'm a chip designer too.
|
|
<br><b>yakovlev:</b> wow, me too.
|
|
<br><b>yakovlev:</b> I can say. POWER4
|
|
<br><b>MarkK:</b> but I'm also interested in chipset design, and how that might play in
|
|
here
|
|
<br><b>uninet:</b> I'm feeling out numbered here... I'm just a lowly web designer.
|
|
<br><b>bryce:</b> We're thinking about SMP chip designs
|
|
<br><b>bryce:</b> big surprise :)
|
|
<br><b>MarkK:</b> The web rules...;-) We just work!
|
|
<br><b>MarkK:</b> Anyway, long term I'm interestedin how I can use this with new chip
|
|
designs prior to tapeout...
|
|
<br><b>yakovlev:</b> Interesting.
|
|
<br><b>bryce:</b> it could certainly be made into a good driver/monitor...
|
|
<br><b>yakovlev:</b> Were you one of the guys pushing for a more modular design?
|
|
<br><b>MarkK:</b> yes, driver could get deveoped in Windows.
|
|
*** Signoff: smapnipss ()
|
|
<br><b>MarkK:</b> I usually have some sort of C model for the chip
|
|
<br><b>MarkK:</b> hook it all together and try it out...
|
|
<br><b>uninet:</b> That would be nice. Would the C code your are writting be able to be
|
|
open sourced?
|
|
<br><b>bryce:</b> haha
|
|
<br><b>MarkK:</b> LOL
|
|
<br><b>uninet:</b> :-)
|
|
<br><b>yakovlev:</b> ;)
|
|
<br><b>MarkK:</b> Laugh Out Loud or Lot's Of Luck
|
|
<br><b>MarkK:</b> you're choice!!
|
|
*** eks|x (eks@HSE-Montreal-ppp123837.qc.sympatico.ca) has joined channel
|
|
#Bochs
|
|
<br><b>eks|x:</b> hi guys :)
|
|
<br><b>bryce:</b> sorry, I'm just trying to picture the open source chip design...
|
|
People have talked about it, but it's hard to see it happening.
|
|
<br><b>MarkK:</b> hi eks
|
|
<br><b>bryce:</b> Hi eks!
|
|
<br><b>uninet:</b> Hi eks!
|
|
<br><b>eks|x:</b> :)
|
|
<br><b>MarkK:</b> Not really....
|
|
<br><b>bryce:</b> eks: we're just talking about our answers to a little survey at
|
|
http://bochs.sourceforge.net/ircsurvey.html
|
|
<br><b>MarkK:</b> I worked in the IP industry before Phoenix bought us...
|
|
<br><b>uninet:</b> <br><b>sigh:</b> Oh well, I guess bochs needs more speed before it needs IEEE
|
|
1394 anyway...
|
|
<br><b>MarkK:</b> people are starting to do open source Verilog
|
|
<br><b>yakovlev:</b> depends on how prevalent FPGAs become in configurable consumer
|
|
electronics.
|
|
<br><b>MarkK:</b> Or faster platforms to run Bochs on.
|
|
<br><b>yakovlev:</b> Anyways, we're getting very sidetracked.
|
|
<br><b>MarkK:</b> yes
|
|
<br><b>bryce:</b> good point :)
|
|
<br><b>bryce:</b> so I heard several votes for better mouse support (bug1)
|
|
<br><b>uninet:</b> Definately.
|
|
<br><b>eks|x:</b> what I would really appreciate is having the fpu more closely related
|
|
to the debugger, aka fpu stack on cpu_dump
|
|
<br><b>bryce:</b> ah, I never thought about that.
|
|
<br><b>MarkK:</b> Is your 'Disk Image Tools' about how to build HDs with certain OS's
|
|
and apps?
|
|
<br><b>yakovlev:</b> bug1, bug4
|
|
<br><b>bryce:</b> eks, that should not be hard to manage. Bochs must have the values in
|
|
there somewhere, you just need printed out right?
|
|
<br><b>uninet:</b> bug3 sounds like a nice one to fix too...
|
|
<br><b>bryce:</b> yes, bug3 is tough though
|
|
<br><b>bryce:</b> well maybe not tough, just lots of OSes out there.
|
|
<br><b>yakovlev:</b> feature7, feature2
|
|
<br><b>eks|x:</b> bryce: right
|
|
<br><b>uninet:</b> Yeah, at least it would be nice on Win9x.
|
|
<br><b>bryce:</b> for the cdrom support, what if we made a portable way to read from a
|
|
cdrom disk image?
|
|
<br><b>yakovlev:</b> yes, but if we get the CDROM model right, we're done.
|
|
<br><b>eks|x:</b> bryce: we have some 3D computing code we try to work out in a gaming
|
|
station, we worked out out own fpu stack out code, but it would be kinda neat
|
|
to have them out on cpu_dump
|
|
<br><b>eks|x:</b> yakovlev: cdrom model shouldn't be too hard to implement, close to hdd
|
|
model
|
|
<br><b>MarkK:</b> Bryce: So that part is under feature 1?
|
|
<br><b>bryce:</b> not as convenient as the real cdrom (need lots of disk space) but then
|
|
the job of reading the raw cd is left to platform-dependent tools that are
|
|
already around.
|
|
<br><b>yakovlev:</b> that would be good, Bryce.
|
|
<br><b>yakovlev:</b> I was surprised that wasn't there already.
|
|
<br><b>uninet:</b> Would it be possible to make bochs pretend /dev/cdrom was a cdrom
|
|
image?
|
|
<br><b>bryce:</b> I think we just need to understand a few of the ioctls (maybe snatch
|
|
from linux kernel code or something) to see how to read table of contents and
|
|
stuff
|
|
<br><b>yakovlev:</b> well, it would take some looking, but basically, yes.
|
|
<br><b>eks|x:</b> just out of nowhere like that, any of you familiar with 'bfe' ? ;)
|
|
<br><b>yakovlev:</b> We'd have to add the removable media controls to the CDROM
|
|
interface, but even that isn't ridiculous.
|
|
<br><b>bryce:</b> eks: can you add that as a feature request on SF? otherwise I promise
|
|
I'll forget. :)
|
|
<br><b>eks|x:</b> it's a nice addition to bochs I think
|
|
<br><b>eks|x:</b> bryce: I can do that,sure :)
|
|
<br><b>bryce:</b> bfe: I looked at it once, and asked the author if he wanted to
|
|
integrate it, he's not that interested.
|
|
<br><b>uninet:</b> yakovlev: Could it do something similar to Win4Lin, where the guest
|
|
OS handles how the CD's are mounted?
|
|
<br><b>uninet:</b> (i.e. automount, standard mount, etc.)
|
|
<br><b>MarkK:</b> could do that for all the physical I/O if you wanted to...
|
|
<br><b>yakovlev:</b> well, bochs needs to know if a CD is there or not.
|
|
<br><b>eks|x:</b> bryce: yeah, I know, but it's a good tool, I use it often, mostly to
|
|
generate cpu-flow tracing in the history file
|
|
<br><b>bryce:</b> bfe is actually what started me thinking about guis
|
|
<br><b>yakovlev:</b> in the emulated sense.
|
|
<br><b>uninet:</b> Hmm...
|
|
<br><b>yakovlev:</b> Beyond that, it's just a file.
|
|
<br><b>eks|x:</b> yakovlev: one problem I see is changing the actual cd ocne bochs is
|
|
started
|
|
<br><b>uninet:</b> Could it probe the CD-ROM drive every time it is requested?
|
|
<br><b>bryce:</b> slow
|
|
<br><b>yakovlev:</b> Wrong layer, guys.
|
|
<br><b>yakovlev:</b> All bochs needs is:
|
|
<br><b>uninet:</b> How's autmount do it?
|
|
<br><b>yakovlev:</b> CDROM_INSERT().
|
|
<br><b>yakovlev:</b> CDROM_EJECT().
|
|
<br><b>yakovlev:</b> the OS interface code figures out when to call them.
|
|
<br><b>uninet:</b> That'd make sense.
|
|
<br><b>eks|x:</b> yip
|
|
<br><b>bryce:</b> cdrom would be a big help in installing new software
|
|
<br><b>yakovlev:</b> then maybe DISK_SEEK, DISK_READ, and DISK_WRITE to complete the
|
|
set.
|
|
<br><b>MarkK:</b> what's the interface look like between the IDE controller and the
|
|
HD/CDROM?
|
|
<br><b>bryce:</b> if I manage to make a larger-scale survey out of this, anything you'd
|
|
like to add to it?
|
|
<br><b>MarkK:</b> Does it run ATAPI commands?
|
|
<br><b>yakovlev:</b> yes, ATAPI.
|
|
<br><b>uninet:</b> bryce: perhaps a question on the most important feature of a new GUI?
|
|
<br><b>bryce:</b> feature10: GUI for configuration and runtime control
|
|
<br><b>bryce:</b> oh I see
|
|
<br><b>bryce:</b> like what do you want the gui to do?
|
|
<br><b>uninet:</b> Right.
|
|
<br><b>bryce:</b> Answer: everything.
|
|
<br><b>uninet:</b> Assuming that the GUI could have lots of different things (GUI
|
|
debugger, GUI config, etc.)
|
|
<br><b>uninet:</b> Bryce, I like that answer.
|
|
<br><b>bryce:</b> should we talk about guis now?
|
|
<br><b>yakovlev:</b> Answer: everything. I want to push all the interface as far away
|
|
from bochs internals as possible. :)
|
|
<br><b>yakovlev:</b> Notice a recurring theme in my messages? :)
|
|
<br><b>eks|x:</b> any of you tried simnow! ?
|
|
<br><b>eks|x:</b> yakolev? layering? ;)
|
|
<br><b>bryce:</b> I like what Greg said in an email, that we can get separation just by
|
|
putting the GUI code and the bochs code into different libraries that are
|
|
linked together. Do I have that right?
|
|
<br><b>yakovlev:</b> Nope. My impression is that it contains almost an entire
|
|
microprocessor worth of simulation data.
|
|
<br><b>yakovlev:</b> Sort of.
|
|
<br><b>uninet:</b> Yeah, I liked that idea too.
|
|
<br><b>yakovlev:</b> It doesn't necessarily HAVE to be in a different library, but
|
|
that's the idea.
|
|
<br><b>uninet:</b> Well, actually one should be a normal program that requires the
|
|
shared library that contains the other code, right?
|
|
<br><b>yakovlev:</b> Also, I used "GUI code" very loosely.
|
|
<br><b>yakovlev:</b> right, tim.
|
|
<br><b>bryce:</b> no reason to require shared library, but that is one way to do it.
|
|
<br><b>yakovlev:</b> Tim, I mean.
|
|
<br><b>uninet:</b> I think that would be best.
|
|
<br><b>uninet:</b> (not shared library)
|
|
*** Psyon (exodus@exodus.psyon.org) has joined channel #Bochs
|
|
<br><b>yakovlev:</b> Shared library good, but could be compiled separately.
|
|
<br><b>bryce:</b> hi Don!
|
|
<br><b>Psyon:</b> Im here!
|
|
<br><b>uninet:</b> Or rather, what I mean, is Greg's idea. I have no preference in how
|
|
it's done... I'm just thinking in terms of Perl. :-)
|
|
<br><b>Psyon:</b> What did I miss?
|
|
<br><b>Psyon:</b> HEY
|
|
<br><b>uninet:</b> Hi Don!
|
|
<br><b>bryce:</b> it will all be on the web site.
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>Psyon:</b> ok
|
|
<br><b>bryce:</b> we're starting to talk about the GUI!
|
|
<br><b>Psyon:</b> well... what am I hearing about Perl?
|
|
<br><b>Psyon:</b> Good that is my dept?
|
|
<br><b>bryce:</b> we're going reimplement all of bochs in perl.
|
|
<br><b>Psyon:</b> oops
|
|
<br><b>uninet:</b> Yeah, if it is dynamically linked that would be good. That way the
|
|
GUI code could be switched without a recompile.
|
|
<br><b>Psyon:</b> I meant !
|
|
<br><b>Psyon:</b> Uhh...
|
|
<br><b>Psyon:</b> is that a good idea?
|
|
<br><b>bryce:</b> :)
|
|
<br><b>bryce:</b> (that was a joke)
|
|
<br><b>Psyon:</b> oh
|
|
<br><b>Psyon:</b> ok
|
|
<br><b>Psyon:</b> well...
|
|
<br><b>Psyon:</b> You can write perl modules in C
|
|
<br><b>Psyon:</b> cant you?
|
|
<br><b>uninet:</b> :-) Maybe... it wouldn't require a compilier then.
|
|
<br><b>Psyon:</b> I was told
|
|
<br><b>Psyon:</b> write a bochs perl module
|
|
<br><b>Psyon:</b> that would allow you to run bochs and have events caught by perl
|
|
<br><b>yakovlev:</b> Anyways, I used "GUI code" to refer to any thing that interfaces
|
|
with the host system.
|
|
<br><b>yakovlev:</b> Ahh, but then we have to port perl to MacOS.
|
|
<br><b>Psyon:</b> They have a Mac Perl
|
|
<br><b>Psyon:</b> dont they?
|
|
<br><b>uninet:</b> Yeah, I think that's a good definition... so anything that could be
|
|
considered "client code" right?
|
|
<br><b>eks|x:</b> btw, perl is an easy to write into language, but afaik, it's never as
|
|
fast as optimized-compiled C
|
|
<br><b>yakovlev:</b> Yeah, basically.
|
|
<br><b>bryce:</b> greg, how is your model different from what Bochs already does?
|
|
<br><b>bryce:</b> we have cpu, iodev, and gui all in separate libraries.
|
|
<br><b>yakovlev:</b> Not very.
|
|
<br><b>yakovlev:</b> iodev is pretty close to CPU.
|
|
<br><b>Psyon:</b> so the new model reflects the Plex86 plugin structure?
|
|
<br><b>uninet:</b> Is the current GUI library dynamically loaded?
|
|
<br><b>bryce:</b> so with some makefile tricks we could compile them as shared
|
|
libraries.
|
|
<br><b>bryce:</b> not dynamic, no
|
|
<br><b>eks|x:</b> bryce: feature added on sf (fpu stack dump)
|
|
<br><b>bryce:</b> eks: thanks
|
|
<br><b>bryce:</b> uh, I don't know anything about the plex86 plugins, is it based on
|
|
shared libraries?
|
|
<br><b>Psyon:</b> That is how Plex86 does the GUI and IO dev stuff now isnt it?
|
|
<br><b>yakovlev:</b> Right, but we may want to clean up some of the interfaces a bit.
|
|
<br><b>Psyon:</b> I know the GUI is
|
|
<br><b>uninet:</b> bryce: Would it be difficult to make it dynamic so the GUI could be
|
|
changed like a plugin?
|
|
<br><b>Psyon:</b> it compiles it as a shared library
|
|
<br><b>Psyon:</b> the GUI is in the bochs plugin
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>Psyon:</b> uni: There are just certain functions that are needed to be
|
|
implemented for the GUI
|
|
<br><b>yakovlev:</b> Methinks plugins is going a little far.
|
|
<br><b>Psyon:</b> a shared lib that has them wouldnt be a problem
|
|
<br><b>bryce:</b> it seems like compiling as a shared library is not really an important
|
|
feature. it can be done on some platforms and not on others, big deal.
|
|
<br><b>uninet:</b> I'm using plugins in the loose sense of being able to swap in another
|
|
module without having to recompile (like Linux kernel modules)
|
|
<br><b>bryce:</b> it reduces the size of the binary, and maybe you can load up only the
|
|
device models you want that time.
|
|
<br><b>Psyon:</b> the bad thing is that shared libs are done differently on different
|
|
plat forms
|
|
<br><b>bryce:</b> psyon, that's my worry too
|
|
<br><b>Psyon:</b> THey are compiled differently
|
|
<br><b>eks|x:</b> are you guys going with bochs using gui modules or gui using bochs
|
|
module?
|
|
<br><b>Psyon:</b> and... DLLs in windows have to have the exported functions defined
|
|
<br><b>Psyon:</b> __declspec(dllexport)
|
|
<br><b>Psyon:</b> or have a .def file
|
|
<br><b>eks|x:</b> I don't see the real need to swap gui very often without recompile,but
|
|
I might see where switching cpu would be a
|
|
<br><b>uninet:</b> eks|x: I would think the GUI would use the bochs module.
|
|
<br><b>Psyon:</b> eks: it might come in handy with somethign like Bochs-RFB
|
|
<br><b>Psyon:</b> where one time you want to run natively
|
|
<br><b>Psyon:</b> then switch it so you can run over a network
|
|
<br><b>eks|x:</b> yeah
|
|
<br><b>Psyon:</b> but the compiled EXE is so small
|
|
<br><b>Psyon:</b> I just keep two copies
|
|
<br><b>eks|x:</b> one bochs without debugger one with it
|
|
<br><b>uninet:</b> eks|x: It would also be handy if you wanted to use the console gui,
|
|
and then wanted an X11 gui.
|
|
<br><b>bryce:</b> modules might let you make a binary distribution with all the GUIs
|
|
available at .bochsrc time, rather than only one
|
|
<br><b>eks|x:</b> uninet: how often do you switch from one to the other?
|
|
<br><b>Psyon:</b> How big is the compiled bochs on linux?
|
|
<br><b>uninet:</b> eks|x: never. But I haven't actually even tried the console GUI yet.
|
|
<br><b>Psyon:</b> I havent looked at it in linux in a while
|
|
<br><b>eks|x:</b> -rwxr-xr-x 1 root root 1962770 May 29 20:24 bochs
|
|
<br><b>Psyon:</b> whoa!
|
|
<br><b>Psyon:</b> its like 400k in windows
|
|
<br><b>eks|x:</b> with fpu, debugger, and disasm
|
|
<br><b>Psyon:</b> wait
|
|
<br><b>bryce:</b> [bryce@monster bochs-1.2.pre1]$ strip bochs
|
|
<br><b>bryce:</b> ls -[bryce@monster bochs-1.2.pre1]$ ls -l bochs
|
|
<br><b>bryce:</b> -rwxrwxr-x 1 bryce bryce 441036 May 30 22:44 bochs*
|
|
<br><b>Psyon:</b> 384kb
|
|
<br><b>Psyon:</b> that is an out of the box compile of BugFix 2
|
|
<br><b>eks|x:</b> 1.1.3 with a few addys
|
|
<br><b>bryce:</b> I don't think it's the binary size, it's the ability to mix and match
|
|
parts that's powerful, right?
|
|
<br><b>yakovlev:</b> Well, it sounds like we want a bochs executable which loads both a
|
|
GUI and a BOCHS module.
|
|
<br><b>uninet:</b> eks|x: the GUI module would probably be best in Binary releases. If
|
|
you could switch from say a theoretical Motif gui to a GTK GUI or QT GUI...
|
|
<br><b>uninet:</b> ...it would be good since one binary would work on all of those
|
|
GUI's.
|
|
<br><b>eks|x:</b> what about having a main binary using a bochs module and a gui module?
|
|
<br><b>bryce:</b> you can do any of these, however you want.
|
|
<br><b>Psyon:</b> This is where having a separate process for the viewer and the emu
|
|
comes into play
|
|
<br><b>Psyon:</b> that would make it easier to switch the viewer type
|
|
<br><b>yakovlev:</b> eks: jynx
|
|
<br><b>bryce:</b> bochs module with no debugger, optimized for speed, or bochs module
|
|
with debugger and SMP enabled, etc.
|
|
<br><b>MarkK:</b> or modules across a network?
|
|
<br><b>bryce:</b> I haven't used shared libs much. does that make it hard for debugger
|
|
to step through the source and tell you where you are?
|
|
<br><b>uninet:</b> MarkK: That would be another nice reason for modules. RFB could be
|
|
used just by changing modules.
|
|
<br><b>yakovlev:</b> I actually don't like using shared libs for the main bochs at all.
|
|
<br><b>yakovlev:</b> Too hard to make portable.
|
|
<br><b>Psyon:</b> Usually a debugger will tell you which module (lib or dll) the code is
|
|
in
|
|
<br><b>MarkK:</b> I'm also thinking about sim speed....
|
|
<br><b>yakovlev:</b> But compiling them separately would make them useful for other
|
|
things.
|
|
<br><b>MarkK:</b> I can link up 5 or 10 PCs if it's networked together
|
|
<br><b>bryce:</b> they are already compiled separately, as static libraries
|
|
<br><b>yakovlev:</b> Well, a bigger wrapper.
|
|
<br><b>eks|x:</b> -rwxr-xr-x 1 eks users 1472404 May 30 22:42 bochs
|
|
<br><b>eks|x:</b> bare bochs 1.1.3
|
|
<br><b>uninet:</b> bryce: but since they are static libraries, that would mean they need
|
|
to be recompiled for each change, right?
|
|
<br><b>bryce:</b> markk, are you thinking that several pcs would simulate it faster?
|
|
<br><b>yakovlev:</b> Eat up most of iodev, for one.
|
|
<br><b>MarkK:</b> just thinking it might, in the long term
|
|
<br><b>bryce:</b> markk: maybe, probably the first step is multithread support on a
|
|
single machine
|
|
<br><b>MarkK:</b> Also, it might simulate concurrency better later on...
|
|
*** Roadkill (~ondrej@baikonur.orbitec.com.au) has joined channel #Bochs
|
|
<br><b>MarkK:</b> when you want a disk model running in parallel to a VGA model
|
|
<br><b>MarkK:</b> that sort of thing
|
|
*** Roadkill has left channel #Bochs
|
|
<br><b>MarkK:</b> If I had one PC running the HD model, and it had the disk image
|
|
<br><b>bryce:</b> Another big question is what GUI library to use, and I think it should
|
|
be determined by whoever is actually motivated to do some coding.
|
|
<br><b>MarkK:</b> and anotehr running the CPU model...
|
|
<br><b>MarkK:</b> then things would be a bit more like a real PC
|
|
<br><b>MarkK:</b> (this is later though)
|
|
<br><b>uninet:</b> bryce: Like I said (on IM) I'd be willing to make a QT GUI, but I
|
|
would need to wait and see how someone else created a C gui for bochs
|
|
first...
|
|
<br><b>yakovlev:</b> Mark, that's a lower down distinction than where we're talking
|
|
about.
|
|
<br><b>MarkK:</b> I'm a hardware guy! ;-)
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>yakovlev:</b> :)
|
|
<br><b>MarkK:</b> gimme a break! ;-)
|
|
<br><b>bryce:</b> markk: we should try some of these things. I'm afraid that bochs
|
|
spends very little time simulating the behavior of the devices and TONS OF
|
|
TIME simulating all those complicated x86 instructions.
|
|
<br><b>MarkK:</b> yes, and I think no time (maybe) simulating the chip set right now?
|
|
<br><b>Psyon:</b> I think if we are going to make a GUI that uses a toolkit, it should
|
|
use one that Is cross platform
|
|
<br><b>Psyon:</b> QT has a windows version
|
|
<br><b>Psyon:</b> but it costs
|
|
<br><b>Psyon:</b> we might be able to get a special version for bochs though
|
|
<br><b>bryce:</b> what about Tk or wxWindows?
|
|
<br><b>Psyon:</b> is wxWindows any good?
|
|
<br><b>bryce:</b> I have no idea, their website says it is :)
|
|
<br><b>bryce:</b> but it's cross platform, all C based, and open-source
|
|
<br><b>uninet:</b> Psyon: I was mainly thinking I could port what ever free
|
|
crossplatform GUI came out to QT, after the initial work was done. I've never
|
|
done a GUI before, so I probably couldn't do the initial work.
|
|
<br><b>uninet:</b> All I can say is that it seems to me C is the way to go...
|
|
<br><b>uninet:</b> (versus C for the GUI)
|
|
<br><b>Psyon:</b> Well... I dont see why using the standard bochs GUIs are a problem
|
|
<br><b>yakovlev:</b> neither do I.
|
|
<br><b>Psyon:</b> using a GTK of some sort would still have code for Windows and X11 in
|
|
it
|
|
<br><b>uninet:</b> Psyon: GTK for Windows isn't very good at the moment, is it?
|
|
<br><b>Psyon:</b> its decent
|
|
<br><b>Psyon:</b> the Mouse code needs work
|
|
<br><b>Psyon:</b> ive been looking at ways to improve
|
|
<br><b>Psyon:</b> the problem is the way events are handled
|
|
<br><b>bryce:</b> the problem with the current one is that there's no framework to add
|
|
anything at all
|
|
<br><b>Psyon:</b> since handle_events() is only called every so often
|
|
<br><b>uninet:</b> Wouldn't it also cause some problems since it is C-based, where as I
|
|
think MS's commonctrls are C?
|
|
<br><b>Psyon:</b> do to the emulation, the time between calls is a sec or so
|
|
<br><b>Psyon:</b> so it slows it down
|
|
<br><b>Psyon:</b> Who here is pretty familiar with how the mouse emu works?
|
|
<br><b>bryce:</b> not me
|
|
<br><b>yakovlev:</b> not I.
|
|
<br><b>MarkK:</b> nor I
|
|
<br><b>bryce:</b> basically, you're the expert :)
|
|
<br><b>Psyon:</b> when i say handle_events() do you guys know what im refering to?
|
|
<br><b>yakovlev:</b> I've looked at it, but haven't had time to really get into it.
|
|
<br><b>Psyon:</b> well...
|
|
<br><b>eks|x:</b> same here
|
|
<br><b>yakovlev:</b> Are you saying the mouse code is polled.
|
|
<br><b>Psyon:</b> when you amke the GUI
|
|
<br><b>yakovlev:</b> ?
|
|
<br><b>Psyon:</b> you have to keep your own queue of mouse and key events
|
|
<br><b>Psyon:</b> then bochs calls handle_events() in the GUI code
|
|
<br><b>Psyon:</b> and you have to pass it all the events
|
|
<br><b>Psyon:</b> and all of bochs runs in the same thread
|
|
<br><b>Psyon:</b> so it sometimes has a delay between cals
|
|
<br><b>Psyon:</b> to pass teh events to bochs
|
|
<br><b>Psyon:</b> you use mouse_move() or somethign like that
|
|
<br><b>Psyon:</b> and I was thinking about just passing them to bochs as they come in
|
|
<br><b>Psyon:</b> but the window callback for events is on a diff thread
|
|
<br><b>Psyon:</b> and I dont know if that will cause problems
|
|
<br><b>bryce:</b> how often does handle_events get called, and is it on Bochs emulate
|
|
time or real time?
|
|
<br><b>Psyon:</b> It seems to be called every .5 to 1 sec
|
|
<br><b>yakovlev:</b> Hmmmm, sounds like something potentially worth moving from the GUI
|
|
layer into the general bochs layer.
|
|
<br><b>Psyon:</b> when there is heavy emulation being done
|
|
<br><b>Psyon:</b> Well...
|
|
<br><b>Psyon:</b> if we made IODevs have diff threads
|
|
<br><b>Psyon:</b> it would help
|
|
<br><b>bryce:</b> but is it scheduled by the real machine's timer, or by bochs timer
|
|
(like N instructions have gone by)
|
|
<br><b>Psyon:</b> Bochs just has it in a loop
|
|
<br><b>Psyon:</b> Its called as often as It can be i guess
|
|
<br><b>yakovlev:</b> from what Don is saying, sounds like bochs instructions.
|
|
<br><b>bryce:</b> I'm afraid I need to look at it more to be able to know what is going
|
|
on.
|
|
<br><b>Psyon:</b> // Called periodically (vga_update_interval in .bochsrc) so the// the
|
|
gui code can poll for keyboard, mouse, and other// relevant events.
|
|
<br><b>eks|x:</b> I tend to agree with Greg that it's bochs' instructions
|
|
<br><b>Psyon:</b> There
|
|
<br><b>Psyon:</b> that is from Win32.cc in the GUI dir
|
|
<br><b>Psyon:</b> Hmm...
|
|
<br><b>Psyon:</b> I never noticed that
|
|
<br><b>Psyon:</b> I wonder if I set vga_update_interval lower
|
|
<br><b>Psyon:</b> but still
|
|
<br><b>Psyon:</b> with bochs all in one thread
|
|
<br><b>Psyon:</b> it would still cause latency
|
|
<br><b>bryce:</b> I'm worried that we're getting far far away from gui libraries and who
|
|
wants to write some dialog boxes... :)
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>bryce:</b> I want to fix that mouse too, some day.
|
|
<br><b>Psyon:</b> I think that is a big part of the useability problem
|
|
<br><b>uninet:</b> The GUI code is already seperated into a different module, right?
|
|
<br><b>uninet:</b> (or rather library)
|
|
<br><b>Psyon:</b> how well does the mouse work in X11?
|
|
<br><b>bryce:</b> greg and don said, what's wrong with the current gui ?
|
|
<br><b>eks|x:</b> tim: right
|
|
<br><b>eks|x:</b> tim: libgui.a
|
|
<br><b>Psyon:</b> There are some optimizing and cleanup that needs to be done with the
|
|
current ones
|
|
<br><b>Psyon:</b> but that is all
|
|
<br><b>uninet:</b> eks|x: Do you know if it is done in C or C?
|
|
<br><b>eks|x:</b> tim: seemslike c to me
|
|
<br><b>Psyon:</b> it is technically C
|
|
<br><b>eks|x:</b> bx_gui_c::handle_events(void)
|
|
<br><b>Psyon:</b> but doesnt use classes
|
|
<br><b>eks|x:</b> ;)
|
|
<br><b>Psyon:</b> oh
|
|
<br><b>yakovlev:</b> It sounds to me like the way handle_events is used is awkward.
|
|
<br><b>Psyon:</b> guess it doees
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>eks|x:</b> eheh
|
|
<br><b>bryce:</b> Bochs is a wierd mix of C without using a single feature of C.
|
|
<br><b>bryce:</b> :)
|
|
<br><b>Psyon:</b> heheh
|
|
<br><b>uninet:</b> Ah, thanks Bryce.
|
|
<br><b>bryce:</b> greg and don said, what's wrong with the current gui ?
|
|
<br><b>Psyon:</b> I dont think anything is
|
|
<br><b>bryce:</b> and I think that's important to hash out
|
|
<br><b>uninet:</b> So, theoretically, it wouldn't be hard to create a GUI using a C
|
|
toolkit?
|
|
<br><b>Psyon:</b> It might look to plain for some people
|
|
<br><b>yakovlev:</b> No GUI configuration of parameters.
|
|
<br><b>bryce:</b> the thing I'm missing a LOT is the ability to put up dialogs
|
|
<br><b>uninet:</b> Psyon: It looks rather bad, and doesn't have any config tools.
|
|
<br><b>bryce:</b> such as "You just got a panic. do you want to continue"
|
|
<br><b>Psyon:</b> hehehe
|
|
<br><b>bryce:</b> or "Now choose the disk image you want to be in drive A:"
|
|
<br><b>Psyon:</b> I think a live register display would help for debugging too
|
|
<br><b>bryce:</b> that sort of thing
|
|
<br><b>MarkK:</b> Speaking of "You just got a panic. do you want to continue?"
|
|
<br><b>Psyon:</b> making swapable floppy images wouldnt be hard
|
|
<br><b>Psyon:</b> beings you can do it now
|
|
<br><b>Psyon:</b> just unmount it
|
|
<br><b>bryce:</b> how?
|
|
<br><b>Psyon:</b> copy a new disk
|
|
<br><b>MarkK:</b> My 9 year old wants me to come say goodnight
|
|
<br><b>Psyon:</b> and remount
|
|
<br><b>MarkK:</b> bye
|
|
<br><b>eks|x:</b> Psyon: if you mean live reg update, simnow! made the mistake of doing
|
|
such, should be on/off thingy
|
|
<br><b>bryce:</b> renaming the disk image file?
|
|
<br><b>bryce:</b> markk: good night!
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>MarkK:</b> later
|
|
*** Signoff: MarkK ()
|
|
<br><b>Psyon:</b> just copy the new image to the one that is named in bochsrc
|
|
<br><b>Psyon:</b> well...
|
|
<br><b>Psyon:</b> we would want to make it loadable
|
|
<br><b>Psyon:</b> but im saying
|
|
<br><b>yakovlev:</b> copying the image file is awkward.
|
|
<br><b>Psyon:</b> the features are there to do so
|
|
<br><b>bryce:</b> yeah, and then click the stupid disk icon twice?
|
|
<br><b>bryce:</b> it sucks!
|
|
<br><b>yakovlev:</b> And the size can't change.
|
|
<br><b>Psyon:</b> oviously you would unmount... change the image name in memmory
|
|
<br><b>Psyon:</b> then remount
|
|
<br><b>Psyon:</b> Im just saying
|
|
<br><b>Psyon:</b> it should be hard to implement
|
|
<br><b>bryce:</b> what's keeping us from having a dialog box?
|
|
<br><b>yakovlev:</b> And you often forget to unmount, or forget to remount.
|
|
<br><b>bryce:</b> IMHO, no GUI toolkit to write in
|
|
<br><b>yakovlev:</b> I see your point.
|
|
<br><b>Psyon:</b> Well... just make a new toolbar button that lets you load a new image
|
|
<br><b>bryce:</b> psyon: should or shouldn't be hard to implement
|
|
<br><b>Psyon:</b> shouldnt be
|
|
<br><b>bryce:</b> right
|
|
<br><b>Psyon:</b> well...
|
|
<br><b>Psyon:</b> the GUI shoudl have access to all the internal bochs functions
|
|
<br><b>Psyon:</b> init_disk
|
|
<br><b>Psyon:</b> or waht ever it is
|
|
<br><b>yakovlev:</b> What do you mean all the internal bochs functions?
|
|
<br><b>yakovlev:</b> I VERY MUCH disagree with that statement.
|
|
<br><b>Psyon:</b> Well
|
|
<br><b>Psyon:</b> functions that arent in the GUI code
|
|
<br><b>bryce:</b> more toolbar buttons would be fine, but I think we should use
|
|
wxWindows or Tk to allow us to write a somewhat friendly set of controls for
|
|
disk changes, choosing how verbose the logging should be, setting IPS
|
|
<br><b>yakovlev:</b> The GUI should have access to only a limited number of bochs
|
|
functions.
|
|
<br><b>bryce:</b> (or something other than having to write native gui code for every
|
|
little thing)
|
|
<br><b>eks|x:</b> reducing the number of interaction points reduce the error rate
|
|
<br><b>eks|x:</b> easier to debug
|
|
<br><b>yakovlev:</b> I was thinking, what if we used something like an STL dictionary
|
|
and/or list of parms that the GUI code gives bochs on startum.
|
|
<br><b>Psyon:</b> bx_floppy_ctrl_c::init(
|
|
<br><b>Psyon:</b> )
|
|
<br><b>uninet:</b> bryce: I think Tk would be a mistake since it really doesn't work
|
|
very well in Windows (in my experience).
|
|
<br><b>bryce:</b> we haven't even agreed that we need any gui library, that's what I'm
|
|
getting at.
|
|
<br><b>yakovlev:</b> no, the GUI should get some well thought-out interfaces, not
|
|
willy-nilly access to bochs internals.
|
|
<br><b>Psyon:</b> BAH! I cant find the function that ejects it
|
|
<br><b>bryce:</b> IMHO just making all the interfaces to the GUI through public member
|
|
functions is a good way to "define the interface"
|
|
<br><b>yakovlev:</b> Sort of.
|
|
<br><b>bryce:</b> then the .h file for the outermose gui object says exactly what you
|
|
can and can't do with it.
|
|
<br><b>yakovlev:</b> What we really need are acls.
|
|
<br><b>bryce:</b> ? access control lists?
|
|
<br><b>yakovlev:</b> For instance, some disk public member functions should only be
|
|
called by the emulator.
|
|
<br><b>yakovlev:</b> others should only be called by the GUI.
|
|
<br><b>eks|x:</b> can acl be checked at startup only or does it need to be checked at
|
|
every function call?
|
|
<br><b>bryce:</b> I mean that the GUI can only call public member functions of the
|
|
interface object, not that the GUI can call public member functions of any
|
|
object it can find.
|
|
<br><b>uninet:</b> yakovlev: Right... the GUI doesn't need access to everything.
|
|
<br><b>yakovlev:</b> Having a single .h file with the functions that are allowed to be
|
|
accessed outside would be listed there.
|
|
<br><b>yakovlev:</b> acls was just saying that public vs. private isn't descriptive
|
|
enough in some cases.
|
|
<br><b>Psyon:</b> Hmm.... (kinda old topic) but If im looking at this correctly you can
|
|
call bx_floppy_ctrl_c::init() with a new image name it bochs should reload it
|
|
<br><b>Psyon:</b> and it can be a new size
|
|
<br><b>bryce:</b> for example, compile the gui library with only the .h file of one
|
|
bochs class, an interface object whose methods define exactly what a GUI can
|
|
do.
|
|
<br><b>yakovlev:</b> Oh, okay, that's exactly what I'm advocating then, Bryce.
|
|
<br><b>yakovlev:</b> maybe, but bochs doesn't handle floppies right anyways.
|
|
<br><b>Psyon:</b> that seems like a smart idea
|
|
<br><b>Psyon:</b> what doesnt it handle?
|
|
<br><b>Psyon:</b> I reads my real floppies now :)
|
|
<br><b>eks|x:</b> read with MT=0 ;)
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>yakovlev:</b> They should be interfaced to the GUI as simply a file interface and
|
|
ejected/inserted.
|
|
<br><b>yakovlev:</b> it's not separated that well.
|
|
<br><b>yakovlev:</b> file interface meaning a large set of unorganized data.
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>bryce:</b> maybe the first step will be to clean up the interface between current
|
|
GUI library and the rest.
|
|
<br><b>uninet:</b> Question: if and when the GUI gets a config dialog, how should it
|
|
decide whether to save changes to ~/bochsrc or to the bochsrc in the current
|
|
directory?
|
|
<br><b>yakovlev:</b> Right, that's the idea.
|
|
<br><b>Psyon:</b> File/Save menu?
|
|
<br><b>bryce:</b> wherever you choose
|
|
<br><b>Psyon:</b> or ask on close
|
|
<br><b>Psyon:</b> if changes are to be saved
|
|
<br><b>uninet:</b> Ah, that would make sense.
|
|
<br><b>Psyon:</b> just like a word processor would do
|
|
<br><b>yakovlev:</b> What's a bochsrc?
|
|
<br><b>Psyon:</b> bochsrc is the config file
|
|
<br><b>yakovlev:</b> no, you missed the point.
|
|
<br><b>bryce:</b> :)
|
|
<br><b>uninet:</b> Psyon: good point, that would permit runtime only changes.
|
|
<br><b>bryce:</b> bochsrc = some place to save the settings that you like, in some form
|
|
<br><b>bryce:</b> so that you can get them back
|
|
<br><b>yakovlev:</b> right.
|
|
<br><b>bryce:</b> and also send them to somebody so they can duplicate your setup
|
|
<br><b>Psyon:</b> Would be nice to have something like VMWare, so that when the program
|
|
starts it asks what configuration you wish to load
|
|
<br><b>yakovlev:</b> Something which exists totally outside the bochs emulation layer.
|
|
<br><b>Psyon:</b> and has the option to start with power off
|
|
<br><b>uninet:</b> Psyon: I agree, that would be VERY nice.
|
|
<br><b>bryce:</b> greg, yes only that gui part would be reading and writing the bochsrc
|
|
I think.
|
|
<br><b>uninet:</b> VMware has a very well thought out GUI, I think it would be a good
|
|
idea to use a lot of it's ideas.
|
|
<br><b>Psyon:</b> hehehe
|
|
<br><b>eks|x:</b> VMWare is quite good on the gui side, simply missing debugging :P
|
|
<br><b>yakovlev:</b> Watch out for patents there. They're going to be looking at us
|
|
fairly closely.
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>eks|x:</b> are gui patentable?
|
|
<br><b>bryce:</b> yes, I've been handling different configurations by making a different
|
|
directory for every OS that I can run
|
|
<br><b>Psyon:</b> well... I dont think that a start with power off option is patented
|
|
<br><b>Psyon:</b> I just like that idea, so you can start the program
|
|
<br><b>bryce:</b> and each one has its own .bochsrc, disk images, and symbolic link to
|
|
the most recent bochs binary and ROM
|
|
<br><b>Psyon:</b> make config changes
|
|
<br><b>Psyon:</b> then power on the system
|
|
<br><b>Psyon:</b> and since there is already a power button on the toolbar
|
|
<br><b>uninet:</b> yakovlev: you would just want to copy the general ideas, hopefully
|
|
with enough improvements that the VMware people wouldn't even care.
|
|
<br><b>bryce:</b> I'm not saying I like the "each os in a different directory", only
|
|
that that's what I've resorted to for now.
|
|
<br><b>bryce:</b> unless we do a blatant copy of their toolbar or something, I don't
|
|
think we're in trouble.
|
|
<br><b>Psyon:</b> can you run bochs with a config file as an argument... like "bochs
|
|
mysystem.rc"
|
|
<br><b>Psyon:</b> if not
|
|
<br><b>bryce:</b> not sure if it works now, but it would be useful sometimes
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>Psyon:</b> that is something else that might be done in the next release or
|
|
something
|
|
<br><b>bryce:</b> go for it :)
|
|
<br><b>Psyon:</b> actually
|
|
<br><b>uninet:</b> I thought it already worked as a command argument.
|
|
<br><b>Psyon:</b> I think all options can be done on the command line
|
|
<br><b>Psyon:</b> cant they
|
|
<br><b>Psyon:</b> yeah
|
|
<br><b>bryce:</b> yes something like bochs "boot:c" "diskc:blabla"
|
|
<br><b>Psyon:</b> I mostly look at the GUI code so im kinda dumb as to how the rest
|
|
works
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>bryce:</b> I think we should be able to do basically any kind of .bochsrc work in
|
|
a GUI, if we ever expect to make it a user-friendly thing.
|
|
<br><b>Psyon:</b> yeah
|
|
<br><b>yakovlev:</b> I'll make up a generic interface in the next few days and post it
|
|
to the list. It'll be VERY generic. That'll be a RFC.
|
|
<br><b>Psyon:</b> I think the current way of bochs telling the GUI what Buttons to make
|
|
on the tool bar could be carried over to a menu system also
|
|
<br><b>bryce:</b> and once you've got that, it's not much of a stretch to have runtime
|
|
control of some things like IPS and log behavior too
|
|
<br><b>yakovlev:</b> For now, I'm headed to bed.
|
|
<br><b>uninet:</b> 'night Yak.
|
|
<br><b>Psyon:</b> cya
|
|
<br><b>bryce:</b> greg, sounds great!
|
|
<br><b>yakovlev:</b> All you West Coast boys have fun.
|
|
<br><b>yakovlev:</b> :)
|
|
<br><b>bryce:</b> good night
|
|
<br><b>Psyon:</b> night
|
|
*** Signoff: yakovlev (Java Chat http://www.undernet.org/webchat.php)
|
|
<br><b>Psyon:</b> bx_gui_c::headerbar_bitmap
|
|
<br><b>Psyon:</b> oops
|
|
<br><b>Psyon:</b> right now bochs calles bx_gui_c::headerbar_bitmap() and
|
|
bx_gui_c::show_headerbar() to make the toolbar
|
|
<br><b>Psyon:</b> something like that could be done for a Menu system
|
|
<br><b>Psyon:</b> basically
|
|
<br><b>eks|x:</b> Psyon: I think the bochs gfx window shouldn't have icons at all
|
|
<br><b>Psyon:</b> well...
|
|
<br><b>Psyon:</b> im saying
|
|
<br><b>Psyon:</b> the same system
|
|
<br><b>Psyon:</b> could be used to build menus
|
|
<br><b>eks|x:</b> Psyon: I think the gfx window should be a videocard dev using the gui
|
|
toolkit
|
|
<br><b>Psyon:</b> so that the GUI doesnt have to be changed with each new option
|
|
<br><b>bryce:</b> right, something pretty generic can be worked out like the toolbar
|
|
thing
|
|
<br><b>uninet:</b> eks|x: Wouldn't removing the icons lower the friendliness level below
|
|
it's already "lowness"?
|
|
<br><b>eks|x:</b> the gui interface would be using the gui toolkit for the icons
|
|
directly
|
|
<br><b>eks|x:</b> uninet: if you build up a gui to control bochs, you can have icons in
|
|
it, no on the bochs output
|
|
<br><b>Psyon:</b> bx_gui_c::headerbar_bitmap() is passed a bitmap ID returned by an
|
|
earlier function, the alignment (left or right), and a pointer to a function
|
|
<br><b>eks|x:</b> what I would like to see, is a window with nothing in it else than
|
|
what you see on the crt of your comp
|
|
<br><b>Psyon:</b> eks: the current Icons are just simple bit maps used to display the
|
|
buttons
|
|
<br><b>Psyon:</b> nothing stopping us from making that A toolbar button
|
|
<br><b>Psyon:</b> or a menu item
|
|
<br><b>eks|x:</b> and another window that is the bochs control/debugger/etc
|
|
<br><b>Psyon:</b> I would like a full screen option :)
|
|
<br><b>Psyon:</b> Ive been looking at how to do that also
|
|
<br><b>eks|x:</b> definately :)
|
|
<br><b>Psyon:</b> the current tool bar messes it up a little
|
|
<br><b>eks|x:</b> yip
|
|
<br><b>Psyon:</b> but I can work around it
|
|
<br><b>Psyon:</b> at least for windows
|
|
<br><b>uninet:</b> Does anyone here know how to convert normal bitmaps to the ones in
|
|
the .h files in the source code?
|
|
<br><b>eks|x:</b> having it all in the gui bochs control would allow that
|
|
<br><b>Psyon:</b> Im not as familiar with X11 programming
|
|
<br><b>eks|x:</b> tim: sorry, not me
|
|
<br><b>Psyon:</b> uni: the ones in the H are just 1bit bitmaps
|
|
<br><b>bryce:</b> we need to choose at what level the gui/bochs interface should talk.
|
|
I guess this is what Greg said he would work on
|
|
<br><b>eks|x:</b> yeah, the rfc
|
|
<br><b>uninet:</b> Pyson: Win4Lin accomplishes fullscreen by starting a new X session on
|
|
another tty, and then maximizing the window it's in...
|
|
<br><b>bryce:</b> but there is everything from: Now print dialog box #7, which asks
|
|
what disk you want to insert now
|
|
<br><b>uninet:</b> Psyon: 1bit bitmaps?
|
|
<br><b>bryce:</b> to: create a dialog, with a text field here and a button there
|
|
<br><b>Psyon:</b> yep
|
|
<br><b>eks|x:</b> bryce: the 'to:' is a gui toolkit job
|
|
<br><b>Psyon:</b> each bit represetns one pixel
|
|
<br><b>bryce:</b> this is a large space, and somewhere in the middle is the best answer
|
|
<br><b>Psyon:</b> either black or white
|
|
<br><b>Psyon:</b> or forground or background
|
|
<br><b>eks|x:</b> #7 is the actual job of a gui front-end
|
|
<br><b>bryce:</b> psyon: I think he wants to know how to make a new 1-bit bitmap to
|
|
substitute
|
|
<br><b>Psyon:</b> I should say monochomr
|
|
<br><b>uninet:</b> Psyon: Ah, is there anyway to do color 8 bit bitmaps this way?
|
|
<br><b>Psyon:</b> We would have to change how they are passed to the gui
|
|
<br><b>uninet:</b> bryce: Yeah, although perferably also raise the quality above 1-bit.
|
|
<br><b>Psyon:</b> unsigned bx_gui_c::create_bitmap(const unsigned char *bmap, unsigned
|
|
xdim, unsigned ydim)
|
|
<br><b>Psyon:</b> char *bmap is the bitmap
|
|
<br><b>Psyon:</b> and that function in the GUI makes a native bitmap
|
|
<br><b>bryce:</b> what tool can convert a GIF into such a bitmap though?
|
|
<br><b>eks|x:</b> don: seems to me like the internals of the functions uses one bit
|
|
<br><b>Psyon:</b> Hmm...
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>Psyon:</b> You might have to do it manually
|
|
<br><b>uninet:</b> Manually?
|
|
<br><b>uninet:</b> How so?
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>eks|x:</b> bryce: afaik, The Gimp under X, or photoshop under Win
|
|
<br><b>Psyon:</b> picture an 16 by 16 square
|
|
<br><b>bryce:</b> what format? XBM ?
|
|
<br><b>eks|x:</b> bryce: monochrome bitmaps
|
|
<br><b>eks|x:</b> .bmp
|
|
<br><b>Psyon:</b> that would take 4 bytes to display
|
|
<br><b>Psyon:</b> wait
|
|
<br><b>eks|x:</b> Psyon: is the routine actually using whole byte of value 1 or 0 only?
|
|
<br><b>Psyon:</b> well
|
|
<br><b>Psyon:</b> it uses the bits
|
|
<br><b>Psyon:</b> not the bytes
|
|
<br><b>bryce:</b> that icon currently looks like this:
|
|
<br><b>bryce:</b> static unsigned char bochs_icon_bits[] = {
|
|
<br><b>bryce:</b> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff,
|
|
0x00,
|
|
<br><b>bryce:</b> 0xe0, 0xff, 0xff, 0x07, 0xf8, 0xff, 0xff, 0x1f, 0xf8, 0xff, 0xff,
|
|
0x1f,
|
|
<br><b>bryce:</b> 0xfc, 0xc7, 0xe3, 0x3f, 0xfc, 0xc7, 0xe3, 0x3f, 0xfc, 0xc3, 0xc3,
|
|
0x3f,
|
|
<br><b>bryce:</b> 0xfc, 0xc3, 0xc3, 0x3f, 0xf8, 0xc1, 0x83, 0x1f, 0xf0, 0xc0, 0x03,
|
|
0x0f,
|
|
<br><b>bryce:</b> 0x00, 0xc0, 0x03, 0x00, 0x00, 0xc0, 0x03, 0x00, 0x00, 0xc0, 0x03,
|
|
0x00,
|
|
<br><b>bryce:</b> 0x00, 0xc0, 0x03, 0x00, 0x00, 0xc0, 0x03, 0x00, 0x00, 0xc0, 0x03,
|
|
0x00,
|
|
<br><b>eks|x:</b> so a pic shouldn't be bigger than 32bytes
|
|
<br><b>bryce:</b> 0x00, 0xc0, 0x03, 0x00, 0x00, 0xc0, 0x03, 0x00, 0xf0, 0xc0, 0x03,
|
|
0x0f,
|
|
<br><b>bryce:</b> 0xf8, 0xc1, 0x83, 0x1f, 0xfc, 0xc3, 0xc3, 0x3f, 0xfc, 0xc3, 0xc3,
|
|
0x3f,
|
|
<br><b>bryce:</b> 0xfc, 0xc7, 0xe3, 0x3f, 0xfc, 0xc7, 0xe3, 0x3f, 0xf8, 0xff, 0xff,
|
|
0x1f,
|
|
<br><b>bryce:</b> 0xf8, 0xff, 0xff, 0x1f, 0xe0, 0xff, 0xff, 0x07, 0x00, 0xff, 0xff,
|
|
0x00,
|
|
<br><b>bryce:</b> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, };
|
|
<br><b>uninet:</b> So if you created a 1-bit picture in the gimp, and saved it as a bmp,
|
|
how would you get it in that format?
|
|
<br><b>Psyon:</b> make that into 1s and 0s
|
|
<br><b>Psyon:</b> and you will actually see the picture
|
|
<br><b>bryce:</b> no, BMP is not the same as a C header file!
|
|
<br><b>Psyon:</b> you have to convert that to a BMP
|
|
<br><b>eks|x:</b> tim: you need some tool that converts binary-:</b>c headers
|
|
<br><b>uninet:</b> eks|x: Hmm... do you know of a tool that can do that?
|
|
<br><b>eks|x:</b> tim: a search on freshmeat should do that for ya
|
|
<br><b>Psyon:</b> I could prolly make one
|
|
<br><b>eks|x:</b> tim: or wait, are ya under win?
|
|
<br><b>bryce:</b> this sort of crap is what a GUI toolkit should be doing for us
|
|
<br><b>bryce:</b> read BMP or GIF or something, and execute the right code for each
|
|
platform to make that the icon.
|
|
<br><b>eks|x:</b> bryce: right
|
|
<br><b>Psyon:</b> well... GTKs will want to use XPM or Jpg or PNG
|
|
<br><b>Psyon:</b> which would look nicer
|
|
<br><b>eks|x:</b> png seems fine to me
|
|
<br><b>uninet:</b> eks|x: Linux.
|
|
<br><b>eks|x:</b> tim: freshmeat.net -- solution for ya ;)
|
|
<br><b>bryce:</b> we are using a VERY low-level toolkit and that's why we have icons
|
|
that look like a C header file.
|
|
<br><b>Psyon:</b> I think we could easily convert this to use 256 color bitmaps
|
|
<br><b>uninet:</b> eks|x: thanks. I think I'll try my hands at creating some new bitmaps
|
|
then.
|
|
<br><b>uninet:</b> Psyon: that would be nice.
|
|
<br><b>Psyon:</b> each byte representing a color in the color table that bochs uses
|
|
<br><b>eks|x:</b> Psyon: normalized palette or each their owns?
|
|
<br><b>eks|x:</b> k
|
|
<br><b>Psyon:</b> normallized
|
|
<br><b>eks|x:</b> bochs palette
|
|
<br><b>Psyon:</b> bochs has an internal pallet
|
|
<br><b>Psyon:</b> Actually... looking at this
|
|
<br><b>eks|x:</b> btw, one annoying thing I've seen is the actual colors used when
|
|
displaying text in bochs (16 colors)
|
|
<br><b>Psyon:</b> the GUI code would all that needs to be changed
|
|
<br><b>Psyon:</b> just specify the bitmap the same way in the header
|
|
<br><b>eks|x:</b> is this palette easily modifiable?
|
|
<br><b>Psyon:</b> create_bitmap is just passed a pointer to the first byte
|
|
<br><b>Psyon:</b> the they dimensions of the pic
|
|
<br><b>Psyon:</b> so with a mono BMP
|
|
<br><b>Psyon:</b> the size of the pic is (X * Y) / 8
|
|
<br><b>Psyon:</b> but create images still wont be real easy
|
|
<br><b>Psyon:</b> the bytes in the .h files are not in BMP format
|
|
<br><b>uninet:</b> Hmm... I wonder how Kevin did it?
|
|
<br><b>bryce:</b> I'm going to sound like a broken record...
|
|
<br><b>Psyon:</b> he drew them out by hand
|
|
<br><b>bryce:</b> :)
|
|
<br><b>Psyon:</b> like an ASCII artist would
|
|
<br><b>bryce:</b> ....use a toolkit!
|
|
<br><b>Psyon:</b> why?
|
|
<br><b>Psyon:</b> Toolkits take up too much space
|
|
<br><b>Psyon:</b> :)
|
|
<br><b>eks|x:</b> eheh
|
|
<br><b>bryce:</b> a cross-platform GUI library has to deal with this problem
|
|
<br><b>uninet:</b> Psyon: So you would just put out hex symbols until they looked like
|
|
something?
|
|
<br><b>eks|x:</b> "let's write bochs in asm, so it can fit in 100kb"
|
|
<br><b>eks|x:</b> ;)
|
|
<br><b>bryce:</b> of icon image formats or whatever
|
|
<br><b>Psyon:</b> Yep
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>Psyon:</b> I think the current way of doing the GUI is nice
|
|
<br><b>Psyon:</b> its just the actuall GUIs
|
|
<br><b>Psyon:</b> that suck
|
|
<br><b>Psyon:</b> heheh
|
|
<br><b>eks|x:</b> don: any idea for that 16 colors palette used to display vga text?
|
|
<br><b>eks|x:</b> hard to fix?
|
|
<br><b>Psyon:</b> reword that
|
|
<br><b>eks|x:</b> well, clear white gets out as light blue..
|
|
<br><b>eks|x:</b> etc, colors are screwed
|
|
* eks|x should add a bug report..
|
|
<br><b>Psyon:</b> Hmm...
|
|
<br><b>uninet:</b> So most likely it would be easier to wait until we switch to a
|
|
toolkit to work on the icons?
|
|
<br><b>eks|x:</b> hrmm.. the vga color palette, when displaying text in the guest, gets
|
|
out wrong
|
|
<br><b>Psyon:</b> actually that standard VGA pallet kinda shows it as offwhite I think
|
|
<br><b>bryce:</b> Tim, IMHO yes :)
|
|
<br><b>Psyon:</b> and text looks fine to me
|
|
<br><b>eks|x:</b> Psyon: colors are screwed on my side
|
|
<br><b>uninet:</b> The text looks good to me too... just like a normal console.
|
|
<br><b>eks|x:</b> Psyon: light blue is dark blue
|
|
<br><b>uninet:</b> bryce: thanks.
|
|
<br><b>eks|x:</b> Psyon: white is light blue, etc
|
|
<br><b>Psyon:</b> It might be the GUI code then
|
|
<br><b>uninet:</b> eks|x: Are you running at 256 colors?
|
|
<br><b>Psyon:</b> each char on the screen is represented by 2 bytes
|
|
<br><b>bryce:</b> on X windows, my text colors are always messed up unless I quit
|
|
netscape first, and then run bochs
|
|
<br><b>Psyon:</b> one is the character
|
|
<br><b>Psyon:</b> and one is the format options
|
|
<br><b>eks|x:</b> tim: full 32bit color
|
|
<br><b>Psyon:</b> forground and background color
|
|
<br><b>Psyon:</b> you running in X or windows?
|
|
<br><b>eks|x:</b> X
|
|
<br><b>Psyon:</b> ok
|
|
<br><b>uninet:</b> eks|x: do the other apps around Bochs have weird colors too (when
|
|
bochs is running)?
|
|
<br><b>Psyon:</b> can you send me a screen?
|
|
<br><b>bryce:</b> I have 8-bit color I guess, so netscape sucks up all the available
|
|
colors , leaving my text purple or something
|
|
* eks|x is an anti-windows kindof guy ;)
|
|
<br><b>eks|x:</b> tim: nope, I can screw in The Gimp in full color no problem but bochs
|
|
is always screwed, alone or not
|
|
<br><b>bryce:</b> wierd
|
|
<br><b>eks|x:</b> the 0x07 color in text is fine
|
|
<br><b>eks|x:</b> the 0x01 color is very too dark
|
|
<br><b>eks|x:</b> and the 0x09 is like the 0x01 should normally be
|
|
<br><b>uninet:</b> eks|x: Hmm... could it be an misconfig with bochrc's pallet settings
|
|
(I think it can have a shared or internal pallet, IIRC)?
|
|
<br><b>eks|x:</b> 0x0F gets out as the original 0x09
|
|
<br><b>Psyon:</b> That is proably the internal bochs Pallet
|
|
<br><b>eks|x:</b> that's my guess too
|
|
<br><b>Psyon:</b> http://bochs.sourceforge.net/screenshot/freedos.png
|
|
<br><b>Psyon:</b> that screen shot looks fine
|
|
<br><b>Psyon:</b> so maybe its just you :)
|
|
<br><b>eks|x:</b> eheh
|
|
<br><b>Psyon:</b> actually it looks yellow
|
|
<br><b>Psyon:</b> http://bochs.sourceforge.net/screenshot/kidos.jpg
|
|
<br><b>Psyon:</b> but that one seems ok
|
|
<br><b>eks|x:</b> ehe
|
|
<br><b>Psyon:</b> I need to set up another linux box to play with bochs on
|
|
<br><b>Psyon:</b> I dont like to run it on my web server
|
|
<br><b>Psyon:</b> the X11 GUI uses XSetForeground and XSetBackground
|
|
<br><b>Psyon:</b> so it maybe a problem with those
|
|
<br><b>Psyon:</b> Yeah...
|
|
<br><b>Psyon:</b> looking over the X code
|
|
<br><b>Psyon:</b> I woudl say it is somethign with your X color pallet
|
|
<br><b>Psyon:</b> Did I say somethign wrong? everyone is quiet?
|
|
<br><i>*** Signoff: eks|x (h51.us.undernet.org McLean.VA.US.Undernet.Org)
|
|
<br>*** Signoff: bryce (h51.us.undernet.org McLean.VA.US.Undernet.Org)
|
|
<br>*** Signoff: uninet (h51.us.undernet.org McLean.VA.US.Undernet.Org)
|
|
<br>*** Signoff: Psyon (http://www.psyon.org -- It's all that and a Unix manual!)
|
|
<br>*** uninet (~tbutler@c1331724-a.schrls1.mo.home.com) has joined channel #Bochs
|
|
<br>*** Psyon (exodus@exodus.psyon.org) has joined channel #Bochs
|
|
<br>*** bryce (~bryce@debussy.ne.mediaone.net) has joined channel #Bochs</i>
|
|
<br><b>uninet:</b> Ah people are posting again... I thought everyone had left and my
|
|
client just didn't sense it.
|
|
<br><b>uninet:</b> Psyon: Thanks!
|
|
<br><b>Psyon:</b> Hmm..
|
|
<br><b>uninet:</b> Perhaps I can make sense of some of this.
|
|
<br><b>Psyon:</b> well that kinda explains why he did it that way
|
|
<br><b>Psyon:</b> In windows
|
|
<br><b>Psyon:</b> I an make it use 256 color bitmaps
|
|
<br><b>Psyon:</b> not sure how to do it in X11
|
|
<br><b>Psyon:</b> or Mac
|
|
<br><b>Psyon:</b> for that matter
|
|
<br><b>Psyon:</b> :)
|
|
<br><b>uninet:</b> :-)
|
|
<br><b>uninet:</b> I suppose this is a good reason for me to finally apply myself to
|
|
learn C.
|
|
<br><b>uninet:</b> This chat seems to be dying a slow death...
|
|
<br><b>bryce:</b> I'm back, sorry
|
|
<br><b>uninet:</b> Hey Bryce!
|
|
<br><b>bryce:</b> who's left
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>uninet:</b> eveyone besides myself and Don.
|
|
<br><b>Psyon:</b> me
|
|
<br><b>uninet:</b> (and you of course)
|
|
<br><b>bryce:</b> are you still talking about icons :)
|
|
<br><b>uninet:</b> Yup.
|
|
<br><b>Psyon:</b> Yeah, but we can change the subject to something more important
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>uninet:</b> Sounds good, I think I'll sit it out for the toolkit to be decided on
|
|
(if we even decide on one)
|
|
<br><b>bryce:</b> I'm hoping that someone has actual experience with a cross-platform
|
|
toolkit or is willing to learn
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>Psyon:</b> I can learn
|
|
<br><b>Psyon:</b> I guess
|
|
<br><b>bryce:</b> since we have bugs and features galore in addition to the gui to work
|
|
on too
|
|
<br><b>uninet:</b> The difficult thing is, there are lots of qualified people, but not
|
|
so many that actually know bochs.
|
|
<br><b>Psyon:</b> I know the bochs GUI parts
|
|
<br><b>Psyon:</b> at least the current way
|
|
<br><b>uninet:</b> I'd love to help... maybe I could help out somewhat...
|
|
<br><b>bryce:</b> I would say it doesn't matter if they know bochs, it only matters that
|
|
they care about it enough to spend some time on it
|
|
<br><b>bryce:</b> we need to help define the interface
|
|
<br><b>Psyon:</b> That is my big problem right now
|
|
<br><b>Psyon:</b> I have to kill some of my other projects
|
|
<br><b>Psyon:</b> and devot time to the major ones
|
|
<br><b>uninet:</b> killall *projects
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>bryce:</b> (we = people who do know bochs and know what the GUI needs to be able
|
|
to do)
|
|
<br><b>Psyon:</b> http://www.perlhq.com -- I have to keep stuff on that page updated.
|
|
<br><b>bryce:</b> my road map is:
|
|
<br><b>bryce:</b> fix up 1.2.pre1
|
|
<br><b>bryce:</b> then call it 1.2
|
|
<br><b>bryce:</b> put binaries of 1.2 everywhere under the sun
|
|
<br><b>Psyon:</b> hehehe
|
|
<br><b>bryce:</b> and then we have a chance at getting more people aware of the project
|
|
<br><b>uninet:</b> Sounds good.
|
|
<br><b>bryce:</b> I bet there are lots of people who stopped looking at www.bochs.com
|
|
during the last year
|
|
<br><b>uninet:</b> I'm suppose to get it up everywhere under the sun, right?
|
|
<br><b>bryce:</b> I'll be happy to help with that, once we have a 1.2 that we're proud
|
|
of.
|
|
<br><b>uninet:</b> It seems to me, you should be proud of the current 1.2, it's a lot
|
|
nicer being able to type bochs-dlx immediately after install, and try it out!
|
|
<br><b>bryce:</b> :)
|
|
<br><b>Psyon:</b> I need to fix up the raw disk code a little
|
|
<br><b>bryce:</b> I'm nearly proud of it :)
|
|
<br><b>Psyon:</b> right now its a hack
|
|
<br><b>Psyon:</b> I need to make it proper
|
|
<br><b>uninet:</b> Will that be difficult?
|
|
<br><b>Psyon:</b> no
|
|
<br><b>Psyon:</b> It just assumes a size of the disk
|
|
<br><b>bryce:</b> well even having a 1.2 that makes people say "Wow that has a lot of
|
|
potential, I wonder if there's a new one" would be good enough
|
|
<br><b>Psyon:</b> _stat() on windows doesnt work when \\.\a: is opened
|
|
<br><b>Psyon:</b> just need to make it check to see if its using a raw disk or now
|
|
<br><b>Psyon:</b> not
|
|
<br><b>uninet:</b> bryce: I agree. If people see Bochs poping on Freshmeat and such
|
|
every few weeks, it might make people realize this project is alive!
|
|
<br><b>Psyon:</b> Just need to get disk info a diff way
|
|
<br><b>bryce:</b> psyon, do you have cvs?
|
|
<br><b>Psyon:</b> I can set it up again
|
|
<br><b>bryce:</b> it would probably help in staying current
|
|
<br><b>bryce:</b> or maybe CVS snapshots are better, I don't know
|
|
<br><b>Psyon:</b> oh
|
|
<br><b>Psyon:</b> you just mean to get the code
|
|
<br><b>bryce:</b> yes
|
|
<br><b>Psyon:</b> i thought you meant the CVS server
|
|
<br><b>bryce:</b> no we have one of those now
|
|
<br><b>Psyon:</b> I have CVS on the linux box
|
|
<br><b>Psyon:</b> Ill have to get a client for this one
|
|
<br><b>Psyon:</b> ive just been using snapshots
|
|
<br><b>bryce:</b> whatever works
|
|
<br><b>bryce:</b> if you are actively messing with the code, cvs update would be useful
|
|
<br><b>bryce:</b> random RFB thought: if we get networking going on bochs, you could run
|
|
vncserver within bochs and connect to it with a vncviewer on the real
|
|
machine, right?
|
|
<br><b>Psyon:</b> Yes
|
|
<br><b>bryce:</b> might be slow
|
|
<br><b>Psyon:</b> but it would work slowly
|
|
<br><b>uninet:</b> What is the difference between RFB and VNC again?
|
|
<br><b>Psyon:</b> RFB is the protolcol
|
|
<br><b>Psyon:</b> VNC is the program
|
|
<br><b>bryce:</b> RFB = request for Bochs?
|
|
<br><b>uninet:</b> Ah, I see... thanks. Sorry, I know that was a dump question.
|
|
<br><b>Psyon:</b> brb... potty break
|
|
<br><b>uninet:</b> hahaha
|
|
<br><b>uninet:</b> I don't know if that was what AT&T was thinking, but I think that is
|
|
a good explaination of that acronym
|
|
<br><b>bryce:</b> :)
|
|
<br><b>uninet:</b> Well, and then there were two.
|
|
<br><b>bryce:</b> I think it might be easy to put those few survey questions on a
|
|
SourceForge survey
|
|
<br><b>uninet:</b> That would be nice... to get a feel for the general opinions of the
|
|
Bochs community.
|
|
<br><b>Psyon:</b> ok
|
|
<br><b>Psyon:</b> bak
|
|
<br><b>bryce:</b> I first looked at the SF survey as a way to handle the testing forms,
|
|
and it really was not good for that, but for independent questions like
|
|
these, it would be fine.
|
|
<br><b>Psyon:</b> I just may be tooting my own horn... but I think bochs-RFB is a good
|
|
way to separate the emulator and the GUI :)
|
|
<br><b>uninet:</b> How do you set it up?
|
|
<br><b>Psyon:</b> bochs RFB?
|
|
<br><b>bryce:</b> tim: you have to be admin on the project
|
|
<br><b>uninet:</b> Don, I agree, I think RFB is a very good system of dividing the GUI
|
|
and emulator.
|
|
<br><b>bryce:</b> and then type in the questions and answers, it's all web form stuff
|
|
<br><b>uninet:</b> Psyon: I meant survey forms.
|
|
<br><b>uninet:</b> bryce: Ah... I see. That's why I couldn't figure out how to set up a
|
|
survey. :-)
|
|
<br><b>bryce:</b> Don: doesn't RFB imply that you are sending a bunch of pixels for each
|
|
VGA character, not just a single ascii code?
|
|
<br><b>Psyon:</b> Uhh... Yes
|
|
<br><b>uninet:</b> afk.
|
|
<br><b>Psyon:</b> We need to write our own proto to optimize it
|
|
<br><b>bryce:</b> did you have to "draw" the toolbar yourself?
|
|
<br><b>Psyon:</b> but I went with RFB
|
|
<br><b>Psyon:</b> since there are so many viewers
|
|
<br><b>Psyon:</b> yes I drew the toolbar
|
|
<br><b>Psyon:</b> but all teh GUIs do that
|
|
<br><b>bryce:</b> right
|
|
<br><b>Psyon:</b> I just draw it in the local frame buffer
|
|
<br><b>Psyon:</b> and send it like the rest of the screen updates
|
|
<br><b>bryce:</b> so if you were going to make a dialog box in Bochs-RFB, you would
|
|
really have to do it without benefit of any library.
|
|
<br><b>Psyon:</b> Right!
|
|
<br><b>bryce:</b> like a button, you have to render it, handle clicks to it, etc.
|
|
<br><b>Psyon:</b> yeah
|
|
<br><b>uninet:</b> back.
|
|
<br><b>Psyon:</b> I never said there werent draw backs
|
|
<br><b>Psyon:</b> but
|
|
<br><b>uninet:</b> Could the client vnc GUI use a toolkit to render a button?
|
|
<br><b>Psyon:</b> I was going for compatibility of the viewer
|
|
<br><b>bryce:</b> no a VNC client is VERY simple, right?
|
|
<br><b>Psyon:</b> VNC client just draws data sent to it
|
|
<br><b>uninet:</b> Yeah... could the RFB protocol be extended for "Boch Enhanced"
|
|
clients, while maintaing compatiblity with normal VNC clients?
|
|
<br><b>Psyon:</b> Hmm....
|
|
<br><b>Psyon:</b> Sure
|
|
<br><b>bryce:</b> VNC is open source right?
|
|
<br><b>Psyon:</b> RFB is event based
|
|
<br><b>Psyon:</b> Yep
|
|
<br><b>Psyon:</b> so adding new Events for Bochs Enhancements
|
|
<br><b>bryce:</b> have you seen Xvnc the VNC-X server for linux
|
|
<br><b>Psyon:</b> would work
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>uninet:</b> That way, an enhance client could do the fancy stuff like (dialog
|
|
boxes) where the normal VNC client could just continue doing what it does
|
|
now...
|
|
<br><b>Psyon:</b> We would be better off just modifying it all
|
|
<br><b>bryce:</b> Xvnc is portable, since it has no display code only networking code,
|
|
<br><b>Psyon:</b> and just base it on RFB
|
|
<br><b>Psyon:</b> It would be better to send a text update event and just send the chars
|
|
<br><b>Psyon:</b> but that will only work while in a text mode
|
|
<br><b>Psyon:</b> when In windows
|
|
<br><b>bryce:</b> it seems like you could hack their Xvnc so that you could use any X11
|
|
library you like
|
|
<br><b>Psyon:</b> Text would still have to be sent as images
|
|
<br><b>uninet:</b> bryce: I think you are right.
|
|
<br><b>Psyon:</b> You know...
|
|
<br><b>bryce:</b> the X11 library could be used to draw dialog boxes, handle all events,
|
|
etc. without having to rewrite low level gui code.
|
|
<br><b>Psyon:</b> I guess to extend RFB to work how we want it... you would only need to
|
|
add two events
|
|
<br><b>Psyon:</b> RFBEventGetUserInput or something to pop up a dialog box...
|
|
<br><b>Psyon:</b> that would be sent to the client
|
|
<br><b>Psyon:</b> RFBDialogItemEvent sent to the bochs server
|
|
<br><b>Psyon:</b> those would be followed by data as to which dialog item was acted on
|
|
<br><b>Psyon:</b> or what type of input to get
|
|
<br><b>uninet:</b> If the client and server where on one computer, would there be much
|
|
of a performance hit over the current system?
|
|
<br><b>Psyon:</b> There is a bit
|
|
<br><b>bryce:</b> yes
|
|
<br><b>Psyon:</b> Bochs-RFB runs slowly even on the same computer, because I have not
|
|
implemented compression yet
|
|
<br><b>Psyon:</b> and passing all the graphics through Winsock
|
|
<br><b>Psyon:</b> casues a bottlnet
|
|
<br><b>Psyon:</b> bottleneck
|
|
<br><b>uninet:</b> But if you did, do you think there would still be a hit?
|
|
<br><b>Psyon:</b> not as much
|
|
<br><b>bryce:</b> now bochs uses the lowest level APIs to draw graphics, and I think
|
|
anything else will be a performance hit.
|
|
<br><b>uninet:</b> bryce: that's true.
|
|
<br><b>Psyon:</b> Then why do you want to use a toolkit?
|
|
<br><b>bryce:</b> I'm advocating GUI libraries for dialogs and control panels and suc
|
|
<br><b>bryce:</b> such
|
|
<br><b>bryce:</b> NOT as a replacement for the current VGA display window
|
|
<br><b>Psyon:</b> oh
|
|
<br><b>Psyon:</b> ok
|
|
<br><b>bryce:</b> which is performance-critical
|
|
<br><b>uninet:</b> I still am not sure that Don's idea of using RFB to seperate the GUI
|
|
might not be the best way to go...
|
|
<br><b>uninet:</b> (no matter which toolkit is used)
|
|
<br><b>Psyon:</b> I dont think it is the best way to go
|
|
<br><b>Psyon:</b> I just think its a good start
|
|
<br><b>bryce:</b> it can be done, but I think a much higher-level communication between
|
|
bochs and gui is better
|
|
<br><b>Psyon:</b> the concept and idea
|
|
<br><b>Psyon:</b> did you put bochs-RFB in the CVS tree btw?
|
|
<br><b>uninet:</b> Right, it would need to be worked on, but the concept is good.
|
|
<br><b>bryce:</b> like gui says: "Hey Bochs, I want you to change the floppy disk to
|
|
/home/bryce/newimage.img"
|
|
<br><b>bryce:</b> and bochs says: "Ok, I did it"
|
|
<br><b>Psyon:</b> I dont think it should be done like that
|
|
<br><b>Psyon:</b> I think it should be done how the current toolbar is done
|
|
<br><b>Psyon:</b> bochs tells the GUI to make a button
|
|
<br><b>Psyon:</b> and gives it a function pointer
|
|
<br><b>bryce:</b> the RFB way would be more like, gui says: "hey they clicked on
|
|
312,12"
|
|
<br><b>Psyon:</b> to be called
|
|
<br><b>Psyon:</b> in this case
|
|
<br><b>Psyon:</b> it could be giving an ID
|
|
<br><b>Psyon:</b> and then when the Button or what ever is pushed
|
|
<br><b>Psyon:</b> it would tell bochs that button ID has been pushed
|
|
<br><b>Psyon:</b> and bochs will act on it
|
|
<br><b>bryce:</b> and bochs says "ok 312,12 looks like the reset button so now gui
|
|
should display an "Are you sure" message"
|
|
<br><b>Psyon:</b> Yes
|
|
<br><b>uninet:</b> that would work really well...
|
|
<br><b>bryce:</b> I like the fact that that's general, and higher level
|
|
<br><b>Psyon:</b> I dont think using the coords of the click is a good idea
|
|
<br><b>Psyon:</b> then we would be limited to using images again
|
|
<br><b>bryce:</b> but I'm afraid that a whole protocol like that will not give the GUI
|
|
(whoever has to turn the dialog into actual API calls)
|
|
<br><b>Psyon:</b> Hmm...
|
|
<br><b>uninet:</b> Well, on non image things, couldn't it say "hey the user clicked on
|
|
menuitem1"?
|
|
<br><b>bryce:</b> a chance to make a decent looking dialog
|
|
<br><b>Psyon:</b> uninet that is what I was thinking
|
|
<br><b>bryce:</b> psyon, so what type of messages should bochs be telling the gui?
|
|
<br><b>Psyon:</b> That is how the current one basically works
|
|
<br><b>uninet:</b> Ah.
|
|
<br><b>bryce:</b> buttons are easy, how about dialogs?
|
|
<br><b>Psyon:</b> The current way of doing it is a good concept
|
|
<br><b>Psyon:</b> it just needs improving
|
|
<br><b>Psyon:</b> Well...
|
|
<br><b>Psyon:</b> What are the types of dialogs that will be needed?
|
|
<br><b>Psyon:</b> Yes/No, File, OK
|
|
<br><b>Psyon:</b> what else?
|
|
<br><b>bryce:</b> For each of these devices (HD, CMOS, CDROM, Floppy), choose what
|
|
<br><b>Psyon:</b> well...
|
|
<br><b>Psyon:</b> just in general
|
|
<br><b>bryce:</b> a panic, debug, info, and error message should do?
|
|
<br><b>Psyon:</b> well...
|
|
<br><b>bryce:</b> crash, print, or ignore?
|
|
<br><b>uninet:</b> Config dialogs too, right?
|
|
<br><b>Psyon:</b> Oh yah
|
|
<br><b>Psyon:</b> i forgot the config stuff
|
|
<br><b>Psyon:</b> Hmm....
|
|
<br><b>bryce:</b> that's a complicated one, and I think you may end up with the best
|
|
looking dialog
|
|
<br><b>bryce:</b> if you send a very high level message, like "show the log options
|
|
dialog now"
|
|
<br><b>Psyon:</b> I would like to see the dialogs defined by bochs
|
|
<br><b>bryce:</b> rather than trying to make your protocol SO general that bochs can ask
|
|
for any kind of dialog it might need
|
|
<br><b>Psyon:</b> and just displayed by the GUI
|
|
<br><b>Psyon:</b> like have bochs send the GUI a template for the dialog
|
|
<br><b>Psyon:</b> and draw it based on that
|
|
<br><b>bryce:</b> basically like a web form?
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>Psyon:</b> HEY!
|
|
<br><b>bryce:</b> oh no!
|
|
<br><b>Psyon:</b> thats not a bad Idea
|
|
<br><b>Psyon:</b> use XML or HTML to do the dialogs
|
|
<br><b>bryce:</b> :)
|
|
<br><b>Psyon:</b> then when submited... data can be passed back to bochs in a URLENcoded
|
|
string
|
|
<br><b>uninet:</b> Couldn't the GUI have the config template on the GUI side rather than
|
|
have bochs send it to it?
|
|
<br><b>Psyon:</b> boot=c&hd=linux.img
|
|
<br><b>Psyon:</b> stuff like that
|
|
<br><b>Psyon:</b> uninet: the GUI wouldnt have to be updated as much if bochs told it
|
|
how to make it
|
|
<br><b>bryce:</b> It certainly could be done that way, and if you're very sneaky you
|
|
might use your browser as the viewer.
|
|
<br><b>Psyon:</b> Well... you wouldnt use it as the viewer
|
|
<br><b>Psyon:</b> cant draw the VGA screen to the browser
|
|
<br><b>Psyon:</b> well... you could push it to it
|
|
<br><b>Psyon:</b> as a streaming video
|
|
<br><b>bryce:</b> no, VGA screen is low level APIs as it is now
|
|
<br><b>bryce:</b> otherwise you add lots of overhead
|
|
<br><b>Psyon:</b> Could do
|
|
<br><b>bryce:</b> I mean the control panel
|
|
<br><b>uninet:</b> Well, if you were using the browser as teh viewer, couldn't the VGA
|
|
screen be shown in a Java applet and config handled by normal browser means?
|
|
<br><b>Psyon:</b> char *bx_gui::ShowDialog(XMLCode *gui);
|
|
<br><b>Psyon:</b> XMLCode beings XML or HTML code for the form
|
|
<br><b>bryce:</b> yes, but slowly! We don't need any more speed penalties here.
|
|
<br><b>Psyon:</b> and the return would be a string much like the QUERY_STRING of the web
|
|
form
|
|
<br><b>Psyon:</b> parsing would be a pain though
|
|
<br><b>Psyon:</b> and might make a performace hit
|
|
<br><b>bryce:</b> are you thinking of a custom viewer or an existing web browser?
|
|
<br><b>Psyon:</b> custom viewer
|
|
<br><b>bryce:</b> ok
|
|
<br><b>Psyon:</b> well... there are plenty of open source HTML viewers
|
|
<br><b>bryce:</b> I'm thinking nothing should go through this interface that is
|
|
performance critical anyway.
|
|
<br><b>Psyon:</b> could steal some code to rended the HTML forms
|
|
<br><b>uninet:</b> Although what toolkit would be used to render the HTML forms? :-)
|
|
<br><b>bryce:</b> anything performance critical should either go to the existing
|
|
low-level API, or logged directly to a file.
|
|
<br><b>Psyon:</b> What is with you people and toolkits?
|
|
<br><b>Psyon:</b> :)
|
|
<br><b>uninet:</b> I dunno... :-) I was just thinking you now have the same problem of
|
|
rendering lots of things, and the added complexity of an HTML rendering
|
|
layer.
|
|
<br><b>Psyon:</b> well... it would only be HTML forms
|
|
<br><b>Psyon:</b> not full HTML
|
|
<br><b>Psyon:</b> maybe that is a bad idea
|
|
<br><b>Psyon:</b> but its an idea
|
|
<br><b>uninet:</b> It sounds good to me, I was just thinking you still have to figure
|
|
out how to render the widgets on the form.
|
|
<br><b>bryce:</b> well you can write XML for a form that describes exactly what the GUI
|
|
needs
|
|
<br><b>bryce:</b> without it having to be standard HTML
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>Psyon:</b> and libXml is cross platform
|
|
<br><b>bryce:</b> but is any of this a benefit?
|
|
<br><b>Psyon:</b> hold on..
|
|
<br><b>Psyon:</b> let me clear something up.
|
|
<br><b>bryce:</b> ok
|
|
<br><b>uninet:</b> I guess that the GUI could be seperate, but still extensible.
|
|
<br><b>Psyon:</b> Will the GUI be a separate process... or the same one?
|
|
<br><b>Psyon:</b> we need to make a decision on that
|
|
<br><b>uninet:</b> I would think a seperate process would be better (better cross
|
|
platform support), but that's only me.
|
|
<br><b>bryce:</b> it could be either way
|
|
<br><b>Psyon:</b> before we go any farther
|
|
<br><b>bryce:</b> I think it's no problem to open a network socket between them,
|
|
although then you need portable socket code and some semblance of security
|
|
<br><b>Psyon:</b> Well, using XML for dialogs would benefit for remote viewers
|
|
<br><b>Psyon:</b> most all socket code is pretty close to the same
|
|
<br><b>Psyon:</b> in the sense that what if bochs is running on linux and being viewed
|
|
in windows
|
|
<br><b>Psyon:</b> or Vice Versa
|
|
<br><b>uninet:</b> The nice thing about seperate processes with network code is it
|
|
doesn't matter if the viewer is on the same computer or 2,000 miles away...
|
|
<br><b>Psyon:</b> Even if it is the same process
|
|
<br><b>Psyon:</b> it would work ok
|
|
<br><b>bryce:</b> ok, sockets are fine and same process or different process is fine
|
|
<br><b>Psyon:</b> Ok...
|
|
<br><b>bryce:</b> but it seems like there are disadvantages to sending XML too
|
|
<br><b>Psyon:</b> can we see any problems with using XML for dialogs?
|
|
<br><b>Psyon:</b> why?
|
|
<br><b>bryce:</b> as opposed to just saying "Ok gui, show dialog number 7"
|
|
<br><b>Psyon:</b> well... the XML code can be cached
|
|
<br><b>Psyon:</b> do like
|
|
<br><b>uninet:</b> Idea:
|
|
<br><b>uninet:</b> What if the GUI and Bochs sync on startup with the XML forms...
|
|
<br><b>bryce:</b> if you tell it "show #7" then you can make the dialog look as good as
|
|
possible for that system
|
|
<br><b>bryce:</b> which is not a hard task
|
|
<br><b>uninet:</b> ...so that once it was started, requests would just be show7, or what
|
|
ever.
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>Psyon:</b> thats what I was going to say
|
|
<br><b>bryce:</b> if you send it XML, then the viewer's job is to make anything in the
|
|
world look as good as possible, which is a hard task
|
|
<br><b>Psyon:</b> send the code with and ID number
|
|
<br><b>Psyon:</b> They only big problem im seeing with XMl is how to return data back to
|
|
bochs
|
|
<br><b>Psyon:</b> user URLEncoded strings would work
|
|
<br><b>bryce:</b> anything would work
|
|
<br><b>uninet:</b> Well, the nice thing about this too, is that even if the different
|
|
platforms had different GUIs using different toolkits (or lack of), the menus
|
|
and dialogs would look the same.
|
|
<br><b>bryce:</b> you have a binary connection, send bytes?
|
|
<br><b>bryce:</b> true
|
|
<br><b>Psyon:</b> I think we should just do the dialogs in XML one way or the other
|
|
<br><b>Psyon:</b> then we dont have to worry about crossplatform toolkits
|
|
<br><b>uninet:</b> Exactly.
|
|
<br><b>uninet:</b> Then the best toolkit for each platform could be used, rather than
|
|
simply the lowest common denominator.
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>bryce:</b> you do have to worry about writing a general form viewer for every
|
|
platform, which is not exactly simple
|
|
<br><b>Psyon:</b> Hmm...
|
|
<br><b>bryce:</b> nor, one might argue, in the realm of bochs development at all :)
|
|
<br><b>uninet:</b> True...
|
|
<br><b>bryce:</b> maybe we should FIND one rather than write one
|
|
<br><b>uninet:</b> Well, you could port the existing GUI to this system (without
|
|
configs), and then as voluteers appears willing to create an "enhanced
|
|
viewer" it could become available.
|
|
<br><b>Psyon:</b> we could make our own toolkit
|
|
<br><b>bryce:</b> aaaaaaaaah
|
|
<br><b>uninet:</b> :-)
|
|
<br><b>bryce:</b> :)
|
|
<br><b>uninet:</b> Well, unless we make our own toolkit, BTK (?), or keep bochs
|
|
toolkit-independant (where it uses the best gui for each platform)...
|
|
<br><b>Psyon:</b> You know... the whole cross platform thing is what is making this hard
|
|
<br><b>uninet:</b> ...there are going to be platform limitations based on the toolkit.
|
|
<br><b>Psyon:</b> I can think of a hundred ways to just do it in windows
|
|
<br><b>uninet:</b> Yup.
|
|
<br><b>bryce:</b> yup.
|
|
<br><b>bryce:</b> what is wrong with making the XML viewer in wxWindows which runs on
|
|
tons of platforms already?
|
|
<br><b>uninet:</b> That would be a good idea.
|
|
<br><b>uninet:</b> We could always aim to have more viewers (using other toolkits) later
|
|
on... but that would get the ball rolling.
|
|
<br><b>Psyon:</b> how does wxWindows look?
|
|
<br><b>bryce:</b> no idea
|
|
<br><b>uninet:</b> I think it looks like Windows in Windows, Motif or GTK in *nix...
|
|
<br><b>Psyon:</b> if the page will load
|
|
<br><b>bryce:</b> http://www.wxwindows.org/
|
|
<br><b>uninet:</b> http://www.wxwindows.org/samples.htm
|
|
<br><b>Psyon:</b> ok
|
|
<br><b>Psyon:</b> that looks ok
|
|
<br><b>Psyon:</b> I guess
|
|
<br><b>Psyon:</b> we can always mod it
|
|
<br><b>bryce:</b> it looks good to me, but I haven't seen the API
|
|
<br><b>Psyon:</b> and it runs on mac
|
|
<br><b>bryce:</b> but it's open source, C, and cross platform, that's a very good
|
|
start
|
|
<br><b>uninet:</b> It ain't beatiful, but if other GUI's could be written on the XML
|
|
framework, that wouldn't be a problem...
|
|
<br><b>Psyon:</b> If QT was opensource on all platforms
|
|
<br><b>Psyon:</b> I would go for that
|
|
<br><b>Psyon:</b> it has an XML renderer and everything
|
|
<br><b>uninet:</b> I hear it wouldn't be hard to get QT-free to work in Windows...
|
|
<br><b>Psyon:</b> Ive gotten it to work
|
|
<br><b>Psyon:</b> but it requires an X server
|
|
<br><b>uninet:</b> Really?
|
|
<br><b>uninet:</b> Oh.
|
|
<br><b>Psyon:</b> That is one of my other projects
|
|
<br><b>Psyon:</b> I found some code on the MS FTP
|
|
<br><b>bryce:</b> at the risk of being the devil's advocate all the time: why not write
|
|
gui/wxWindows.cc and compile it directly into bochs? Would this not be a
|
|
great starting point?
|
|
<br><b>Psyon:</b> that maps some Xlib functions to Win32 API
|
|
<br><b>uninet:</b> According to Mosfet (of KDE), it shouldn't be to hard to make it work
|
|
like TrollTech's QT for windows, since they are both from the same codebase.
|
|
<br><b>Psyon:</b> and I was working with that too
|
|
<br><b>Psyon:</b> Uninet: http://www.sourceforge.net/projects/kde-cygwin
|
|
<br><b>bryce:</b> well ok not a great one
|
|
<br><b>Psyon:</b> that guy talks about the problems with compiling KDE on windows
|
|
<br><b>Psyon:</b> bryce: that is a good start yes
|
|
<br><b>Psyon:</b> that is what we need is a start
|
|
<br><b>uninet:</b> If you compiled the wxWindows directly into Bochs, wouldn't that
|
|
limit the expansion into other toolkits?
|
|
<br><b>Psyon:</b> ok... have you guys looked at the bochs GUI functions yet? like
|
|
tile_update, create_bitmap, text_unpdate?
|
|
<br><b>uninet:</b> Wow! Don, I didn't know you were working on kde-cygwin! I just read
|
|
about that at KDE's The Dot the other day.
|
|
<br><b>Psyon:</b> any of them?
|
|
<br><b>Psyon:</b> Im not working on that
|
|
<br><b>Psyon:</b> thats not my projects
|
|
<br><b>Psyon:</b> I have been doing the same thing
|
|
<br><b>Psyon:</b> but thats not mine
|
|
<br><b>bryce:</b> no I haven't
|
|
<br><b>uninet:</b> Oh, I saw you are the developer list and assumed you were.
|
|
<br><b>Psyon:</b> I am?
|
|
<br><b>Psyon:</b> He added me?
|
|
<br><b>bryce:</b> haha
|
|
<br><b>uninet:</b> Yup.
|
|
<br><b>uninet:</b> You are.
|
|
<br><b>uninet:</b> http://sourceforge.net/project/memberlist.php?group_id=27249
|
|
<br><b>Psyon:</b> oh
|
|
<br><b>uninet:</b> Nothing like being on a project without being told about it, huh? ;-)
|
|
<br><b>Psyon:</b> ok
|
|
<br><b>Psyon:</b> :)
|
|
<br><b>Psyon:</b> I emailed the guy a few times
|
|
<br><b>Psyon:</b> and discussed some things with him
|
|
<br><b>Psyon:</b> that is what takes up a lot of my time
|
|
<br><b>Psyon:</b> im fighting against MS in my own way
|
|
<br><b>uninet:</b> :-)
|
|
<br><b>Psyon:</b> I figure by making KDE (or more importantly, Konqueror
|
|
<br><b>bryce:</b> aren't we all.
|
|
<br><b>Psyon:</b> ) run in windows
|
|
<br><b>Psyon:</b> that strikes a blow against IE
|
|
<br><b>Psyon:</b> :)
|
|
<br><b>uninet:</b> I'd love to see Konqi in Windows.
|
|
<br><b>uninet:</b> How's it going with that project?
|
|
<br><b>Psyon:</b> Its going ok
|
|
<br><b>Psyon:</b> I mostly was trying to make QT/Free compile in cygwin
|
|
<br><b>Psyon:</b> which I did fine as a static lib
|
|
<br><b>Psyon:</b> but had troubles making shared
|
|
<br><b>Psyon:</b> but Ralf succeeded where I failed
|
|
<br><b>Psyon:</b> and got that to work
|
|
<br><b>uninet:</b> So, would it be hard to get QT/Free to work well enough in Windows
|
|
that it could be used for the Bochs toolkit?
|
|
<br><b>Psyon:</b> It will work with an X server now
|
|
<br><b>Psyon:</b> as to make it work without one
|
|
<br><b>Psyon:</b> im looking into it
|
|
<br><b>Psyon:</b> I dont know exactly how dependant QT/Free is on X
|
|
<br><b>Psyon:</b> Its a lot of code to look over
|
|
<br><b>Psyon:</b> I know they tried to keep is as OS independant as possible
|
|
<br><b>uninet:</b> It seems to me QT would be better than wxWindows in that you would
|
|
also add QT/Embedded (which comes in a "free" version) to the platforms Bochs
|
|
could run on...
|
|
<br><b>Psyon:</b> QT/Embedded draws directly to the FrameBuffer of your graphics card
|
|
<br><b>Psyon:</b> and wouldnt work in windows
|
|
<br><b>bryce:</b> not being free is a big problem though, as good as QT might be
|
|
<br><b>uninet:</b> Have you ever tried talking to mosfet about it?
|
|
<br><b>Psyon:</b> oh
|
|
<br><b>Psyon:</b> nm
|
|
<br><b>Psyon:</b> mosfet?
|
|
<br><b>uninet:</b> He's at www.mosfet.org.
|
|
<br><b>Psyon:</b> Oh
|
|
<br><b>uninet:</b> He's the one that wrote that it wouldn't be hard to port QT/free to
|
|
natively run on windows.
|
|
<br><b>Psyon:</b> the KDE guys
|
|
<br><b>uninet:</b> yeah.
|
|
<br><b>Psyon:</b> Ive talked to some of them about it
|
|
<br><b>uninet:</b> It seems to me both Bochs and KDE could benefit if QT/free worked
|
|
natively under Win32... maybe some of the KDE folks could help. :-)
|
|
<br><b>Psyon:</b> heheh
|
|
<br><b>bryce:</b> hard to see how porting toolkits is in the scope of Bochs...
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>bryce:</b> this QT must be pretty amazing!
|
|
<br><b>uninet:</b> Well, I was just thinking if Don had already been investigating it...
|
|
<br><b>Psyon:</b> QT is nice
|
|
<br><b>uninet:</b> From my limited knowledge of it... it is.
|
|
<br><b>Psyon:</b> and has a lot of the functionality we need
|
|
<br><b>bryce:</b> how is it different from other GUI toolkits?
|
|
<br><b>Psyon:</b> HEY! anyways
|
|
<br><b>uninet:</b> It will also most likely be the toolkit of the future. Trolltech is
|
|
on an ambitious campaign to make it the defacto toolkit used in Universities.
|
|
<br><b>Psyon:</b> back to what I was saying before!!!
|
|
<br><b>bryce:</b> ok
|
|
<br><b>bryce:</b> XML?
|
|
<br><b>uninet:</b> ?
|
|
<br><b>Psyon:</b> Before we use QT or wxWindows
|
|
<br><b>Psyon:</b> ok
|
|
<br><b>Psyon:</b> now
|
|
<br><b>Psyon:</b> as I was saying
|
|
<br><b>Psyon:</b> right now bochs tells teh GUI code to add a bitmap to the toolbar
|
|
<br><b>Psyon:</b> got that part?
|
|
<br><b>Psyon:</b> well...
|
|
<br><b>uninet:</b> yes.
|
|
<br><b>bryce:</b> yes
|
|
<br><b>Psyon:</b> we would need to add something
|
|
<br><b>Psyon:</b> that tells it to add a menu item
|
|
<br><b>Psyon:</b> or a button
|
|
<br><b>Psyon:</b> or whatever
|
|
<br><b>uninet:</b> right.
|
|
<br><b>bryce:</b> right.
|
|
<br><b>Psyon:</b> we have to do that before we make it use QT or wxWindows
|
|
<br><b>uninet:</b> I'm still with you there.
|
|
<br><b>Psyon:</b> bx_gui_c::add_menu_item
|
|
<br><b>bryce:</b> I would have said "as" rather than "before"
|
|
<br><b>Psyon:</b> then in that function
|
|
<br><b>Psyon:</b> call the TK function to add the item
|
|
<br><b>bryce:</b> no way to test it until you have something to hook it to, but go on
|
|
<br><b>Psyon:</b> well
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>uninet:</b> So in essence, this would become a compatiblity layer between bochs
|
|
and what ever toolkit, right?
|
|
<br><b>Psyon:</b> This keeps the same concept the the current GUI structure... but adds
|
|
more functionality
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>Psyon:</b> and we would d something like bx_gui_c::do_dialog()
|
|
<br><b>bryce:</b> right, we need to make the C calls look more like the interface
|
|
between bochs and the XML thing will eventually look
|
|
<br><b>Psyon:</b> or something
|
|
<br><b>uninet:</b> gotcha.
|
|
<br><b>Psyon:</b> This doesnt push us towards having a separate GUI and Emu
|
|
<br><b>Psyon:</b> but It does get us going towards user friendly
|
|
<br><b>Psyon:</b> which I think is more important
|
|
<br><b>bryce:</b> yes
|
|
<br><b>uninet:</b> right.
|
|
<br><b>Psyon:</b> and again, you could always recompile with Bochs-RFB :)
|
|
<br><b>uninet:</b> :-)
|
|
<br><b>Psyon:</b> also... the menu items should not be critical to bochs running
|
|
<br><b>Psyon:</b> incase a GUI cant create them
|
|
<br><b>Psyon:</b> like the curses one
|
|
<br><b>uninet:</b> right.
|
|
<br><b>bryce:</b> sure. (btw, yes rfb is in CVS, and in fact in 1.2.pre1)
|
|
<br><b>Psyon:</b> oooh... good
|
|
<br><b>Psyon:</b> now I can put Bochs Developer on my resume :)
|
|
<br><b>Psyon:</b> hehehehe
|
|
<br><b>uninet:</b> :-)
|
|
<br><b>bryce:</b> :)
|
|
<br><b>Psyon:</b> http://www.psyon.org/resume/index.html --- well it needs some spicing
|
|
up
|
|
<br><b>uninet:</b> a good thing considering we are still in the No. 2 slot on SF.
|
|
<br><b>Psyon:</b> I suck at resumes.
|
|
<br><b>Psyon:</b> I dont like to look at that
|
|
<br><b>Psyon:</b> but anways
|
|
<br><b>Psyon:</b> so what would we need implemented... add_menu_item, show_dialog,
|
|
add_button?
|
|
<br><b>Psyon:</b> something along those lines?
|
|
<br><b>uninet:</b> Sounds good to me...
|
|
<br><b>bryce:</b> well are we going toward XML already, or waiting until later?
|
|
<br><b>uninet:</b> Psyon: your resume actually looks good.
|
|
<br><b>Psyon:</b> The layout is good... the content sucks
|
|
<br><b>Psyon:</b> hmm...
|
|
<br><b>uninet:</b> It seems to me, if you can do it with something simpler than XML, why
|
|
not?
|
|
<br><b>Psyon:</b> bryce: if we are keeping the current way of doing the GUI
|
|
<br><b>Psyon:</b> lets wait till later
|
|
<br><b>Psyon:</b> Well...
|
|
<br><b>Psyon:</b> hmm...
|
|
<br><b>bryce:</b> yeah, it's tricky
|
|
<br><b>Psyon:</b> then how should we do dialogs
|
|
<br><b>Psyon:</b> I think we will have to
|
|
<br><b>Psyon:</b> to do the dialogs
|
|
<br><b>uninet:</b> Couldn't XML be sandwiched in as an additional layer, if it was ever
|
|
needed?
|
|
<br><b>Psyon:</b> well... again... if this was all os specific, we could have each GUI
|
|
with its own menu, and its own dialogs
|
|
<br><b>Psyon:</b> I think we will have to look into XML
|
|
<br><b>Psyon:</b> to do the dialogs
|
|
<br><b>bryce:</b> yes, and I wonder if that's even the best way to do it...later.
|
|
<br><b>Psyon:</b> Unless!
|
|
<br><b>Psyon:</b> we do a separate function for each needed dialog
|
|
<br><b>bryce:</b> once you have 3 dialogs coded in your new toolkit
|
|
<br><b>Psyon:</b> show_config
|
|
<br><b>Psyon:</b> hmm...
|
|
<br><b>bryce:</b> it will then be easy to write XML that can reproduce those dialogs
|
|
<br><b>bryce:</b> but without any examples to work from, you have a very general, very
|
|
hard task in writing the XML parser
|
|
<br><b>bryce:</b> without any XML code to try it with
|
|
<br><b>uninet:</b> At the risk of sounding stupid, what would be the advantage of XML
|
|
over sending the info without XML?
|
|
<br><b>Psyon:</b> we could do, show_config() show_change_disk() and stuff like that
|
|
<br><b>bryce:</b> (not writing the xml parser)
|
|
<br><b>Psyon:</b> XML is a standard
|
|
<br><b>Psyon:</b> well... what would be better
|
|
<br><b>Psyon:</b> having one function called to show all dialogs
|
|
<br><b>uninet:</b> True... but would that necessarily be beneficial in this case?
|
|
<br><b>Psyon:</b> or a separate one for each
|
|
<br><b>bryce:</b> I think doing show_config() and show_change_disk() is a good start
|
|
<br><b>uninet:</b> me too.
|
|
<br><b>Psyon:</b> so a separate one
|
|
<br><b>Psyon:</b> and when we call add_menu_item (or whatever) it will contain a
|
|
function pointer... which coudl be a pointer to show_blah_dialog directly
|
|
<br><b>uninet:</b> right...
|
|
<br><b>bryce:</b> something like that
|
|
<br><b>Psyon:</b> ok
|
|
<br><b>bryce:</b> that will get us going
|
|
<br><b>Psyon:</b> so who is in chareg of getting this started :)
|
|
<br><b>Psyon:</b> hehehe
|
|
<br><b>Psyon:</b> Im guessing im the candidate?
|
|
<br><b>uninet:</b> Idea: for an XML parser (if needed) could you take the one out of QT
|
|
and make it independant?
|
|
<br><b>bryce:</b> I think once we have some concrete examples of dialogs, it will be
|
|
much more clear what the XML should look like.
|
|
<br><b>uninet:</b> I vote for you.
|
|
<br><b>Psyon:</b> uni: ive been thinking of that already
|
|
<br><b>uninet:</b> (psyon)
|
|
<br><b>bryce:</b> :)
|
|
<br><b>uninet:</b> Psyon: we seem to be thinking along the same lines a lot tonight.
|
|
<br><b>Psyon:</b> I will warn you guys that I will be out of town from the 8th till the
|
|
14th of june
|
|
<br><b>Psyon:</b> hehe
|
|
<br><b>bryce:</b> I guess it better be done by the 8th then ;-)
|
|
<br><b>Psyon:</b> Umm...
|
|
<br><b>Psyon:</b> i doubt it
|
|
<br><b>Psyon:</b> maybe a start
|
|
<br><b>Psyon:</b> but not finished
|
|
<br><b>uninet:</b> Sounds like a good idea... that's a whole 9 days!
|
|
<br><b>Psyon:</b> the functions them selves wont be hard to add
|
|
<br><b>Psyon:</b> its the dialogs that will be a pain
|
|
<br><b>bryce:</b> right
|
|
<br><b>uninet:</b> And the dialogs themselves will require settling on a starting point
|
|
GUI, right?
|
|
<br><b>bryce:</b> if we are using CVS, it's much easier to collaborate
|
|
<br><b>uninet:</b> (or rather toolkit)
|
|
<br><b>bryce:</b> so that one person doesn't have to do everything alone and send a diff
|
|
when he's done
|
|
<br><b>Psyon:</b> the current calls to create the toolbar are hard coded
|
|
<br><b>Psyon:</b> so this wont be hard at all to implement the stufs
|
|
<br><b>Psyon:</b> stubs
|
|
<br><b>uninet:</b> So, you could stick with the hardcoded with the new implementation
|
|
until you settled on a toolkit(s)?
|
|
<br><b>Psyon:</b> yes
|
|
<br><b>bryce:</b> do you think we should leave the icons alone for now?
|
|
<br><b>bryce:</b> maybe that was the same question
|
|
<br><b>Psyon:</b> My one problem here is how do different toolkits handle sub menus?
|
|
<br><b>Psyon:</b> icons are staying for now
|
|
<br><b>bryce:</b> ok
|
|
<br><b>uninet:</b> I'd be happy to make new icons (if you want) but perhaps we should
|
|
wait until something like wxWindows or QT comes into the picture...
|
|
<br><b>Psyon:</b> Probably just change that over to a toolbar with buttons later
|
|
<br><b>bryce:</b> I think between the two we should at least try wxWindows since it
|
|
already runs on win32
|
|
<br><b>bryce:</b> (without hacking necessary)
|
|
<br><b>Psyon:</b> heheh
|
|
<br><b>uninet:</b> true. The beauty of this system is that QT would still be an option
|
|
for an additional GUI afterwards..
|
|
<br><b>bryce:</b> one of the best benefits of separation of bochs and GUI is that they
|
|
can be _developed_ independently
|
|
<br><b>Psyon:</b> Yes
|
|
<br><b>uninet:</b> that's very true.
|
|
<br><b>bryce:</b> since the dialog code is the hard part, and connecting it to bochs is
|
|
easy
|
|
<br><b>bryce:</b> let's work together on the first few dialogs
|
|
<br><b>Psyon:</b> Ok guys, hate to do this
|
|
<br><b>Psyon:</b> but I need sleep
|
|
<br><b>bryce:</b> sleep??
|
|
<br><b>uninet:</b> What's that?
|
|
<br><b>Psyon:</b> My fiance is already pissed that I didnt go to bed with her earlier
|
|
<br><b>Psyon:</b> :)
|
|
<br><b>bryce:</b> *nod*
|
|
<br><b>Psyon:</b> I will work out a menu function
|
|
<br><b>Psyon:</b> in the morning or when ever
|
|
<br><b>uninet:</b> Hmm... man sleep says: "sleep - delay for a specified amount of time"
|
|
<br><b>Psyon:</b> Yep, im delaying
|
|
<br><b>uninet:</b> :-) Well good night Don! Sleep well.
|
|
<br><b>bryce:</b> good night!
|
|
<br><b>Psyon:</b> cya guys later</tt><BR><BR>
|
|
<i>And with Don heading off for the night, we concluded our very productive, first IRC chat at just past 10:30PM (PDT).</i> <BR><BR>
|
|
|
|
|
|
<!--content ends here -->
|
|
|
|
|
|
<!--#include virtual="includes/footer.txt" -->
|
|
|
|
|
|
Last Modified on <!--#flastmod file="mailinglists.html" -->.<BR>
|
|
|
|
<!--#include virtual="includes/cright.txt" -->
|
|
|
|
</BODY>
|
|
</HTML> |