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