bochs: The Open Source IA-32 Emulation Project (Mailing Lists)

Transcript of 5/30/2001 Bochs Chat

Those in attendance were: Bryce Denney (bryce), Greg Alexander (yakovlev), Donald Becker (psyon), Mark Knecht (Markk), Tim Butler (uninet), eks|x, nolu, and smapnipss
Elapsed Time: 4.5 Hours (6:00PM - 10:30 PM PDT)
*** 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 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 te sting 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& nbsp;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 bu g 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 pr oblems in gui/nogui.cc, iodev/pci.cc bryce: - removed extra pa ren that broke SHOW_IPS bryce: - HALT macro in&nb sp;rombios.c causes a bochs panic (which can be turned off bryce: in .bochsrc)&nbs p;instead of actually halting. bryce: - added additional ;check for null pointer in debugger exit rout ine 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&n bsp;a symlink to /usr/bin would be good. yakovlev: We should put in a fix f or the timing. yakovlev: No, it belongs in /usr/local/bin&n bsp;on linux. MarkK: I would have been happy with&nbs p;finding it in a readme... bryce: timing? as in bochs takes 100%&n bsp;cpu? uninet: It seems that it is rather ;bad it installs outside the path of RH though... yakovlev: and sometimes runs faster than&nbs p;real time. yakovlev: I had an idea on that on e. bryce: I agree that's important, but I& nbsp;think not for the 1.2 bryce: I'm thinking bug fixes only, bas ically, 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&nb sp;release of any existing feature improvements? yakovlev: essentially? bryce: right. here's what I was thinkin g with 1.2.pre1 uninet: I thought it was a feature ;release bryce: we had lots of features that&nbs p;only the authors have tried bryce: and finally the ability to make& nbsp;RPMS and win32 binaries bryce: so I wanted as many people as possible to be able to try the featur es 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 fi le bryce: I'll paste them in now if y ou want. yakovlev: bochs-RFB I think is new in&n bsp;1.2 also. MarkK: not necessary....I can't run tonight& nbsp;anyway MarkK: I'll look at the tar file bryce: there are some important ones, e sp 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&nb sp;has the log of changes too. yakovlev: Ugh, I'd really like to get&n bsp;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&n bsp;be 1.2.pre1 with a few bug fixes uninet: Sounds reasonable. bryce: and anything major should go int o 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 f or the big stuff. yakovlev: but, it's an incremental improveme nt. bryce: 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. MarkK: so far I must say I'm REALL Y impressed here though MarkK: I'm participating on some much l arger projects MarkK: and they're no where as organize d MarkK: (of course I don't really know&n bsp;how many are participating here!!) bryce: 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 bryce: I wanted to get binary releases& nbsp;out as soon as possible bryce: since that will allow the most&n bsp;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&nb sp;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& nbsp;cleanup, the .bochsrc cleanup, the I/O cleanup? uninet: What would be the advantage of& nbsp;a 1.1.2 binary release? bryce: there's too much that should be& nbsp;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&nb sp;backport anything we want. bryce: given enough time. yakovlev: We had at least a few me ssages on the list about people getting HALT messages when things used to run fine. uninet: Can't that be stopped in bochsr c? bryce: the bug fix to HALT causes errors to be reported correctly, that's all. yakovlev: from the bios fixes you recen tly added. *** Signoff: nolu (Read error: Connection timed&nb sp;out) yakovlev: yup, that's the problem. bryce: anything that has STOPPED working&nbs p;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& nbsp;version that possibly reports but continues to run after errors occur. yakovlev: right uninet: I thought Bryce said the Bochsr c 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 pos sibly easy workaround. bryce: Tim, the HALTs now produce a&nbs p;bochs panic. In 1.2 all panics can be turned non-fatal by changing the .bochsrc. yakovlev: but I don't trust any code&nb sp;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& nbsp;wouldn't make a difference. bryce: we should distinguish between the&nbs p;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&nb sp;of the bios with HALT defined to be n op. bryce: the HALT macro was broken until& nbsp;1.2.pre1, it did absolutely nothing yakovlev: Which was good from a user&nb sp;perspective, bad from a debugging one. bryce: the hlt instruction halts the bo chs 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&nb sp;here's what it does now: yakovlev: Right, and I'm just saying I& nbsp;don't want to have to disable all hlts, just the one in HALT. bryce: the HALT macro causes bochs to&n bsp;call panic bryce: with the line number of the ;HALT macro (in rombios.c) bryce: and then it does NOT call t he x86 hlt yakovlev: oh, that's somewhat better. bryce: this lets you control what happe ns through the bochsrc by saying "panic: action=fatal" or "panic: action=report" bryce: do you think that's an ok b ehavior for a 1.2 release? yakovlev: Not too bad. bryce: :) yakovlev: You guys had talked about bei ng 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 capabili ty 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 .b ochsrc syntax to specify this yakovlev: could we define the panics ca used 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& nbsp;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=repor t, 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&n bsp;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& nbsp;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 th is for us. bryce: :) yakovlev: yup. yakovlev: just a minute, I like the&nbs p;log idea. yakovlev: hmmmm... yakovlev: what if we viewed these more& nbsp;as commands. yakovlev: so, we could use: yakovlev: log: filename="outfile", panic=fatal, e rror=report yakovlev: log: obj=PIT, filename="outfile2", pani c=report, info=report yakovlev: that's cleaner. yakovlev: we'd have to decide just how& nbsp;to parse different things. bryce: so if you have no obj=X the n 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&nbs p;from earlier lines yakovlev: we only have to specify part& nbsp;on a line, bryce: right yakovlev: right. bryce: ok, that sounds like a good ;start. yakovlev: filename would apply either only&n bsp;to the module. yakovlev: or even only to the reporting specified on that line. MarkK: Is there something easy you coul d do to keep separate runs in separate files? MarkK: So that if you wanted to ru n regression it would be easy bryce: (let's continue the .bochsrc syntax&n bsp;on email, so that we can get to other things too) MarkK: sure bryce: mark, maybe you could put in&nbs p;a %d or something bryce: into the filename, and then spri ntf some time stamp into the %d MarkK: that's an idea yakovlev: there are several ways to do& nbsp;it. yakovlev: the calling program could just&nbs p;change the value in .bochsrc between runs. yakovlev: at any rate, next topic... bryce: I had a little survey written&nb sp;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 i t but try to get more people to answer&n bsp;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.&nbs p; 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&nb sp;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 enjoymen t of running a PC in my PC. :-) uninet: Future Bug fixes: bug 1. Featur e Request: feature 8. bryce: also to be able to watch th e OS working (esp Linux since I can see& nbsp;the source too) uninet: (Mouse problems, and emulation speed respectively) MarkK: Chip Designer: Inteested in interfaci gn it to my new design. MarkK: bad spelling. ;-) bryce: mark, are you allowed to say&nbs p;what you're designing? :) MarkK: Sort of.... smapnipss: i use bochs for os developme nt MarkK: I'm working on some leading edge 1394 stuff bryce: I understand, I'm a chip designe r too. yakovlev: wow, me too. yakovlev: I can say. POWER4 MarkK: but I'm also interested in chips et design, and how that might play in here uninet: I'm feeling out numbered here...&nbs p;I'm just a lowly web designer. bryce: We're thinking about SMP chip de signs bryce: big surprise :) MarkK: The web rules...;-) We just work ! MarkK: Anyway, long term I'm interestedin&nb sp;how I can use this with new chip designs prior to tapeout... yakovlev: Interesting. bryce: it could certainly be made into& nbsp;a good driver/monitor... yakovlev: Were you one of the guys ;pushing for a more modular design? MarkK: yes, driver could get deveoped i n Windows. *** Signoff: smapnipss () MarkK: I usually have some sort of ;C model for the chip MarkK: hook it all together and try&nbs p;it out... uninet: That would be nice. Would the&n bsp;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 j oined channel #Bochs eks|x: hi guys :) bryce: 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. MarkK: hi eks bryce: Hi eks! uninet: Hi eks! eks|x: :) MarkK: Not really.... bryce: eks: we're just talking about ou r 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&nb sp;bochs needs more speed before it needs IEE E 1394 anyway... MarkK: people are starting to do open&n bsp;source Verilog yakovlev: depends on how prevalent FPGAs&nbs p;become in configurable consumer electronics. MarkK: Or faster platforms to run Bochs on. yakovlev: Anyways, we're getting very sidetr acked. MarkK: yes bryce: good point :) bryce: so I heard several votes for&nbs p;better mouse support (bug1) uninet: Definately. eks|x: what I would really appreciate i s 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&nbs p;to manage. Bochs must have the values ;in there somewhere, you just need printed out ri ght? uninet: bug3 sounds like a nice one&nbs p;to fix too... bryce: yes, bug3 is tough though bryce: well maybe not tough, just lots& nbsp;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&n bsp;we made a portable way to read from a cdrom disk image? yakovlev: yes, but if we get the C DROM model right, we're done. eks|x: 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 eks|x: yakovlev: cdrom model shouldn't be&nb sp;too hard to implement, close to hdd model MarkK: Bryce: So that part is under&nbs p;feature 1? bryce: 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. yakovlev: that would be good, Bryce. yakovlev: I was surprised that wasn't t here already. uninet: Would it be possible to make&nb sp;bochs pretend /dev/cdrom was a cdrom image? bryce: 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 yakovlev: well, it would take some look ing, but basically, yes. eks|x: just out of nowhere like that,&n bsp;any of you familiar with 'bfe' ? ;) yakovlev: We'd have to add the removabl e media controls to the CDROM interface, but even that isn't ridiculous. bryce: eks: can you add that as a& nbsp;feature request on SF? otherwise I prom ise I'll forget. :) eks|x: it's a nice addition to bochs&nb sp;I think eks|x: bryce: I can do that,sure :) bryce: bfe: I looked at it once, a nd 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 p hysical I/O if you wanted to... yakovlev: well, bochs needs to know if& nbsp;a CD is there or not. eks|x: 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 bryce: bfe is actually what started me& nbsp;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&n bsp;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 i n installing new software yakovlev: then maybe DISK_SEEK, DISK_READ, a nd DISK_WRITE to complete the set. MarkK: what's the interface look like b etween the IDE controller and the HD/CDROM? bryce: if I manage to make a large r-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 th e most important feature of a new GUI? bryce: feature10: GUI for configuration and& nbsp;runtime control bryce: oh I see bryce: like what do you want the g ui to do? uninet: Right. bryce: Answer: everything. uninet: Assuming that the GUI could hav e 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 t o push all the interface as far away from bochs internals as possible. :) yakovlev: Notice a recurring theme in m y 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& nbsp;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&nbs p;be in a different library, but that's the idea. uninet: Well, actually one should be a& nbsp;normal program that requires the shared library that contains the other code, right? yakovlev: Also, I used "GUI code" very& nbsp;loosely. yakovlev: right, tim. bryce: no reason to require shared libr ary, 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& nbsp;#Bochs yakovlev: Shared library good, but could&nbs p;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&nb sp;Perl. :-) Psyon: What did I miss? Psyon: HEY uninet: Hi Don! bryce: it will all be on the web&n bsp;site. Psyon: hehe Psyon: ok bryce: we're starting to talk about the GUI! Psyon: well... what am I hearing about& nbsp;Perl? Psyon: Good that is my dept? bryce: we're going reimplement all of b ochs in perl. Psyon: oops uninet: Yeah, if it is dynamically link ed that would be good. That way the GUI code could be switched without a recompil e. 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&nb sp;C Psyon: cant you? uninet: :-) Maybe... it wouldn't require&nbs p;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&nbs p;definition... so anything that could be considered "client code" right? eks|x: btw, perl is an easy to wri te into language, but afaik, it's never as fast as optimized-compiled C yakovlev: Yeah, basically. bryce: greg, how is your model differen t 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&nb sp;Plex86 plugin structure? uninet: Is the current GUI library dyna mically loaded? bryce: so with some makefile tricks we& nbsp;could compile them as shared libraries. bryce: not dynamic, no eks|x: bryce: feature added on sf (fpu& nbsp;stack dump) bryce: eks: thanks bryce: uh, I don't know anything about& nbsp;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&nbs p;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 plu gin Psyon: hehe Psyon: uni: There are just certain func tions that are needed to be implemented for the GUI yakovlev: Methinks plugins is going a l ittle far. Psyon: a shared lib that has them wouldnt be a problem bryce: 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. uninet: 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) bryce: it reduces the size of the binary, and maybe you can load up only t he device models you want that time. Psyon: the bad thing is that shared&nbs p;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&nb sp;using gui modules or gui using bochs module? Psyon: and... DLLs in windows have to&n bsp;have the exported functions defined Psyon: __declspec(dllexport) Psyon: or have a .def file eks|x: 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 uninet: eks|x: I would think the GUI&nb sp;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 r un 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 w ith it uninet: eks|x: It would also be handy&n bsp;if you wanted to use the console gui, and then wanted an X11 gui. bryce: modules might let you make a&nbs p;binary distribution with all the GUIs available at .bochsrc time, rather than only one eks|x: uninet: how often do you switch& nbsp;from one to the other? Psyon: How big is the compiled bochs&nb sp;on linux? uninet: eks|x: never. But I haven't act ually even tried the console GUI yet. Psyon: I havent looked at it in li nux 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 boch s bryce: ls -[bryce@monster bochs-1.2.pre1]$ ls&nbs p;-l bochs bryce: -rwxrwxr-x 1 bryce ; bryce 441036 May 30&nb sp;22:44 bochs* Psyon: 384kb Psyon: that is an out of the box&n bsp;compile of BugFix 2 eks|x: 1.1.3 with a few addys bryce: I don't think it's the binary&nb sp;size, it's the ability to mix and match parts that's powerful, right? yakovlev: Well, it sounds like we want& nbsp;a bochs executable which loads both a GUI and a BOCHS module. uninet: 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... uninet: ...it would be good since one&n bsp;binary would work on all of those GUI's. eks|x: what about having a main binary& nbsp;using a bochs module and a gui module? bryce: you can do any of these, ho wever you want. Psyon: This is where having a separate& nbsp;process for the viewer and the emu comes into play Psyon: that would make it easier to&nbs p;switch the viewer type yakovlev: eks: jynx bryce: bochs module with no debugger, o ptimized 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 ni ce reason for modules. RFB could be used just by changing modules. yakovlev: I actually don't like using s hared 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 spee d.... yakovlev: But compiling them separately woul d 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 & nbsp; users 1472404 May 30 22:42 bochs eks|x: bare bochs 1.1.3 uninet: bryce: but since they are stati c libraries, that would mean they need to be recompiled for each change, right? bryce: markk, are you thinking that sev eral pcs would simulate it faster? yakovlev: Eat up most of iodev, for&nbs p;one. MarkK: just thinking it might, in the&n bsp;long term bryce: markk: maybe, probably the first ;step is multithread support on a single machine MarkK: Also, it might simulate concurrency&n bsp;better later on... *** Roadkill (~ondrej@baikonur.orbitec.com.au) has joined&nb sp;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&nbs p;to do some coding. MarkK: and anotehr running the CPU mode l... 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&nb sp;I would need to wait and see how someone e lse created a C gui for bochs first... yakovlev: Mark, that's a lower down dis tinction 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&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. MarkK: yes, and I think no time (m aybe) simulating the chip set right now? Psyon: I think if we are going to& nbsp;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&n bsp;special version for bochs though bryce: what about Tk or wxWindows? Psyon: is wxWindows any good? bryce: I have no idea, their website&nb sp;says it is :) bryce: but it's cross platform, all C&n bsp;based, and open-source uninet: 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. uninet: All I can say is that it&n bsp;seems to me C is the way to go... uninet: (versus C for the GUI) Psyon: Well... I dont see why using&nbs p;the standard bochs GUIs are a problem yakovlev: neither do I. Psyon: using a GTK of some sort wo uld still have code for Windows and X11 in it uninet: Psyon: GTK for Windows isn't ve ry 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&nb sp;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& nbsp;every so often uninet: Wouldn't it also cause some pro blems since it is C-based, where as I think MS's commonctrls are C? Psyon: do to the emulation, the time&nb sp;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 yo u 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 q ueue of mouse and key events Psyon: then bochs calls handle_events() in&n bsp;the GUI code Psyon: and you have to pass it all the events Psyon: and all of bochs runs in th e 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&nbs p;like that Psyon: and I was thinking about just&nb sp;passing them to bochs as they come in Psyon: but the window callback for even ts is on a diff thread Psyon: and I dont know if that wil l 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 poten tially worth moving from the GUI layer into the general bochs layer. Psyon: when there is heavy emulation be ing 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 c an be i guess yakovlev: from what Don is saying, soun ds like bochs instructions. bryce: I'm afraid I need to look a t it more to be able to know what i s going on. Psyon: // Called periodically (vga_update_interva l in .bochsrc) so the// the gui code can poll for keyboard, mouse, and&nb sp;other// relevant events. eks|x: I tend to agree with Greg t hat it's bochs' instructions Psyon: There Psyon: that is from Win32.cc in the&nbs p;GUI dir Psyon: Hmm... Psyon: I never noticed that Psyon: I wonder if I set vga_update_int erval 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 f ar far away from gui libraries and who wants to write some dialog boxes... :) Psyon: hehe bryce: I want to fix that mouse to o, some day. Psyon: I think that is a big part& nbsp;of the useability problem uninet: The GUI code is already seperat ed into a different module, right? uninet: (or rather library) Psyon: how well does the mouse work&nbs p;in X11? bryce: greg and don said, what's wrong& nbsp;with the current gui ? eks|x: tim: right eks|x: tim: libgui.a Psyon: There are some optimizing and cl eanup that needs to be done with the current ones Psyon: but that is all uninet: eks|x: Do you know if it i s 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&n bsp;without using a single feature of C. bryce: :) Psyon: heheh uninet: Ah, thanks Bryce. bryce: greg and don said, what's wrong& nbsp;with the current gui ? Psyon: I dont think anything is bryce: and I think that's important to& nbsp;hash out uninet: So, theoretically, it wouldn't be&nb sp;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 pan ic. do you want to continue" Psyon: hehehe bryce: or "Now choose the disk image&nb sp;you want to be in drive A:" Psyon: I think a live register display& nbsp;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&n bsp;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 lo adable Psyon: but im saying yakovlev: copying the image file is awk ward. Psyon: the features are there to do&nbs p;so bryce: yeah, and then click the stupid& nbsp;disk icon twice? bryce: it sucks! yakovlev: And the size can't change. Psyon: oviously you would unmount... change& nbsp;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& nbsp;dialog box? yakovlev: And you often forget to unmou nt, or forget to remount. bryce: IMHO, no GUI toolkit to write&nb sp;in yakovlev: I see your point. Psyon: Well... just make a new toolbar& nbsp;button that lets you load a new image bryce: psyon: should or shouldn't be ha rd to implement Psyon: shouldnt be bryce: right Psyon: well... Psyon: the GUI shoudl have access to&nb sp;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 tha t statement. Psyon: Well Psyon: functions that arent in the GUI& nbsp;code bryce: 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 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&nb sp;points reduce the error rate eks|x: easier to debug yakovlev: 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. 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&n bsp;need any gui library, that's what I'm getting at. yakovlev: no, the GUI should get some&n bsp;well thought-out interfaces, not willy-nilly access to bochs internals. Psyon: BAH! I cant find the function&nb sp;that ejects it bryce: IMHO just making all the interfa ces to the GUI through public member functions is a good way to "define the i nterface" yakovlev: Sort of. bryce: then the .h file for the ou termose 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&nbs p;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&nb sp;only or does it need to be checked at every function call? bryce: 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. uninet: yakovlev: Right... the GUI doesn't&n bsp;need access to everything. yakovlev: Having a single .h file with& nbsp;the functions that are allowed to be accessed outside would be listed there. yakovlev: acls was just saying that pub lic 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 nam e it bochs should reload it Psyon: and it can be a new size bryce: 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. yakovlev: Oh, okay, that's exactly what ;I'm advocating then, Bryce. yakovlev: maybe, but bochs doesn't handle&nb sp;floppies right anyways. Psyon: that seems like a smart idea Psyon: what doesnt it handle? Psyon: I reads my real floppies now&nbs p;:) 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&nbs p;set of unorganized data. Psyon: hehe bryce: maybe the first step will be&nbs p;to clean up the interface between current GUI library and the rest. uninet: 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? 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 p ermit runtime only changes. bryce: bochsrc = some place to save&nbs p;the settings that you like, in some form bryce: so that you can get them ba ck yakovlev: right. bryce: and also send them to somebody&n bsp;so they can duplicate your setup Psyon: Would be nice to have something& nbsp;like VMWare, so that when the program starts it asks what configuration you wish to load yakovlev: Something which exists totally out side the bochs emulation layer. Psyon: and has the option to start ;with power off uninet: Psyon: I agree, that would be&n bsp;VERY nice. bryce: greg, yes only that gui part&nbs p;would be reading and writing the bochsrc I think. uninet: 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. 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&nbs p;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 y ou can start the program bryce: and each one has its own .b ochsrc, 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&nbs p;power button on the toolbar uninet: 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. 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 co nfig file as an argument... like "bochs mysystem.rc" Psyon: if not bryce: not sure if it works now, b ut it would be useful sometimes Psyon: yes Psyon: that is something else that migh t be done in the next release or something bryce: go for it :) Psyon: actually uninet: I thought it already worked as& nbsp;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"&nbs p;"diskc:blabla" Psyon: I mostly look at the GUI co de so im kinda dumb as to how the r est works Psyon: hehe bryce: 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. Psyon: yeah yakovlev: 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. 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&n bsp;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& nbsp;fun. yakovlev: :) bryce: good night Psyon: night *** Signoff: yakovlev (Java Chat http://www.undernet.or g/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 don e for a Menu system Psyon: basically eks|x: Psyon: I think the bochs gfx&nbs p;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&nb sp;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&n bsp;be worked out like the toolbar thing uninet: eks|x: Wouldn't removing the icons&n bsp;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 g ui to control bochs, you can have icons in it, no on the bochs output Psyon: 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 eks|x: 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 Psyon: eks: the current Icons are just& nbsp;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&n bsp;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&n bsp;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&nb sp;convert normal bitmaps to the ones in the .h files in the source code? eks|x: having it all in the gui bo chs 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& nbsp;just 1bit bitmaps bryce: 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 eks|x: yeah, the rfc uninet: Pyson: Win4Lin accomplishes fullscreen&nb sp;by starting a new X session on another tty, and then maximizing the window i t's in... bryce: but there is everything from: &n bsp;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 t oolkit 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&n bsp;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&n bsp;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 als o 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&nbs p;makes a native bitmap bryce: what tool can convert a GIF ;into such a bitmap though? eks|x: don: seems to me like the i nternals of the functions uses one bit Psyon: Hmm... Psyon: yes Psyon: You might have to do it man ually uninet: Manually? uninet: How so? Psyon: yes eks|x: bryce: afaik, The Gimp under X,& nbsp;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 u sing 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 t his: bryce: static unsigned char bochs_icon_bits[]&nbs p;= { bryce: 0x00, 0x00, 0x00, 0x00, 0 x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0x00, bryce: 0xe0, 0xff, 0xff, 0x07, 0 xf8, 0xff, 0xff, 0x1f, 0xf8, 0xff, 0xff, 0x1f, bryce: 0xfc, 0xc7, 0xe3, 0x3f, 0 xfc, 0xc7, 0xe3, 0x3f, 0xfc, 0xc3, 0xc3, 0x3f, bryce: 0xfc, 0xc3, 0xc3, 0x3f, 0 xf8, 0xc1, 0x83, 0x1f, 0xf0, 0xc0, 0x03, 0x0f, bryce: 0x00, 0xc0, 0x03, 0x00, 0 x00, 0xc0, 0x03, 0x00, 0x00, 0xc0, 0x03, 0x00, bryce: 0x00, 0xc0, 0x03, 0x00, 0 x00, 0xc0, 0x03, 0x00, 0x00, 0xc0, 0x03, 0x00, eks|x: so a pic shouldn't be bigger&nbs p;than 32bytes bryce: 0x00, 0xc0, 0x03, 0x00, 0 x00, 0xc0, 0x03, 0x00, 0xf0, 0xc0, 0x03, 0x0f, bryce: 0xf8, 0xc1, 0x83, 0x1f, 0 xfc, 0xc3, 0xc3, 0x3f, 0xfc, 0xc3, 0xc3, 0x3f, bryce: 0xfc, 0xc7, 0xe3, 0x3f, 0 xfc, 0xc7, 0xe3, 0x3f, 0xf8, 0xff, 0xff, 0x1f, bryce: 0xf8, 0xff, 0xff, 0x1f, 0 xe0, 0xff, 0xff, 0x07, 0x00, 0xff, 0xff, 0x00, bryce: 0x00, 0x00, 0x00, 0x00, 0 x00, 0x00, 0x00, 0x00, }; uninet: 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? Psyon: make that into 1s and 0s Psyon: and you will actually see the&nb sp;picture bryce: no, BMP is not the same as& nbsp;a C header file! Psyon: you have to convert that to ;a BMP eks|x: tim: you need some tool that&nbs p;converts binary-:c headers uninet: eks|x: Hmm... do you know of&nb sp;a tool that can do that? eks|x: tim: a search on freshmeat shoul d 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,&nb sp;and execute the right code for each platform to make that the icon. eks|x: bryce: right Psyon: well... GTKs will want to use&nb sp;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&nb sp;toolkit and that's why we have icons that look like a C header file. Psyon: I think we could easily convert& nbsp;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 i n the color table that bochs uses eks|x: Psyon: normalized palette or each&nbs p;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 see n 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 p ointer 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&n bsp;* Y) / 8 Psyon: but create images still wont be& nbsp;real easy Psyon: the bytes in the .h files a re not in BMP format uninet: Hmm... I wonder how Kevin did&n bsp;it? bryce: I'm going to sound like a b roken 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&nb sp;out hex symbols until they looked like something? eks|x: "let's write bochs in asm, so&nb sp;it can fit in 100kb" eks|x: ;) bryce: of icon image formats or whateve r 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 c olors palette used to display vga text? eks|x: hard to fix? Psyon: reword that eks|x: well, clear white gets out as&nb sp;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, wh en displaying text in the guest, gets out wrong Psyon: actually that standard VGA pallet&nbs p;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& nbsp;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 th en uninet: eks|x: Are you running at 256&n bsp;colors? Psyon: each char on the screen is represented by 2 bytes bryce: on X windows, my text colors&nbs p;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 T he Gimp in full color no problem but boc hs is always screwed, alone or not bryce: wierd eks|x: the 0x07 color in text is f ine eks|x: the 0x01 color is very too dark eks|x: and the 0x09 is like the 0x 01 should normally be uninet: 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)? eks|x: 0x0F gets out as the original&nb sp;0x09 Psyon: That is proably the internal boc hs 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 li nux box to play with bochs on Psyon: I dont like to run it on&nb sp;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? 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 -- 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 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&nbs p;some of this. Psyon: well that kinda explains why he& nbsp;did it that way Psyon: In windows Psyon: I an make it use 256 color& nbsp;bitmaps Psyon: not sure how to do it in&nb sp;X11 Psyon: or Mac Psyon: for that matter Psyon: :) uninet: :-) uninet: I suppose this is a good r eason for me to finally apply myself to learn C. uninet: This chat seems to be dying&nbs p;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 icon s :) uninet: Yup. Psyon: Yeah, but we can change the ;subject to something more important Psyon: hehe uninet: Sounds good, I think I'll sit&n bsp;it out for the toolkit to be decided ;on (if we even decide on one) bryce: I'm hoping that someone has actu al 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& nbsp;galore in addition to the gui to work on too uninet: The difficult thing is, there a re 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&nbs p;could help out somewhat... bryce: 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 bryce: we need to help define the interface Psyon: That is my big problem right&nbs p;now Psyon: I have to kill some of my&n bsp;other projects Psyon: and devot time to the major ;ones uninet: killall *projects Psyon: hehe bryce: (we = people who do know bo chs and know what the GUI needs to be&nb sp;able to do) Psyon: http://www.perlhq.com -- I have&nbs p;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 u nder the sun Psyon: hehehe bryce: and then we have a chance a t getting more people aware of the project uninet: Sounds good. bryce: I bet there are lots of peo ple who stopped looking at www.bochs.com during the last year uninet: I'm suppose to get it up e verywhere under the sun, right? bryce: I'll be happy to help with that, once we have a 1.2 that we're prou d 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&nbs p;after install, and try it out! bryce: :) Psyon: I need to fix up the raw&nb sp;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 t he 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"&nbs p;would be good enough Psyon: _stat() on windows doesnt work w hen \\.\a: is opened Psyon: just need to make it check to see if its using a raw disk or n ow Psyon: not uninet: 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! 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 stayin g current bryce: or maybe CVS snapshots are bette r, I don't know Psyon: oh Psyon: you just mean to get the co de 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 fo r 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&nb sp;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&n bsp;know that was a dump question. Psyon: brb... potty break uninet: hahaha uninet: I don't know if that was w hat 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&nb sp;a feel for the general opinions of the Bochs community. Psyon: ok Psyon: bak bryce: 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. Psyon: 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 ;:) uninet: How do you set it up? Psyon: bochs RFB? bryce: tim: you have to be admin o n the project uninet: Don, I agree, I think RFB is a very good system of dividing the GU I and emulator. bryce: and then type in the questions&n bsp;and answers, it's all web form stuff uninet: Psyon: I meant survey forms. uninet: bryce: Ah... I see. That's why& nbsp;I couldn't figure out how to set up ;a survey. :-) bryce: Don: doesn't RFB imply that you& nbsp;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 pr oto 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 o f the screen updates bryce: 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. 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&n bsp;backs Psyon: but uninet: Could the client vnc GUI use&nb sp;a toolkit to render a button? Psyon: I was going for compatibility of the viewer bryce: no a VNC client is VERY sim ple, right? Psyon: VNC client just draws data sent& nbsp;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&n bsp;Enhancements bryce: have you seen Xvnc the VNC-X&nbs p;server for linux Psyon: would work Psyon: yes uninet: 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... Psyon: We would be better off just ;modifying it all bryce: Xvnc is portable, since it has&n bsp;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 ch ars Psyon: but that will only work while&nb sp;in a text mode Psyon: when In windows bryce: it seems like you could hack&nbs p;their Xvnc so that you could use any X 11 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&nb sp;to draw dialog boxes, handle all events, etc. without having to rewrite low level gui& nbsp;code. Psyon: I guess to extend RFB to wo rk 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 c lient Psyon: RFBDialogItemEvent sent to the bochs& nbsp;server Psyon: those would be followed by data& nbsp;as to which dialog item was acted on Psyon: or what type of input to ge t uninet: If the client and server where& nbsp;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 th e same computer, because I have not implemented compression yet Psyon: and passing all the graphics thr ough Winsock Psyon: casues a bottlnet Psyon: bottleneck uninet: But if you did, do you thi nk there would still be a hit? Psyon: not as much bryce: now bochs uses the lowest level& nbsp;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&nbs p;current VGA display window Psyon: oh Psyon: ok bryce: which is performance-critical uninet: 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... uninet: (no matter which toolkit is use d) Psyon: I dont think it is the best way to go Psyon: I just think its a good sta rt 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&nbs p;CVS tree btw? uninet: Right, it would need to be ;worked on, but the concept is good. bryce: like gui says: "Hey Bochs, I&nbs p;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 d one like that Psyon: I think it should be done h ow 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 l ike, 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& nbsp;ID has been pushed Psyon: and bochs will act on it bryce: and bochs says "ok 312,12 looks& nbsp;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&nb sp;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&n bsp;API calls) Psyon: Hmm... uninet: Well, on non image things, coul dn't it say "hey the user clicked on menuitem1"? bryce: a chance to make a decent l ooking dialog Psyon: uninet that is what I was t hinking bryce: psyon, so what type of messages& nbsp;should bochs be telling the gui? Psyon: That is how the current one ;basically works uninet: Ah. bryce: buttons are easy, how about dial ogs? 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&nb sp;that will be needed? Psyon: Yes/No, File, OK Psyon: what else? bryce: For each of these devices (HD,&n bsp;CMOS, CDROM, Floppy), choose what Psyon: well... Psyon: just in general bryce: a panic, debug, info, and error& nbsp;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& nbsp;think you may end up with the best looking dialog bryce: if you send a very high lev el message, like "show the log options dialog now" Psyon: I would like to see the dia logs defined by bochs bryce: rather than trying to make your& nbsp;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&nbs p;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&n bsp;dialogs bryce: :) Psyon: then when submited... data can b e passed back to bochs in a URLENcoded string uninet: Couldn't the GUI have the confi g 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& nbsp;be updated as much if bochs told it how to make it bryce: It certainly could be done that& nbsp;way, and if you're very sneaky you might use your browser as the viewer. Psyon: Well... you wouldnt use it as&nb sp;the viewer Psyon: cant draw the VGA screen to ;the browser Psyon: well... you could push it to&nbs p;it Psyon: as a streaming video bryce: no, VGA screen is low level ;APIs as it is now bryce: otherwise you add lots of overhe ad Psyon: Could do bryce: I mean the control panel uninet: 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? Psyon: char *bx_gui::ShowDialog(XMLCode *gui); Psyon: XMLCode beings XML or HTML code& nbsp;for the form bryce: yes, but slowly! We don't need any more speed penalties here. Psyon: and the return would be a s tring 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&nbs p;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 t hrough this interface that is performance critical anyway. Psyon: could steal some code to rended& nbsp;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 compl exity of an HTML rendering layer. Psyon: well... it would only be HTML&nb sp;forms Psyon: not full HTML Psyon: maybe that is a bad idea Psyon: but its an idea uninet: 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. 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 benefi t? 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 proces s 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 a nd some semblance of security Psyon: Well, using XML for dialogs woul d benefit for remote viewers Psyon: most all socket code is pretty&n bsp;close to the same Psyon: in the sense that what if b ochs is running on linux and being viewed in windows Psyon: or Vice Versa uninet: 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... Psyon: Even if it is the same proc ess Psyon: it would work ok bryce: ok, sockets are fine and same&nb sp;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&nbs p;using XML for dialogs? Psyon: why? bryce: as opposed to just saying "Ok&nb sp;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" th en you can make the dialog look as good& nbsp;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 s ay bryce: 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 Psyon: send the code with and ID n umber Psyon: They only big problem im seeing& nbsp;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 toolk its (or lack of), the menus and dialogs would look the same. bryce: you have a binary connection, se nd bytes? bryce: true Psyon: I think we should just do t he 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& nbsp;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&nbs p;realm of bochs development at all :) uninet: True... bryce: maybe we should FIND one rather& nbsp;than write one uninet: 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. Psyon: we could make our own toolkit bryce: aaaaaaaaah uninet: :-) bryce: :) uninet: 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)... Psyon: You know... the whole cross plat form thing is what is making this hard uninet: ...there are going to be platfo rm limitations based on the toolkit. Psyon: I can think of a hundred wa ys to just do it in windows uninet: Yup. bryce: yup. bryce: what is wrong with making the&nb sp;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&nbs p;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&n bsp;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& nbsp;haven't seen the API Psyon: and it runs on mac bryce: but it's open source, C, and&nbs p;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 pro jects Psyon: I found some code on the MS FTP bryce: 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? Psyon: that maps some Xlib functions to Win32 API uninet: 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. Psyon: and I was working with that ;too Psyon: Uninet: http://www.sourceforge.net/projects/kde-cygw in bryce: well ok not a great one Psyon: that guy talks about the problem s with compiling KDE on windows Psyon: bryce: that is a good start ;yes Psyon: that is what we need is a&n bsp;start uninet: If you compiled the wxWindows d irectly into Bochs, wouldn't that limit the expansion into other toolkits? Psyon: ok... have you guys looked at&nb sp;the bochs GUI functions yet? like tile_update, create_bitmap, text_unpdate? uninet: 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. 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 deve loper 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=2 7249 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 tim es Psyon: and discussed some things with h im Psyon: that is what takes up a lot of my time Psyon: im fighting against MS in my&nbs p;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 W indows. uninet: How's it going with that projec t? Psyon: Its going ok Psyon: I mostly was trying to make ;QT/Free compile in cygwin Psyon: which I did fine as a stati c lib Psyon: but had troubles making shared Psyon: but Ralf succeeded where I faile d Psyon: and got that to work uninet: 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? Psyon: It will work with an X serv er now Psyon: as to make it work without one Psyon: im looking into it Psyon: I dont know exactly how dependan t QT/Free is on X Psyon: Its a lot of code to look&n bsp;over Psyon: I know they tried to keep i s 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&nbs p;FrameBuffer of your graphics card Psyon: and wouldnt work in windows bryce: not being free is a big pro blem though, as good as QT might be uninet: Have you ever tried talking to& nbsp;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&nb sp;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&nb sp;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 functi onality we need bryce: how is it different from other&n bsp;GUI toolkits? Psyon: HEY! anyways uninet: 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. Psyon: back to what I was saying b efore!!! 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&nb sp;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 w e 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&nb sp;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&nb sp;on Psyon: well Psyon: yes uninet: So in essence, this would becom e a compatiblity layer between bochs and what ever toolkit, right? Psyon: This keeps the same concept the& nbsp;the current GUI structure... but adds more functionality Psyon: yes Psyon: and we would d something like&nb sp;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 eventual ly look Psyon: or something uninet: gotcha. Psyon: This doesnt push us towards havi ng a separate GUI and Emu Psyon: but It does get us going to wards user friendly Psyon: which I think is more important bryce: yes uninet: right. Psyon: and again, you could always reco mpile with Bochs-RFB :) uninet: :-) Psyon: also... the menu items should no t 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& nbsp;CVS, and in fact in 1.2.pre1) Psyon: oooh... good Psyon: now I can put Bochs Developer&nb sp;on my resume :) Psyon: hehehehe uninet: :-) bryce: :) Psyon: http://www.psyon.org/resume/index.html ---&nb sp;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 implemente d... add_menu_item, show_dialog, add_button? Psyon: something along those lines? uninet: Sounds good to me... bryce: well are we going toward XML&nbs p;already, or waiting until later? uninet: Psyon: your resume actually looks&nb sp;good. Psyon: The layout is good... the conten t 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&nbs p;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 a s 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 loo k 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&nb sp;each needed dialog bryce: once you have 3 dialogs coded&nb sp;in your new toolkit Psyon: show_config Psyon: hmm... bryce: it will then be easy to wri te 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_chang e_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 sh ow all dialogs uninet: True... but would that necessarily&n bsp;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 gett ing this started :) Psyon: hehehe Psyon: Im guessing im the candidate? uninet: Idea: for an XML parser (if&nbs p;needed) could you take the one out of QT and make it independant? bryce: I think once we have some c oncrete 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&n bsp;already uninet: (psyon) bryce: :) uninet: Psyon: we seem to be thinking&n bsp;along the same lines a lot tonight. Psyon: I will warn you guys that I will be out of town from the 8th t ill the 14th of june Psyon: hehe bryce: I guess it better be done b y 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 b e hard to add Psyon: its the dialogs that will be&nbs p;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 m uch easier to collaborate uninet: (or rather toolkit) bryce: so that one person doesn't have& nbsp;to do everything alone and send a diff when he's done Psyon: the current calls to create the& nbsp;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&nb sp;hardcoded with the new implementation until you settled on a toolkit(s)? Psyon: yes bryce: do you think we should leave&nbs p;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 i cons (if you want) but perhaps we should wait until something like wxWindows or QT com es into the picture... Psyon: Probably just change that over t o 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&nbs p;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 func tion 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& nbsp;well. bryce: good night! Psyon: cya guys later Last Modified on .