T H E   C R O S S   P L A T F O R M   I A - 3 2   E M U L A T O R
Current Release: Bochs 2.8
- Home Page   - SF Project Page Search Get Bochs   - Download Current   - See All Releases   - Disk Images Support   - Bochs Wiki   - Bochs FAQ   - Documentation      - User Guide      - Devel. Guide      - Doc. Guide   - Mailing Lists   - Discussion Boards   - SF Site Docs Feedback   - Bug Reports   - Feature Requests Development   - Get Involved   - View the Source   - Patches   - Tech Specs Pages Resources   - Bochs History   - Bochs Links   - Related Links   - Screen Shots	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 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 And with Don heading off for the night, we concluded our very productive, first IRC chat at just past 10:30PM (PDT).
	Please send comments and questions concerning the site to Volker Ruppert. Web site feature requests and bug reports should be added to the Web site tracker. Last Modified on Saturday, 16-Jul-2022 08:03:02 UTC. © 2001-2024 The Bochs Project. See the project statistics here.