2614 lines
160 KiB
HTML
2614 lines
160 KiB
HTML
|
<HTML>
|
||
|
|
<HEAD>
|
||
|
|
<TITLE>bochs: The Open Source IA-32 Emulation Project (Mailing Lists)</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> <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 te
|
||
|
|
sting 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&
|
||
|
|
nbsp;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 bu
|
||
|
|
g 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 pr
|
||
|
|
oblems in gui/nogui.cc, iodev/pci.cc
|
||
|
|
<br><b>bryce:</b> - removed extra pa
|
||
|
|
ren that broke SHOW_IPS
|
||
|
|
<br><b>bryce:</b> - HALT macro in&nb
|
||
|
|
sp;rombios.c causes a bochs panic (which can
|
||
|
|
be turned off
|
||
|
|
<br><b>bryce:</b> in .bochsrc)&nbs
|
||
|
|
p;instead of actually halting.
|
||
|
|
<br><b>bryce:</b> - added additional 
|
||
|
|
;check for null pointer in debugger exit rout
|
||
|
|
ine
|
||
|
|
<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&n
|
||
|
|
bsp;a symlink to /usr/bin would be good.
|
||
|
|
<br><b>yakovlev:</b> We should put in a fix f
|
||
|
|
or the timing.
|
||
|
|
<br><b>yakovlev:</b> No, it belongs in /usr/local/bin&n
|
||
|
|
bsp;on linux.
|
||
|
|
<br><b>MarkK:</b> I would have been happy with&nbs
|
||
|
|
p;finding it in a readme...
|
||
|
|
<br><b>bryce:</b> timing? as in bochs takes 100%&n
|
||
|
|
bsp;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&nbs
|
||
|
|
p;real time.
|
||
|
|
<br><b>yakovlev:</b> I had an idea on that on
|
||
|
|
e.
|
||
|
|
<br><b>bryce:</b> I agree that's important, but I&
|
||
|
|
nbsp;think not for the 1.2
|
||
|
|
<br><b>bryce:</b> I'm thinking bug fixes only, bas
|
||
|
|
ically, 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&nb
|
||
|
|
sp;release of any existing feature improvements?
|
||
|
|
<br><b>yakovlev:</b> essentially?
|
||
|
|
<br><b>bryce:</b> right. here's what I was thinkin
|
||
|
|
g 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&nbs
|
||
|
|
p;only the authors have tried
|
||
|
|
<br><b>bryce:</b> and finally the ability to make&
|
||
|
|
nbsp;RPMS and win32 binaries
|
||
|
|
<br><b>bryce:</b> so I wanted as many people
|
||
|
|
as possible to be able to try the featur
|
||
|
|
es <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 fi
|
||
|
|
le
|
||
|
|
<br><b>bryce:</b> I'll paste them in now if y
|
||
|
|
ou want.
|
||
|
|
<br><b>yakovlev:</b> bochs-RFB I think is new in&n
|
||
|
|
bsp;1.2 also.
|
||
|
|
<br><b>MarkK:</b> not necessary....I can't run tonight&
|
||
|
|
nbsp;anyway
|
||
|
|
<br><b>MarkK:</b> I'll look at the tar file
|
||
|
|
<br><b>bryce:</b> there are some important ones, e
|
||
|
|
sp 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&nb
|
||
|
|
sp;has the log of changes too.
|
||
|
|
<br><b>yakovlev:</b> Ugh, I'd really like to get&n
|
||
|
|
bsp;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&n
|
||
|
|
bsp;be 1.2.pre1 with a few bug fixes
|
||
|
|
<br><b>uninet:</b> Sounds reasonable.
|
||
|
|
<br><b>bryce:</b> and anything major should go int
|
||
|
|
o 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 f
|
||
|
|
or the big stuff.
|
||
|
|
<br><b>yakovlev:</b> but, it's an incremental improveme
|
||
|
|
nt.
|
||
|
|
<br><b>bryce:</b> I should say pretty early on,&nb
|
||
|
|
sp;I have only worked on projects of 2-3
|
||
|
|
people before and have not done this kind&nbs
|
||
|
|
p;of thing before, so I'm learning as I go.
|
||
|
|
<br><b>MarkK:</b> so far I must say I'm REALL
|
||
|
|
Y impressed here though
|
||
|
|
<br><b>MarkK:</b> I'm participating on some much l
|
||
|
|
arger projects
|
||
|
|
<br><b>MarkK:</b> and they're no where as organize
|
||
|
|
d
|
||
|
|
<br><b>MarkK:</b> (of course I don't really know&n
|
||
|
|
bsp;how many are participating here!!)
|
||
|
|
<br><b>bryce:</b> I hope to get more people i
|
||
|
|
nvolved in making decisions like when to do
|
||
|
|
releases, but here's what I was thinking for&
|
||
|
|
nbsp;the 1.2 thing
|
||
|
|
<br><b>bryce:</b> I wanted to get binary releases&
|
||
|
|
nbsp;out as soon as possible
|
||
|
|
<br><b>bryce:</b> since that will allow the most&n
|
||
|
|
bsp;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&nb
|
||
|
|
sp;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&
|
||
|
|
nbsp;cleanup, the .bochsrc cleanup, the I/O cleanup?
|
||
|
|
<br><b>uninet:</b> What would be the advantage of&
|
||
|
|
nbsp;a 1.1.2 binary release?
|
||
|
|
<br><b>bryce:</b> there's too much that should be&
|
||
|
|
nbsp;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&nb
|
||
|
|
sp;backport anything we want.
|
||
|
|
<br><b>bryce:</b> given enough time.
|
||
|
|
<br><b>yakovlev:</b> We had at least a few me
|
||
|
|
ssages on the list about people getting
|
||
|
|
HALT messages when things used to run fine.
|
||
|
|
<br><b>uninet:</b> Can't that be stopped in bochsr
|
||
|
|
c?
|
||
|
|
<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 recen
|
||
|
|
tly added.
|
||
|
|
*** Signoff: nolu (Read error: Connection timed&nb
|
||
|
|
sp;out) <br><b>yakovlev:</b> yup, that's the problem.
|
||
|
|
<br><b>bryce:</b> anything that has STOPPED working&nbs
|
||
|
|
p;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&
|
||
|
|
nbsp;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 Bochsr
|
||
|
|
c 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 pos
|
||
|
|
sibly easy workaround.
|
||
|
|
<br><b>bryce:</b> Tim, the HALTs now produce a&nbs
|
||
|
|
p;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&nb
|
||
|
|
sp;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&
|
||
|
|
nbsp;wouldn't make a difference.
|
||
|
|
<br><b>bryce:</b> we should distinguish between the&nbs
|
||
|
|
p;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&nb
|
||
|
|
sp;of the bios with HALT defined to be n
|
||
|
|
op.
|
||
|
|
<br><b>bryce:</b> the HALT macro was broken until&
|
||
|
|
nbsp;1.2.pre1, it did absolutely nothing
|
||
|
|
<br><b>yakovlev:</b> Which was good from a user&nb
|
||
|
|
sp;perspective, bad from a debugging one.
|
||
|
|
<br><b>bryce:</b> the hlt instruction halts the bo
|
||
|
|
chs 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&nb
|
||
|
|
sp;here's what it does now:
|
||
|
|
<br><b>yakovlev:</b> Right, and I'm just saying I&
|
||
|
|
nbsp;don't want to have to disable all
|
||
|
|
hlts, just the one in HALT.
|
||
|
|
<br><b>bryce:</b> the HALT macro causes bochs to&n
|
||
|
|
bsp;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 t
|
||
|
|
he x86 hlt
|
||
|
|
<br><b>yakovlev:</b> oh, that's somewhat better.
|
||
|
|
<br><b>bryce:</b> this lets you control what happe
|
||
|
|
ns through the bochsrc by saying
|
||
|
|
"panic: action=fatal" or "panic: action=report"
|
||
|
|
<br><b>bryce:</b> do you think that's an ok b
|
||
|
|
ehavior 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 bei
|
||
|
|
ng 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 capabili
|
||
|
|
ty 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 .b
|
||
|
|
ochsrc syntax to specify this
|
||
|
|
<br><b>yakovlev:</b> could we define the panics ca
|
||
|
|
used 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&
|
||
|
|
nbsp;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=repor
|
||
|
|
t, 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&n
|
||
|
|
bsp;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&
|
||
|
|
nbsp;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 th
|
||
|
|
is for us. <br><b>bryce:</b> :) <br><b>yakovlev:</b> yup.
|
||
|
|
<br><b>yakovlev:</b> just a minute, I like the&nbs
|
||
|
|
p;log idea. <br><b>yakovlev:</b> hmmmm...
|
||
|
|
<br><b>yakovlev:</b> what if we viewed these more&
|
||
|
|
nbsp;as commands.
|
||
|
|
<br><b>yakovlev:</b> so, we could use:
|
||
|
|
<br><b>yakovlev:</b> log: filename="outfile", panic=fatal, e
|
||
|
|
rror=report
|
||
|
|
<br><b>yakovlev:</b> log: obj=PIT, filename="outfile2", pani
|
||
|
|
c=report, info=report <br><b>yakovlev:</b> that's cleaner.
|
||
|
|
<br><b>yakovlev:</b> we'd have to decide just how&
|
||
|
|
nbsp;to parse different things.
|
||
|
|
<br><b>bryce:</b> so if you have no obj=X the
|
||
|
|
n 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&nbs
|
||
|
|
p;from earlier lines
|
||
|
|
<br><b>yakovlev:</b> we only have to specify part&
|
||
|
|
nbsp;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&n
|
||
|
|
bsp;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 coul
|
||
|
|
d do to keep separate runs in separate files?
|
||
|
|
<br><b>MarkK:</b> So that if you wanted to ru
|
||
|
|
n regression it would be easy
|
||
|
|
<br><b>bryce:</b> (let's continue the .bochsrc syntax&n
|
||
|
|
bsp;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&nbs
|
||
|
|
p;a %d or something
|
||
|
|
<br><b>bryce:</b> into the filename, and then spri
|
||
|
|
ntf some time stamp into the %d
|
||
|
|
<br><b>MarkK:</b> that's an idea
|
||
|
|
<br><b>yakovlev:</b> there are several ways to do&
|
||
|
|
nbsp;it.
|
||
|
|
<br><b>yakovlev:</b> the calling program could just&nbs
|
||
|
|
p;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&nb
|
||
|
|
sp;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 i
|
||
|
|
t but try to get more people to answer&n
|
||
|
|
bsp;it later on <br><b>yakovlev:</b> K.
|
||
|
|
<br><b>bryce:</b> it's at <a
|
||
|
|
href="http://bochs.sourceforge.net/ircsurvey.html">http://bochs.sourceforge.net/ircsurvey.html</a>
|
||
|
|
<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.&nbs
|
||
|
|
p; 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&nb
|
||
|
|
sp;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 enjoymen
|
||
|
|
t of running a PC in my PC. :-)
|
||
|
|
<br><b>uninet:</b> Future Bug fixes: bug 1. Featur
|
||
|
|
e Request: feature 8.
|
||
|
|
<br><b>bryce:</b> also to be able to watch th
|
||
|
|
e OS working (esp Linux since I can see&
|
||
|
|
nbsp;the source too)
|
||
|
|
<br><b>uninet:</b> (Mouse problems, and emulation speed
|
||
|
|
respectively)
|
||
|
|
<br><b>MarkK:</b> Chip Designer: Inteested in interfaci
|
||
|
|
gn it to my new design.
|
||
|
|
<br><b>MarkK:</b> bad spelling. ;-)
|
||
|
|
<br><b>bryce:</b> mark, are you allowed to say&nbs
|
||
|
|
p;what you're designing? :)
|
||
|
|
<br><b>MarkK:</b> Sort of....
|
||
|
|
<br><b>smapnipss:</b> i use bochs for os developme
|
||
|
|
nt
|
||
|
|
<br><b>MarkK:</b> I'm working on some leading edge
|
||
|
|
1394 stuff
|
||
|
|
<br><b>bryce:</b> I understand, I'm a chip designe
|
||
|
|
r 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 chips
|
||
|
|
et design, and how that might play in here
|
||
|
|
<br><b>uninet:</b> I'm feeling out numbered here...&nbs
|
||
|
|
p;I'm just a lowly web designer.
|
||
|
|
<br><b>bryce:</b> We're thinking about SMP chip de
|
||
|
|
signs <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&nb
|
||
|
|
sp;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&
|
||
|
|
nbsp;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 i
|
||
|
|
n 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&nbs
|
||
|
|
p;it out...
|
||
|
|
<br><b>uninet:</b> That would be nice. Would the&n
|
||
|
|
bsp;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 j
|
||
|
|
oined channel #Bochs <br><b>eks|x:</b> hi guys :)
|
||
|
|
<br><b>bryce:</b> sorry, I'm just trying to pictur
|
||
|
|
e the open source chip design...
|
||
|
|
People have talked about it, but it's hard&nb
|
||
|
|
sp;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 ou
|
||
|
|
r 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&nb
|
||
|
|
sp;bochs needs more speed before it needs IEE
|
||
|
|
E 1394 anyway...
|
||
|
|
<br><b>MarkK:</b> people are starting to do open&n
|
||
|
|
bsp;source Verilog
|
||
|
|
<br><b>yakovlev:</b> depends on how prevalent FPGAs&nbs
|
||
|
|
p;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 sidetr
|
||
|
|
acked. <br><b>MarkK:</b> yes <br><b>bryce:</b> good point :)
|
||
|
|
<br><b>bryce:</b> so I heard several votes for&nbs
|
||
|
|
p;better mouse support (bug1) <br><b>uninet:</b> Definately.
|
||
|
|
<br><b>eks|x:</b> what I would really appreciate i
|
||
|
|
s 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&nbs
|
||
|
|
p;to manage. Bochs must have the values 
|
||
|
|
;in
|
||
|
|
there somewhere, you just need printed out ri
|
||
|
|
ght?
|
||
|
|
<br><b>uninet:</b> bug3 sounds like a nice one&nbs
|
||
|
|
p;to fix too...
|
||
|
|
<br><b>bryce:</b> yes, bug3 is tough though
|
||
|
|
<br><b>bryce:</b> well maybe not tough, just lots&
|
||
|
|
nbsp;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&n
|
||
|
|
bsp;we made a portable way to read from
|
||
|
|
a cdrom disk image?
|
||
|
|
<br><b>yakovlev:</b> yes, but if we get the C
|
||
|
|
DROM model right, we're done.
|
||
|
|
<br><b>eks|x:</b> bryce: we have some 3D computing
|
||
|
|
code we try to work out in a gamin
|
||
|
|
g
|
||
|
|
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&nb
|
||
|
|
sp;too hard to implement, close to hdd model
|
||
|
|
<br><b>MarkK:</b> Bryce: So that part is under&nbs
|
||
|
|
p;feature 1?
|
||
|
|
<br><b>bryce:</b> not as convenient as the real&nb
|
||
|
|
sp;cdrom (need lots of disk space) but then
|
||
|
|
the job of reading the raw cd is left&nb
|
||
|
|
sp;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 t
|
||
|
|
here already.
|
||
|
|
<br><b>uninet:</b> Would it be possible to make&nb
|
||
|
|
sp;bochs pretend /dev/cdrom was a cdrom image?
|
||
|
|
<br><b>bryce:</b> I think we just need to und
|
||
|
|
erstand a few of the ioctls (maybe snatch
|
||
|
|
from linux kernel code or something) to see&n
|
||
|
|
bsp;how to read table of contents and stuff
|
||
|
|
<br><b>yakovlev:</b> well, it would take some look
|
||
|
|
ing, but basically, yes.
|
||
|
|
<br><b>eks|x:</b> just out of nowhere like that,&n
|
||
|
|
bsp;any of you familiar with 'bfe' ? ;)
|
||
|
|
<br><b>yakovlev:</b> We'd have to add the removabl
|
||
|
|
e media controls to the CDROM
|
||
|
|
interface, but even that isn't ridiculous.
|
||
|
|
<br><b>bryce:</b> eks: can you add that as a&
|
||
|
|
nbsp;feature request on SF? otherwise I prom
|
||
|
|
ise I'll forget. :)
|
||
|
|
<br><b>eks|x:</b> it's a nice addition to bochs&nb
|
||
|
|
sp;I think
|
||
|
|
<br><b>eks|x:</b> bryce: I can do that,sure :)
|
||
|
|
<br><b>bryce:</b> bfe: I looked at it once, a
|
||
|
|
nd 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 p
|
||
|
|
hysical I/O if you wanted to...
|
||
|
|
<br><b>yakovlev:</b> well, bochs needs to know if&
|
||
|
|
nbsp;a CD is there or not.
|
||
|
|
<br><b>eks|x:</b> bryce: yeah, I know, but it's&nb
|
||
|
|
sp;a good tool, I use it often, mostly t
|
||
|
|
o generate cpu-flow tracing in the history file
|
||
|
|
<br><b>bryce:</b> bfe is actually what started me&
|
||
|
|
nbsp;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&n
|
||
|
|
bsp;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 i
|
||
|
|
n installing new software
|
||
|
|
<br><b>yakovlev:</b> then maybe DISK_SEEK, DISK_READ, a
|
||
|
|
nd DISK_WRITE to complete the set.
|
||
|
|
<br><b>MarkK:</b> what's the interface look like b
|
||
|
|
etween the IDE controller and the HD/CDROM?
|
||
|
|
<br><b>bryce:</b> if I manage to make a large
|
||
|
|
r-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 th
|
||
|
|
e most important feature of a new GUI?
|
||
|
|
<br><b>bryce:</b> feature10: GUI for configuration and&
|
||
|
|
nbsp;runtime control <br><b>bryce:</b> oh I see
|
||
|
|
<br><b>bryce:</b> like what do you want the g
|
||
|
|
ui to do? <br><b>uninet:</b> Right.
|
||
|
|
<br><b>bryce:</b> Answer: everything.
|
||
|
|
<br><b>uninet:</b> Assuming that the GUI could hav
|
||
|
|
e 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 t
|
||
|
|
o push all the interface as far away
|
||
|
|
from bochs internals as possible. :)
|
||
|
|
<br><b>yakovlev:</b> Notice a recurring theme in m
|
||
|
|
y 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&
|
||
|
|
nbsp;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&nbs
|
||
|
|
p;be in a different library, but
|
||
|
|
that's the idea.
|
||
|
|
<br><b>uninet:</b> Well, actually one should be a&
|
||
|
|
nbsp;normal program that requires the
|
||
|
|
shared library that contains the other code,
|
||
|
|
right?
|
||
|
|
<br><b>yakovlev:</b> Also, I used "GUI code" very&
|
||
|
|
nbsp;loosely. <br><b>yakovlev:</b> right, tim.
|
||
|
|
<br><b>bryce:</b> no reason to require shared libr
|
||
|
|
ary, 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&
|
||
|
|
nbsp;#Bochs
|
||
|
|
<br><b>yakovlev:</b> Shared library good, but could&nbs
|
||
|
|
p;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&nb
|
||
|
|
sp;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&n
|
||
|
|
bsp;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&
|
||
|
|
nbsp;Perl? <br><b>Psyon:</b> Good that is my dept?
|
||
|
|
<br><b>bryce:</b> we're going reimplement all of b
|
||
|
|
ochs in perl. <br><b>Psyon:</b> oops
|
||
|
|
<br><b>uninet:</b> Yeah, if it is dynamically link
|
||
|
|
ed that would be good. That way the
|
||
|
|
GUI code could be switched without a recompil
|
||
|
|
e. <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&nb
|
||
|
|
sp;C <br><b>Psyon:</b> cant you?
|
||
|
|
<br><b>uninet:</b> :-) Maybe... it wouldn't require&nbs
|
||
|
|
p;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&nbs
|
||
|
|
p;definition... so anything that could be
|
||
|
|
considered "client code" right?
|
||
|
|
<br><b>eks|x:</b> btw, perl is an easy to wri
|
||
|
|
te 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 differen
|
||
|
|
t 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&nb
|
||
|
|
sp;Plex86 plugin structure?
|
||
|
|
<br><b>uninet:</b> Is the current GUI library dyna
|
||
|
|
mically loaded?
|
||
|
|
<br><b>bryce:</b> so with some makefile tricks we&
|
||
|
|
nbsp;could compile them as shared libraries.
|
||
|
|
<br><b>bryce:</b> not dynamic, no
|
||
|
|
<br><b>eks|x:</b> bryce: feature added on sf (fpu&
|
||
|
|
nbsp;stack dump) <br><b>bryce:</b> eks: thanks
|
||
|
|
<br><b>bryce:</b> uh, I don't know anything about&
|
||
|
|
nbsp;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&nbs
|
||
|
|
p;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 plu
|
||
|
|
gin <br><b>Psyon:</b> hehe
|
||
|
|
<br><b>Psyon:</b> uni: There are just certain func
|
||
|
|
tions that are needed to be
|
||
|
|
implemented for the GUI
|
||
|
|
<br><b>yakovlev:</b> Methinks plugins is going a l
|
||
|
|
ittle 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&nbs
|
||
|
|
p;shared library is not really an important
|
||
|
|
feature. it can be done on some platfor
|
||
|
|
ms and not on others, big deal.
|
||
|
|
<br><b>uninet:</b> I'm using plugins in the loose&
|
||
|
|
nbsp;sense of being able to swap in another
|
||
|
|
module without having to recompile (like Linux&nbs
|
||
|
|
p;kernel modules)
|
||
|
|
<br><b>bryce:</b> it reduces the size of the
|
||
|
|
binary, and maybe you can load up only t
|
||
|
|
he device models you want that time.
|
||
|
|
<br><b>Psyon:</b> the bad thing is that shared&nbs
|
||
|
|
p;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&nb
|
||
|
|
sp;using gui modules or gui using bochs module?
|
||
|
|
<br><b>Psyon:</b> and... DLLs in windows have to&n
|
||
|
|
bsp;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 t
|
||
|
|
o 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&nb
|
||
|
|
sp;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 r
|
||
|
|
un 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 w
|
||
|
|
ith it
|
||
|
|
<br><b>uninet:</b> eks|x: It would also be handy&n
|
||
|
|
bsp;if you wanted to use the console gui,
|
||
|
|
and then wanted an X11 gui.
|
||
|
|
<br><b>bryce:</b> modules might let you make a&nbs
|
||
|
|
p;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&
|
||
|
|
nbsp;from one to the other?
|
||
|
|
<br><b>Psyon:</b> How big is the compiled bochs&nb
|
||
|
|
sp;on linux?
|
||
|
|
<br><b>uninet:</b> eks|x: never. But I haven't act
|
||
|
|
ually even tried the console GUI yet.
|
||
|
|
<br><b>Psyon:</b> I havent looked at it in li
|
||
|
|
nux 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 boch
|
||
|
|
s
|
||
|
|
<br><b>bryce:</b> ls -[bryce@monster bochs-1.2.pre1]$ ls&nbs
|
||
|
|
p;-l bochs
|
||
|
|
<br><b>bryce:</b> -rwxrwxr-x 1 bryce  
|
||
|
|
; bryce 441036 May 30&nb
|
||
|
|
sp;22:44 bochs* <br><b>Psyon:</b> 384kb
|
||
|
|
<br><b>Psyon:</b> that is an out of the box&n
|
||
|
|
bsp;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&nb
|
||
|
|
sp;size, it's the ability to mix and match
|
||
|
|
parts that's powerful, right?
|
||
|
|
<br><b>yakovlev:</b> Well, it sounds like we want&
|
||
|
|
nbsp;a bochs executable which loads both a
|
||
|
|
GUI and a BOCHS module.
|
||
|
|
<br><b>uninet:</b> eks|x: the GUI module would pro
|
||
|
|
bably 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&n
|
||
|
|
bsp;binary would work on all of those GUI's.
|
||
|
|
<br><b>eks|x:</b> what about having a main binary&
|
||
|
|
nbsp;using a bochs module and a gui module?
|
||
|
|
<br><b>bryce:</b> you can do any of these, ho
|
||
|
|
wever you want.
|
||
|
|
<br><b>Psyon:</b> This is where having a separate&
|
||
|
|
nbsp;process for the viewer and the emu
|
||
|
|
comes into play
|
||
|
|
<br><b>Psyon:</b> that would make it easier to&nbs
|
||
|
|
p;switch the viewer type <br><b>yakovlev:</b> eks: jynx
|
||
|
|
<br><b>bryce:</b> bochs module with no debugger, o
|
||
|
|
ptimized 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 ni
|
||
|
|
ce reason for modules. RFB could be
|
||
|
|
used just by changing modules.
|
||
|
|
<br><b>yakovlev:</b> I actually don't like using s
|
||
|
|
hared 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 spee
|
||
|
|
d....
|
||
|
|
<br><b>yakovlev:</b> But compiling them separately woul
|
||
|
|
d 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 &
|
||
|
|
nbsp; 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 stati
|
||
|
|
c libraries, that would mean they need
|
||
|
|
to be recompiled for each change, right?
|
||
|
|
<br><b>bryce:</b> markk, are you thinking that sev
|
||
|
|
eral pcs would simulate it faster?
|
||
|
|
<br><b>yakovlev:</b> Eat up most of iodev, for&nbs
|
||
|
|
p;one.
|
||
|
|
<br><b>MarkK:</b> just thinking it might, in the&n
|
||
|
|
bsp;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&n
|
||
|
|
bsp;better later on...
|
||
|
|
*** Roadkill (~ondrej@baikonur.orbitec.com.au) has joined&nb
|
||
|
|
sp;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&nbs
|
||
|
|
p;to do some coding.
|
||
|
|
<br><b>MarkK:</b> and anotehr running the CPU mode
|
||
|
|
l...
|
||
|
|
<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&nb
|
||
|
|
sp;I
|
||
|
|
would need to wait and see how someone e
|
||
|
|
lse created a C gui for bochs first...
|
||
|
|
<br><b>yakovlev:</b> Mark, that's a lower down dis
|
||
|
|
tinction 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&nbs
|
||
|
|
p;these things. I'm afraid that bochs
|
||
|
|
spends very little time simulating the behavior&nb
|
||
|
|
sp;of the devices and TONS OF
|
||
|
|
TIME simulating all those complicated x86 instruct
|
||
|
|
ions.
|
||
|
|
<br><b>MarkK:</b> yes, and I think no time (m
|
||
|
|
aybe) simulating the chip set right now?
|
||
|
|
<br><b>Psyon:</b> I think if we are going to&
|
||
|
|
nbsp;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&n
|
||
|
|
bsp;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&nb
|
||
|
|
sp;says it is :)
|
||
|
|
<br><b>bryce:</b> but it's cross platform, all C&n
|
||
|
|
bsp;based, and open-source
|
||
|
|
<br><b>uninet:</b> Psyon: I was mainly thinking I&
|
||
|
|
nbsp;could port what ever free
|
||
|
|
crossplatform GUI came out to QT, after the&n
|
||
|
|
bsp;initial work was done. I've never
|
||
|
|
done a GUI before, so I probably couldn't&nbs
|
||
|
|
p;do the initial work.
|
||
|
|
<br><b>uninet:</b> All I can say is that it&n
|
||
|
|
bsp;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&nbs
|
||
|
|
p;the standard bochs GUIs are a problem
|
||
|
|
<br><b>yakovlev:</b> neither do I.
|
||
|
|
<br><b>Psyon:</b> using a GTK of some sort wo
|
||
|
|
uld still have code for Windows and X11
|
||
|
|
in it
|
||
|
|
<br><b>uninet:</b> Psyon: GTK for Windows isn't ve
|
||
|
|
ry 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&nb
|
||
|
|
sp;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&
|
||
|
|
nbsp;every so often
|
||
|
|
<br><b>uninet:</b> Wouldn't it also cause some pro
|
||
|
|
blems since it is C-based, where as I
|
||
|
|
think MS's commonctrls are C?
|
||
|
|
<br><b>Psyon:</b> do to the emulation, the time&nb
|
||
|
|
sp;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 yo
|
||
|
|
u 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 q
|
||
|
|
ueue of mouse and key events
|
||
|
|
<br><b>Psyon:</b> then bochs calls handle_events() in&n
|
||
|
|
bsp;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 th
|
||
|
|
e 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&nbs
|
||
|
|
p;like that
|
||
|
|
<br><b>Psyon:</b> and I was thinking about just&nb
|
||
|
|
sp;passing them to bochs as they come in
|
||
|
|
<br><b>Psyon:</b> but the window callback for even
|
||
|
|
ts is on a diff thread
|
||
|
|
<br><b>Psyon:</b> and I dont know if that wil
|
||
|
|
l 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 poten
|
||
|
|
tially worth moving from the GUI
|
||
|
|
layer into the general bochs layer.
|
||
|
|
<br><b>Psyon:</b> when there is heavy emulation be
|
||
|
|
ing 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 c
|
||
|
|
an be i guess
|
||
|
|
<br><b>yakovlev:</b> from what Don is saying, soun
|
||
|
|
ds like bochs instructions.
|
||
|
|
<br><b>bryce:</b> I'm afraid I need to look a
|
||
|
|
t it more to be able to know what i
|
||
|
|
s going on.
|
||
|
|
<br><b>Psyon:</b> // Called periodically (vga_update_interva
|
||
|
|
l in .bochsrc) so the// the
|
||
|
|
gui code can poll for keyboard, mouse, and&nb
|
||
|
|
sp;other// relevant events.
|
||
|
|
<br><b>eks|x:</b> I tend to agree with Greg t
|
||
|
|
hat it's bochs' instructions <br><b>Psyon:</b> There
|
||
|
|
<br><b>Psyon:</b> that is from Win32.cc in the&nbs
|
||
|
|
p;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_int
|
||
|
|
erval 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 f
|
||
|
|
ar 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 to
|
||
|
|
o, some day.
|
||
|
|
<br><b>Psyon:</b> I think that is a big part&
|
||
|
|
nbsp;of the useability problem
|
||
|
|
<br><b>uninet:</b> The GUI code is already seperat
|
||
|
|
ed into a different module, right?
|
||
|
|
<br><b>uninet:</b> (or rather library)
|
||
|
|
<br><b>Psyon:</b> how well does the mouse work&nbs
|
||
|
|
p;in X11?
|
||
|
|
<br><b>bryce:</b> greg and don said, what's wrong&
|
||
|
|
nbsp;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 cl
|
||
|
|
eanup 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 i
|
||
|
|
s 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&n
|
||
|
|
bsp;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&
|
||
|
|
nbsp;with the current gui ?
|
||
|
|
<br><b>Psyon:</b> I dont think anything is
|
||
|
|
<br><b>bryce:</b> and I think that's important to&
|
||
|
|
nbsp;hash out
|
||
|
|
<br><b>uninet:</b> So, theoretically, it wouldn't be&nb
|
||
|
|
sp;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 pan
|
||
|
|
ic. do you want to continue"
|
||
|
|
<br><b>Psyon:</b> hehehe
|
||
|
|
<br><b>bryce:</b> or "Now choose the disk image&nb
|
||
|
|
sp;you want to be in drive A:"
|
||
|
|
<br><b>Psyon:</b> I think a live register display&
|
||
|
|
nbsp;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&n
|
||
|
|
bsp;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 lo
|
||
|
|
adable <br><b>Psyon:</b> but im saying
|
||
|
|
<br><b>yakovlev:</b> copying the image file is awk
|
||
|
|
ward.
|
||
|
|
<br><b>Psyon:</b> the features are there to do&nbs
|
||
|
|
p;so
|
||
|
|
<br><b>bryce:</b> yeah, and then click the stupid&
|
||
|
|
nbsp;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&
|
||
|
|
nbsp;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&
|
||
|
|
nbsp;dialog box?
|
||
|
|
<br><b>yakovlev:</b> And you often forget to unmou
|
||
|
|
nt, or forget to remount.
|
||
|
|
<br><b>bryce:</b> IMHO, no GUI toolkit to write&nb
|
||
|
|
sp;in <br><b>yakovlev:</b> I see your point.
|
||
|
|
<br><b>Psyon:</b> Well... just make a new toolbar&
|
||
|
|
nbsp;button that lets you load a new image
|
||
|
|
<br><b>bryce:</b> psyon: should or shouldn't be ha
|
||
|
|
rd 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&nb
|
||
|
|
sp;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 tha
|
||
|
|
t statement. <br><b>Psyon:</b> Well
|
||
|
|
<br><b>Psyon:</b> functions that arent in the GUI&
|
||
|
|
nbsp;code
|
||
|
|
<br><b>bryce:</b> more toolbar buttons would be fi
|
||
|
|
ne, but I think we should use
|
||
|
|
wxWindows or Tk to allow us to write a&n
|
||
|
|
bsp;somewhat friendly set of controls for
|
||
|
|
disk changes, choosing how verbose the logging&nbs
|
||
|
|
p;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&nb
|
||
|
|
sp;points reduce the error rate
|
||
|
|
<br><b>eks|x:</b> easier to debug
|
||
|
|
<br><b>yakovlev:</b> I was thinking, what if we&nb
|
||
|
|
sp;used something like an STL dictionary
|
||
|
|
and/or list of parms that the GUI code g
|
||
|
|
ives 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&n
|
||
|
|
bsp;need any gui library, that's what I'm
|
||
|
|
getting at.
|
||
|
|
<br><b>yakovlev:</b> no, the GUI should get some&n
|
||
|
|
bsp;well thought-out interfaces, not
|
||
|
|
willy-nilly access to bochs internals.
|
||
|
|
<br><b>Psyon:</b> BAH! I cant find the function&nb
|
||
|
|
sp;that ejects it
|
||
|
|
<br><b>bryce:</b> IMHO just making all the interfa
|
||
|
|
ces to the GUI through public member
|
||
|
|
functions is a good way to "define the i
|
||
|
|
nterface" <br><b>yakovlev:</b> Sort of.
|
||
|
|
<br><b>bryce:</b> then the .h file for the ou
|
||
|
|
termose 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&nbs
|
||
|
|
p;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&nb
|
||
|
|
sp;only or does it need to be checked at
|
||
|
|
every function call?
|
||
|
|
<br><b>bryce:</b> I mean that the GUI can onl
|
||
|
|
y call public member functions of the
|
||
|
|
interface object, not that the GUI can call&n
|
||
|
|
bsp;public member functions of any
|
||
|
|
object it can find.
|
||
|
|
<br><b>uninet:</b> yakovlev: Right... the GUI doesn't&n
|
||
|
|
bsp;need access to everything.
|
||
|
|
<br><b>yakovlev:</b> Having a single .h file with&
|
||
|
|
nbsp;the functions that are allowed to be
|
||
|
|
accessed outside would be listed there.
|
||
|
|
<br><b>yakovlev:</b> acls was just saying that pub
|
||
|
|
lic 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 nam
|
||
|
|
e 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 lib
|
||
|
|
rary with only the .h file of one
|
||
|
|
bochs class, an interface object whose methods&nbs
|
||
|
|
p;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&nb
|
||
|
|
sp;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&nbs
|
||
|
|
p;:) <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&nbs
|
||
|
|
p;set of unorganized data. <br><b>Psyon:</b> hehe
|
||
|
|
<br><b>bryce:</b> maybe the first step will be&nbs
|
||
|
|
p;to clean up the interface between current
|
||
|
|
GUI library and the rest.
|
||
|
|
<br><b>uninet:</b> Question: if and when the GUI&n
|
||
|
|
bsp;gets a config dialog, how should it
|
||
|
|
decide whether to save changes to ~/bochsrc o
|
||
|
|
r 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 p
|
||
|
|
ermit runtime only changes.
|
||
|
|
<br><b>bryce:</b> bochsrc = some place to save&nbs
|
||
|
|
p;the settings that you like, in some form
|
||
|
|
<br><b>bryce:</b> so that you can get them ba
|
||
|
|
ck <br><b>yakovlev:</b> right.
|
||
|
|
<br><b>bryce:</b> and also send them to somebody&n
|
||
|
|
bsp;so they can duplicate your setup
|
||
|
|
<br><b>Psyon:</b> Would be nice to have something&
|
||
|
|
nbsp;like VMWare, so that when the program
|
||
|
|
starts it asks what configuration you wish to
|
||
|
|
load
|
||
|
|
<br><b>yakovlev:</b> Something which exists totally out
|
||
|
|
side 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&n
|
||
|
|
bsp;VERY nice.
|
||
|
|
<br><b>bryce:</b> greg, yes only that gui part&nbs
|
||
|
|
p;would be reading and writing the bochsrc
|
||
|
|
I think.
|
||
|
|
<br><b>uninet:</b> VMware has a very well thought&
|
||
|
|
nbsp;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&nbs
|
||
|
|
p;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 y
|
||
|
|
ou can start the program
|
||
|
|
<br><b>bryce:</b> and each one has its own .b
|
||
|
|
ochsrc, 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&nbs
|
||
|
|
p;power button on the toolbar
|
||
|
|
<br><b>uninet:</b> yakovlev: you would just want t
|
||
|
|
o copy the general ideas, hopefully
|
||
|
|
with enough improvements that the VMware people&nb
|
||
|
|
sp;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 co
|
||
|
|
nfig file as an argument... like "bochs
|
||
|
|
mysystem.rc" <br><b>Psyon:</b> if not
|
||
|
|
<br><b>bryce:</b> not sure if it works now, b
|
||
|
|
ut it would be useful sometimes
|
||
|
|
<br><b>Psyon:</b> yes
|
||
|
|
<br><b>Psyon:</b> that is something else that migh
|
||
|
|
t 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&
|
||
|
|
nbsp;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"&nbs
|
||
|
|
p;"diskc:blabla"
|
||
|
|
<br><b>Psyon:</b> I mostly look at the GUI co
|
||
|
|
de so im kinda dumb as to how the r
|
||
|
|
est works <br><b>Psyon:</b> hehe
|
||
|
|
<br><b>bryce:</b> I think we should be able t
|
||
|
|
o 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 interf
|
||
|
|
ace in the next few days and post it
|
||
|
|
to the list. It'll be VERY generic. &nb
|
||
|
|
sp;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&n
|
||
|
|
bsp;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&
|
||
|
|
nbsp;fun. <br><b>yakovlev:</b> :) <br><b>bryce:</b> good night
|
||
|
|
<br><b>Psyon:</b> night
|
||
|
|
*** Signoff: yakovlev (Java Chat http://www.undernet.or
|
||
|
|
g/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 don
|
||
|
|
e for a Menu system <br><b>Psyon:</b> basically
|
||
|
|
<br><b>eks|x:</b> Psyon: I think the bochs gfx&nbs
|
||
|
|
p;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&nb
|
||
|
|
sp;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&n
|
||
|
|
bsp;be worked out like the toolbar thing
|
||
|
|
<br><b>uninet:</b> eks|x: Wouldn't removing the icons&n
|
||
|
|
bsp;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 g
|
||
|
|
ui 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&n
|
||
|
|
bsp;bitmap ID returned by an
|
||
|
|
earlier function, the alignment (left or right),&n
|
||
|
|
bsp;and a pointer to a function
|
||
|
|
<br><b>eks|x:</b> what I would like to see, i
|
||
|
|
s 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&
|
||
|
|
nbsp;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&n
|
||
|
|
bsp;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&n
|
||
|
|
bsp;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&nb
|
||
|
|
sp;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 bo
|
||
|
|
chs 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&
|
||
|
|
nbsp;just 1bit bitmaps
|
||
|
|
<br><b>bryce:</b> we need to choose at what l
|
||
|
|
evel the gui/bochs interface should talk.
|
||
|
|
I guess this is what Greg said he would&
|
||
|
|
nbsp;work on <br><b>eks|x:</b> yeah, the rfc
|
||
|
|
<br><b>uninet:</b> Pyson: Win4Lin accomplishes fullscreen&nb
|
||
|
|
sp;by starting a new X session on
|
||
|
|
another tty, and then maximizing the window i
|
||
|
|
t's in...
|
||
|
|
<br><b>bryce:</b> but there is everything from: &n
|
||
|
|
bsp;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 t
|
||
|
|
oolkit 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&n
|
||
|
|
bsp;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&n
|
||
|
|
bsp;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 als
|
||
|
|
o 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&nbs
|
||
|
|
p;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 i
|
||
|
|
nternals 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 man
|
||
|
|
ually <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,&
|
||
|
|
nbsp;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 u
|
||
|
|
sing 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 t
|
||
|
|
his:
|
||
|
|
<br><b>bryce:</b> static unsigned char bochs_icon_bits[]&nbs
|
||
|
|
p;= {
|
||
|
|
<br><b>bryce:</b> 0x00, 0x00, 0x00, 0x00, 0
|
||
|
|
x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x00,
|
||
|
|
<br><b>bryce:</b> 0xe0, 0xff, 0xff, 0x07, 0
|
||
|
|
xf8, 0xff, 0xff, 0x1f, 0xf8, 0xff, 0xff, 0x1f,
|
||
|
|
<br><b>bryce:</b> 0xfc, 0xc7, 0xe3, 0x3f, 0
|
||
|
|
xfc, 0xc7, 0xe3, 0x3f, 0xfc, 0xc3, 0xc3, 0x3f,
|
||
|
|
<br><b>bryce:</b> 0xfc, 0xc3, 0xc3, 0x3f, 0
|
||
|
|
xf8, 0xc1, 0x83, 0x1f, 0xf0, 0xc0, 0x03, 0x0f,
|
||
|
|
<br><b>bryce:</b> 0x00, 0xc0, 0x03, 0x00, 0
|
||
|
|
x00, 0xc0, 0x03, 0x00, 0x00, 0xc0, 0x03, 0x00,
|
||
|
|
<br><b>bryce:</b> 0x00, 0xc0, 0x03, 0x00, 0
|
||
|
|
x00, 0xc0, 0x03, 0x00, 0x00, 0xc0, 0x03, 0x00,
|
||
|
|
<br><b>eks|x:</b> so a pic shouldn't be bigger&nbs
|
||
|
|
p;than 32bytes
|
||
|
|
<br><b>bryce:</b> 0x00, 0xc0, 0x03, 0x00, 0
|
||
|
|
x00, 0xc0, 0x03, 0x00, 0xf0, 0xc0, 0x03, 0x0f,
|
||
|
|
<br><b>bryce:</b> 0xf8, 0xc1, 0x83, 0x1f, 0
|
||
|
|
xfc, 0xc3, 0xc3, 0x3f, 0xfc, 0xc3, 0xc3, 0x3f,
|
||
|
|
<br><b>bryce:</b> 0xfc, 0xc7, 0xe3, 0x3f, 0
|
||
|
|
xfc, 0xc7, 0xe3, 0x3f, 0xf8, 0xff, 0xff, 0x1f,
|
||
|
|
<br><b>bryce:</b> 0xf8, 0xff, 0xff, 0x1f, 0
|
||
|
|
xe0, 0xff, 0xff, 0x07, 0x00, 0xff, 0xff, 0x00,
|
||
|
|
<br><b>bryce:</b> 0x00, 0x00, 0x00, 0x00, 0
|
||
|
|
x00, 0x00, 0x00, 0x00, };
|
||
|
|
<br><b>uninet:</b> So if you created a 1-bit
|
||
|
|
picture in the gimp, and saved it as a&n
|
||
|
|
bsp;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&nb
|
||
|
|
sp;picture
|
||
|
|
<br><b>bryce:</b> no, BMP is not the same as&
|
||
|
|
nbsp;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&nbs
|
||
|
|
p;converts binary-:</b>c headers
|
||
|
|
<br><b>uninet:</b> eks|x: Hmm... do you know of&nb
|
||
|
|
sp;a tool that can do that?
|
||
|
|
<br><b>eks|x:</b> tim: a search on freshmeat shoul
|
||
|
|
d 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,&nb
|
||
|
|
sp;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&nb
|
||
|
|
sp;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 <br><b>-- solution 
|
||
|
|
;for ya ;)
|
||
|
|
<br><b>bryce:</b> we are using a VERY low-level&nb
|
||
|
|
sp;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&
|
||
|
|
nbsp;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 i
|
||
|
|
n the color table that bochs uses
|
||
|
|
<br><b>eks|x:</b> Psyon: normalized palette or each&nbs
|
||
|
|
p;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 see
|
||
|
|
n 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 p
|
||
|
|
ointer 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&n
|
||
|
|
bsp;* Y) / 8
|
||
|
|
<br><b>Psyon:</b> but create images still wont be&
|
||
|
|
nbsp;real easy
|
||
|
|
<br><b>Psyon:</b> the bytes in the .h files a
|
||
|
|
re not in BMP format
|
||
|
|
<br><b>uninet:</b> Hmm... I wonder how Kevin did&n
|
||
|
|
bsp;it?
|
||
|
|
<br><b>bryce:</b> I'm going to sound like a b
|
||
|
|
roken 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&nb
|
||
|
|
sp;out hex symbols until they looked like
|
||
|
|
something?
|
||
|
|
<br><b>eks|x:</b> "let's write bochs in asm, so&nb
|
||
|
|
sp;it can fit in 100kb" <br><b>eks|x:</b> ;)
|
||
|
|
<br><b>bryce:</b> of icon image formats or whateve
|
||
|
|
r <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 c
|
||
|
|
olors 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&nb
|
||
|
|
sp;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, wh
|
||
|
|
en displaying text in the guest, gets
|
||
|
|
out wrong
|
||
|
|
<br><b>Psyon:</b> actually that standard VGA pallet&nbs
|
||
|
|
p;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&
|
||
|
|
nbsp;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 th
|
||
|
|
en
|
||
|
|
<br><b>uninet:</b> eks|x: Are you running at 256&n
|
||
|
|
bsp;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&nbs
|
||
|
|
p;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 T
|
||
|
|
he Gimp in full color no problem but boc
|
||
|
|
hs is always screwed, alone or not
|
||
|
|
<br><b>bryce:</b> wierd
|
||
|
|
<br><b>eks|x:</b> the 0x07 color in text is f
|
||
|
|
ine
|
||
|
|
<br><b>eks|x:</b> the 0x01 color is very too
|
||
|
|
dark
|
||
|
|
<br><b>eks|x:</b> and the 0x09 is like the 0x
|
||
|
|
01 should normally be
|
||
|
|
<br><b>uninet:</b> eks|x: Hmm... could it be an&nb
|
||
|
|
sp;misconfig with bochrc's pallet settings
|
||
|
|
(I think it can have a shared or interna
|
||
|
|
l pallet, IIRC)?
|
||
|
|
<br><b>eks|x:</b> 0x0F gets out as the original&nb
|
||
|
|
sp;0x09
|
||
|
|
<br><b>Psyon:</b> That is proably the internal boc
|
||
|
|
hs 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 li
|
||
|
|
nux box to play with bochs on
|
||
|
|
<br><b>Psyon:</b> I dont like to run it on&nb
|
||
|
|
sp;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? every
|
||
|
|
one is quiet?
|
||
|
|
*** Signoff: eks|x (h51.us.undernet.org McLean.VA.US.Underne
|
||
|
|
t.Org)
|
||
|
|
*** Signoff: bryce (h51.us.undernet.org McLean.VA.US.Underne
|
||
|
|
t.Org)
|
||
|
|
*** Signoff: uninet (h51.us.undernet.org McLean.VA.US.Undern
|
||
|
|
et.Org)
|
||
|
|
*** Signoff: Psyon (http://www.psyon.org <br><b>-- It's
|
||
|
|
all that and a Unix manual!)
|
||
|
|
*** uninet (~tbutler@c1331724-a.schrls1.mo.home.com) has joi
|
||
|
|
ned channel #Bochs
|
||
|
|
*** Psyon (exodus@exodus.psyon.org) has joined channel&
|
||
|
|
nbsp;#Bochs
|
||
|
|
*** bryce (~bryce@debussy.ne.mediaone.net) has joined c
|
||
|
|
hannel #Bochs
|
||
|
|
<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&nbs
|
||
|
|
p;some of this.
|
||
|
|
<br><b>Psyon:</b> well that kinda explains why he&
|
||
|
|
nbsp;did it that way <br><b>Psyon:</b> In windows
|
||
|
|
<br><b>Psyon:</b> I an make it use 256 color&
|
||
|
|
nbsp;bitmaps
|
||
|
|
<br><b>Psyon:</b> not sure how to do it in&nb
|
||
|
|
sp;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 r
|
||
|
|
eason for me to finally apply myself to
|
||
|
|
learn C.
|
||
|
|
<br><b>uninet:</b> This chat seems to be dying&nbs
|
||
|
|
p;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 icon
|
||
|
|
s :) <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&n
|
||
|
|
bsp;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 actu
|
||
|
|
al 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&
|
||
|
|
nbsp;galore in addition to the gui to work
|
||
|
|
on too
|
||
|
|
<br><b>uninet:</b> The difficult thing is, there a
|
||
|
|
re 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&nbs
|
||
|
|
p;could help out somewhat...
|
||
|
|
<br><b>bryce:</b> I would say it doesn't matter&nb
|
||
|
|
sp;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&nbs
|
||
|
|
p;now
|
||
|
|
<br><b>Psyon:</b> I have to kill some of my&n
|
||
|
|
bsp;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 bo
|
||
|
|
chs and know what the GUI needs to be&nb
|
||
|
|
sp;able to do)
|
||
|
|
<br><b>Psyon:</b> http://www.perlhq.com <br><b>-- I have&nbs
|
||
|
|
p;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 u
|
||
|
|
nder the sun <br><b>Psyon:</b> hehehe
|
||
|
|
<br><b>bryce:</b> and then we have a chance a
|
||
|
|
t getting more people aware of the project
|
||
|
|
<br><b>uninet:</b> Sounds good.
|
||
|
|
<br><b>bryce:</b> I bet there are lots of peo
|
||
|
|
ple who stopped looking at www.bochs.com
|
||
|
|
during the last year
|
||
|
|
<br><b>uninet:</b> I'm suppose to get it up e
|
||
|
|
verywhere 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 prou
|
||
|
|
d 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&nbs
|
||
|
|
p;after install, and try it out!
|
||
|
|
<br><b>bryce:</b> :)
|
||
|
|
<br><b>Psyon:</b> I need to fix up the raw&nb
|
||
|
|
sp;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 t
|
||
|
|
he 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"&nbs
|
||
|
|
p;would be good enough
|
||
|
|
<br><b>Psyon:</b> _stat() on windows doesnt work w
|
||
|
|
hen \\.\a: is opened
|
||
|
|
<br><b>Psyon:</b> just need to make it check
|
||
|
|
to see if its using a raw disk or n
|
||
|
|
ow <br><b>Psyon:</b> not
|
||
|
|
<br><b>uninet:</b> bryce: I agree. If people see&n
|
||
|
|
bsp;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 stayin
|
||
|
|
g current
|
||
|
|
<br><b>bryce:</b> or maybe CVS snapshots are bette
|
||
|
|
r, I don't know <br><b>Psyon:</b> oh
|
||
|
|
<br><b>Psyon:</b> you just mean to get the co
|
||
|
|
de <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 fo
|
||
|
|
r 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&nb
|
||
|
|
sp;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&n
|
||
|
|
bsp;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 w
|
||
|
|
hat 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&nb
|
||
|
|
sp;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 su
|
||
|
|
rvey as a way to handle the testing form
|
||
|
|
s,
|
||
|
|
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 ow
|
||
|
|
n horn... but I think bochs-RFB is a goo
|
||
|
|
d
|
||
|
|
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 o
|
||
|
|
n the project
|
||
|
|
<br><b>uninet:</b> Don, I agree, I think RFB
|
||
|
|
is a very good system of dividing the GU
|
||
|
|
I and emulator.
|
||
|
|
<br><b>bryce:</b> and then type in the questions&n
|
||
|
|
bsp;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&
|
||
|
|
nbsp;I couldn't figure out how to set up 
|
||
|
|
;a survey. :-)
|
||
|
|
<br><b>bryce:</b> Don: doesn't RFB imply that you&
|
||
|
|
nbsp;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 pr
|
||
|
|
oto 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 o
|
||
|
|
f the screen updates
|
||
|
|
<br><b>bryce:</b> so if you were going to mak
|
||
|
|
e 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&n
|
||
|
|
bsp;backs <br><b>Psyon:</b> but
|
||
|
|
<br><b>uninet:</b> Could the client vnc GUI use&nb
|
||
|
|
sp;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 sim
|
||
|
|
ple, right?
|
||
|
|
<br><b>Psyon:</b> VNC client just draws data sent&
|
||
|
|
nbsp;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&n
|
||
|
|
bsp;Enhancements
|
||
|
|
<br><b>bryce:</b> have you seen Xvnc the VNC-X&nbs
|
||
|
|
p;server for linux <br><b>Psyon:</b> would work
|
||
|
|
<br><b>Psyon:</b> yes
|
||
|
|
<br><b>uninet:</b> That way, an enhance client cou
|
||
|
|
ld 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&n
|
||
|
|
bsp;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 ch
|
||
|
|
ars
|
||
|
|
<br><b>Psyon:</b> but that will only work while&nb
|
||
|
|
sp;in a text mode
|
||
|
|
<br><b>Psyon:</b> when In windows
|
||
|
|
<br><b>bryce:</b> it seems like you could hack&nbs
|
||
|
|
p;their Xvnc so that you could use any X
|
||
|
|
11 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&nb
|
||
|
|
sp;to draw dialog boxes, handle all events,
|
||
|
|
etc. without having to rewrite low level gui&
|
||
|
|
nbsp;code.
|
||
|
|
<br><b>Psyon:</b> I guess to extend RFB to wo
|
||
|
|
rk 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 c
|
||
|
|
lient
|
||
|
|
<br><b>Psyon:</b> RFBDialogItemEvent sent to the bochs&
|
||
|
|
nbsp;server
|
||
|
|
<br><b>Psyon:</b> those would be followed by data&
|
||
|
|
nbsp;as to which dialog item was acted on
|
||
|
|
<br><b>Psyon:</b> or what type of input to ge
|
||
|
|
t
|
||
|
|
<br><b>uninet:</b> If the client and server where&
|
||
|
|
nbsp;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 th
|
||
|
|
e same computer, because I have not
|
||
|
|
implemented compression yet
|
||
|
|
<br><b>Psyon:</b> and passing all the graphics thr
|
||
|
|
ough Winsock <br><b>Psyon:</b> casues a bottlnet
|
||
|
|
<br><b>Psyon:</b> bottleneck
|
||
|
|
<br><b>uninet:</b> But if you did, do you thi
|
||
|
|
nk there would still be a hit?
|
||
|
|
<br><b>Psyon:</b> not as much
|
||
|
|
<br><b>bryce:</b> now bochs uses the lowest level&
|
||
|
|
nbsp;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&nbs
|
||
|
|
p;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 D
|
||
|
|
on's idea of using RFB to seperate the G
|
||
|
|
UI might not be the best way to go...
|
||
|
|
<br><b>uninet:</b> (no matter which toolkit is use
|
||
|
|
d)
|
||
|
|
<br><b>Psyon:</b> I dont think it is the best
|
||
|
|
way to go
|
||
|
|
<br><b>Psyon:</b> I just think its a good sta
|
||
|
|
rt
|
||
|
|
<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&nbs
|
||
|
|
p;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&nbs
|
||
|
|
p;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 d
|
||
|
|
one like that
|
||
|
|
<br><b>Psyon:</b> I think it should be done h
|
||
|
|
ow 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 l
|
||
|
|
ike, 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&
|
||
|
|
nbsp;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&
|
||
|
|
nbsp;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&nb
|
||
|
|
sp;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&n
|
||
|
|
bsp;API calls) <br><b>Psyon:</b> Hmm...
|
||
|
|
<br><b>uninet:</b> Well, on non image things, coul
|
||
|
|
dn't it say "hey the user clicked on
|
||
|
|
menuitem1"?
|
||
|
|
<br><b>bryce:</b> a chance to make a decent l
|
||
|
|
ooking dialog
|
||
|
|
<br><b>Psyon:</b> uninet that is what I was t
|
||
|
|
hinking
|
||
|
|
<br><b>bryce:</b> psyon, so what type of messages&
|
||
|
|
nbsp;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 dial
|
||
|
|
ogs?
|
||
|
|
<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&nb
|
||
|
|
sp;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,&n
|
||
|
|
bsp;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&
|
||
|
|
nbsp;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&
|
||
|
|
nbsp;think you may end up with the best
|
||
|
|
looking dialog
|
||
|
|
<br><b>bryce:</b> if you send a very high lev
|
||
|
|
el message, like "show the log options
|
||
|
|
dialog now"
|
||
|
|
<br><b>Psyon:</b> I would like to see the dia
|
||
|
|
logs defined by bochs
|
||
|
|
<br><b>bryce:</b> rather than trying to make your&
|
||
|
|
nbsp;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&nbs
|
||
|
|
p;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&n
|
||
|
|
bsp;dialogs <br><b>bryce:</b> :)
|
||
|
|
<br><b>Psyon:</b> then when submited... data can b
|
||
|
|
e passed back to bochs in a URLENcoded string
|
||
|
|
<br><b>uninet:</b> Couldn't the GUI have the confi
|
||
|
|
g 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&
|
||
|
|
nbsp;be updated as much if bochs told it
|
||
|
|
how to make it
|
||
|
|
<br><b>bryce:</b> It certainly could be done that&
|
||
|
|
nbsp;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&nb
|
||
|
|
sp;the viewer
|
||
|
|
<br><b>Psyon:</b> cant draw the VGA screen to 
|
||
|
|
;the browser
|
||
|
|
<br><b>Psyon:</b> well... you could push it to&nbs
|
||
|
|
p;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 overhe
|
||
|
|
ad <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&nbs
|
||
|
|
p;browser as teh viewer, couldn't the VGA
|
||
|
|
screen be shown in a Java applet and con
|
||
|
|
fig 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&
|
||
|
|
nbsp;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 s
|
||
|
|
tring 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&nbs
|
||
|
|
p;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 t
|
||
|
|
hrough this interface that is
|
||
|
|
performance critical anyway.
|
||
|
|
<br><b>Psyon:</b> could steal some code to rended&
|
||
|
|
nbsp;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 compl
|
||
|
|
exity of an HTML rendering layer.
|
||
|
|
<br><b>Psyon:</b> well... it would only be HTML&nb
|
||
|
|
sp;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 wa
|
||
|
|
s just thinking you still have to figure
|
||
|
|
out how to render the widgets on the for
|
||
|
|
m.
|
||
|
|
<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 benefi
|
||
|
|
t? <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 proces
|
||
|
|
s 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 a
|
||
|
|
nd some semblance of security
|
||
|
|
<br><b>Psyon:</b> Well, using XML for dialogs woul
|
||
|
|
d benefit for remote viewers
|
||
|
|
<br><b>Psyon:</b> most all socket code is pretty&n
|
||
|
|
bsp;close to the same
|
||
|
|
<br><b>Psyon:</b> in the sense that what if b
|
||
|
|
ochs 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 p
|
||
|
|
rocesses with network code is it
|
||
|
|
doesn't matter if the viewer is on the s
|
||
|
|
ame computer or 2,000 miles away...
|
||
|
|
<br><b>Psyon:</b> Even if it is the same proc
|
||
|
|
ess <br><b>Psyon:</b> it would work ok
|
||
|
|
<br><b>bryce:</b> ok, sockets are fine and same&nb
|
||
|
|
sp;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&nbs
|
||
|
|
p;using XML for dialogs? <br><b>Psyon:</b> why?
|
||
|
|
<br><b>bryce:</b> as opposed to just saying "Ok&nb
|
||
|
|
sp;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" th
|
||
|
|
en you can make the dialog look as good&
|
||
|
|
nbsp;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 s
|
||
|
|
ay
|
||
|
|
<br><b>bryce:</b> if you send it XML, then th
|
||
|
|
e viewer's job is to make anything in th
|
||
|
|
e
|
||
|
|
world look as good as possible, which is 
|
||
|
|
;a hard task
|
||
|
|
<br><b>Psyon:</b> send the code with and ID n
|
||
|
|
umber
|
||
|
|
<br><b>Psyon:</b> They only big problem im seeing&
|
||
|
|
nbsp;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 toolk
|
||
|
|
its (or lack of), the menus
|
||
|
|
and dialogs would look the same.
|
||
|
|
<br><b>bryce:</b> you have a binary connection, se
|
||
|
|
nd bytes? <br><b>bryce:</b> true
|
||
|
|
<br><b>Psyon:</b> I think we should just do t
|
||
|
|
he 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&
|
||
|
|
nbsp;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&nbs
|
||
|
|
p;realm of bochs development at all :)
|
||
|
|
<br><b>uninet:</b> True...
|
||
|
|
<br><b>bryce:</b> maybe we should FIND one rather&
|
||
|
|
nbsp;than write one
|
||
|
|
<br><b>uninet:</b> Well, you could port the existi
|
||
|
|
ng GUI to this system (without
|
||
|
|
configs), and then as voluteers appears willing&nb
|
||
|
|
sp;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&nb
|
||
|
|
sp;toolkit, BTK (?), or keep bochs
|
||
|
|
toolkit-independant (where it uses the best gui&nb
|
||
|
|
sp;for each platform)...
|
||
|
|
<br><b>Psyon:</b> You know... the whole cross plat
|
||
|
|
form thing is what is making this hard
|
||
|
|
<br><b>uninet:</b> ...there are going to be platfo
|
||
|
|
rm limitations based on the toolkit.
|
||
|
|
<br><b>Psyon:</b> I can think of a hundred wa
|
||
|
|
ys 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&nb
|
||
|
|
sp;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&nbs
|
||
|
|
p;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&n
|
||
|
|
bsp;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&
|
||
|
|
nbsp;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&nbs
|
||
|
|
p;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 pro
|
||
|
|
jects
|
||
|
|
<br><b>Psyon:</b> I found some code on the MS
|
||
|
|
FTP
|
||
|
|
<br><b>bryce:</b> at the risk of being the de
|
||
|
|
vil's advocate all the time: why not wr
|
||
|
|
ite
|
||
|
|
gui/wxWindows.cc and compile it directly into boch
|
||
|
|
s? 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), i
|
||
|
|
t shouldn't be to hard to make it work
|
||
|
|
like TrollTech's QT for windows, since they a
|
||
|
|
re 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-cygw
|
||
|
|
in <br><b>bryce:</b> well ok not a great one
|
||
|
|
<br><b>Psyon:</b> that guy talks about the problem
|
||
|
|
s 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&n
|
||
|
|
bsp;start
|
||
|
|
<br><b>uninet:</b> If you compiled the wxWindows d
|
||
|
|
irectly into Bochs, wouldn't that
|
||
|
|
limit the expansion into other toolkits?
|
||
|
|
<br><b>Psyon:</b> ok... have you guys looked at&nb
|
||
|
|
sp;the bochs GUI functions yet? like
|
||
|
|
tile_update, create_bitmap, text_unpdate?
|
||
|
|
<br><b>uninet:</b> Wow! Don, I didn't know you&nbs
|
||
|
|
p;were working on kde-cygwin! I just read
|
||
|
|
about that at KDE's The Dot the other da
|
||
|
|
y. <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 deve
|
||
|
|
loper 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=2
|
||
|
|
7249 <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 tim
|
||
|
|
es
|
||
|
|
<br><b>Psyon:</b> and discussed some things with h
|
||
|
|
im
|
||
|
|
<br><b>Psyon:</b> that is what takes up a lot
|
||
|
|
of my time
|
||
|
|
<br><b>Psyon:</b> im fighting against MS in my&nbs
|
||
|
|
p;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 W
|
||
|
|
indows.
|
||
|
|
<br><b>uninet:</b> How's it going with that projec
|
||
|
|
t? <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 stati
|
||
|
|
c lib
|
||
|
|
<br><b>Psyon:</b> but had troubles making shared
|
||
|
|
<br><b>Psyon:</b> but Ralf succeeded where I faile
|
||
|
|
d <br><b>Psyon:</b> and got that to work
|
||
|
|
<br><b>uninet:</b> So, would it be hard to ge
|
||
|
|
t QT/Free to work well enough in Windows
|
||
|
|
that it could be used for the Bochs tool
|
||
|
|
kit?
|
||
|
|
<br><b>Psyon:</b> It will work with an X serv
|
||
|
|
er 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 dependan
|
||
|
|
t QT/Free is on X
|
||
|
|
<br><b>Psyon:</b> Its a lot of code to look&n
|
||
|
|
bsp;over
|
||
|
|
<br><b>Psyon:</b> I know they tried to keep i
|
||
|
|
s 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&nbs
|
||
|
|
p;FrameBuffer of your graphics card
|
||
|
|
<br><b>Psyon:</b> and wouldnt work in windows
|
||
|
|
<br><b>bryce:</b> not being free is a big pro
|
||
|
|
blem though, as good as QT might be
|
||
|
|
<br><b>uninet:</b> Have you ever tried talking to&
|
||
|
|
nbsp;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&nb
|
||
|
|
sp;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&nb
|
||
|
|
sp;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 functi
|
||
|
|
onality we need
|
||
|
|
<br><b>bryce:</b> how is it different from other&n
|
||
|
|
bsp;GUI toolkits? <br><b>Psyon:</b> HEY! anyways
|
||
|
|
<br><b>uninet:</b> It will also most likely be&nbs
|
||
|
|
p;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 b
|
||
|
|
efore!!! <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&nb
|
||
|
|
sp;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 w
|
||
|
|
e 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&nb
|
||
|
|
sp;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&nb
|
||
|
|
sp;on <br><b>Psyon:</b> well <br><b>Psyon:</b> yes
|
||
|
|
<br><b>uninet:</b> So in essence, this would becom
|
||
|
|
e a compatiblity layer between bochs
|
||
|
|
and what ever toolkit, right?
|
||
|
|
<br><b>Psyon:</b> This keeps the same concept the&
|
||
|
|
nbsp;the current GUI structure... but adds
|
||
|
|
more functionality <br><b>Psyon:</b> yes
|
||
|
|
<br><b>Psyon:</b> and we would d something like&nb
|
||
|
|
sp;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 eventual
|
||
|
|
ly look <br><b>Psyon:</b> or something
|
||
|
|
<br><b>uninet:</b> gotcha.
|
||
|
|
<br><b>Psyon:</b> This doesnt push us towards havi
|
||
|
|
ng a separate GUI and Emu
|
||
|
|
<br><b>Psyon:</b> but It does get us going to
|
||
|
|
wards 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 reco
|
||
|
|
mpile with Bochs-RFB :) <br><b>uninet:</b> :-)
|
||
|
|
<br><b>Psyon:</b> also... the menu items should no
|
||
|
|
t 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&
|
||
|
|
nbsp;CVS, and in fact in 1.2.pre1)
|
||
|
|
<br><b>Psyon:</b> oooh... good
|
||
|
|
<br><b>Psyon:</b> now I can put Bochs Developer&nb
|
||
|
|
sp;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 <br><b>---&nb
|
||
|
|
sp;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 implemente
|
||
|
|
d... 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&nbs
|
||
|
|
p;already, or waiting until later?
|
||
|
|
<br><b>uninet:</b> Psyon: your resume actually looks&nb
|
||
|
|
sp;good.
|
||
|
|
<br><b>Psyon:</b> The layout is good... the conten
|
||
|
|
t 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&nbs
|
||
|
|
p;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 a
|
||
|
|
s 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 loo
|
||
|
|
k 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&nb
|
||
|
|
sp;each needed dialog
|
||
|
|
<br><b>bryce:</b> once you have 3 dialogs coded&nb
|
||
|
|
sp;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 wri
|
||
|
|
te 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_chang
|
||
|
|
e_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 sh
|
||
|
|
ow all dialogs
|
||
|
|
<br><b>uninet:</b> True... but would that necessarily&n
|
||
|
|
bsp;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 gett
|
||
|
|
ing 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&nbs
|
||
|
|
p;needed) could you take the one out of
|
||
|
|
QT and make it independant?
|
||
|
|
<br><b>bryce:</b> I think once we have some c
|
||
|
|
oncrete 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&n
|
||
|
|
bsp;already <br><b>uninet:</b> (psyon) <br><b>bryce:</b> :)
|
||
|
|
<br><b>uninet:</b> Psyon: we seem to be thinking&n
|
||
|
|
bsp;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 t
|
||
|
|
ill the 14th of june <br><b>Psyon:</b> hehe
|
||
|
|
<br><b>bryce:</b> I guess it better be done b
|
||
|
|
y 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 b
|
||
|
|
e hard to add
|
||
|
|
<br><b>Psyon:</b> its the dialogs that will be&nbs
|
||
|
|
p;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 m
|
||
|
|
uch easier to collaborate
|
||
|
|
<br><b>uninet:</b> (or rather toolkit)
|
||
|
|
<br><b>bryce:</b> so that one person doesn't have&
|
||
|
|
nbsp;to do everything alone and send a diff
|
||
|
|
when he's done
|
||
|
|
<br><b>Psyon:</b> the current calls to create the&
|
||
|
|
nbsp;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&nb
|
||
|
|
sp;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&nbs
|
||
|
|
p;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 i
|
||
|
|
cons (if you want) but perhaps we should
|
||
|
|
wait until something like wxWindows or QT com
|
||
|
|
es into the picture...
|
||
|
|
<br><b>Psyon:</b> Probably just change that over t
|
||
|
|
o 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&nbs
|
||
|
|
p;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 func
|
||
|
|
tion <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&
|
||
|
|
nbsp;well. <br><b>bryce:</b> good night!
|
||
|
|
<br><b>Psyon:</b> cya guys later</tt>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<!--content ends here -->
|
||
|
|
|
||
|
|
|
||
|
|
<!--#include virtual="includes/footer.txt" -->
|
||
|
|
|
||
|
|
|
||
|
|
Last Modified on <!--#flastmod file="mailinglists.html" -->.<BR>
|
||
|
|
|
||
|
|
<!--#include virtual="includes/cright.txt" -->
|
||
|
|
|
||
|
|
</BODY>
|
||
|
|
</HTML>
|