OSDev.org

stlw wrote:So I see UNIX version of the debug frontend have much less users that Win32 version had

Yeah, I was noticing that, too. The first day I posted my Win32 version, there were 16 downloads of it. Total downloads so far for this X version are about 6, in a week.

On the other hand, that was after WindowsNT had spent several months getting people to try his original Win32 version (and I had posted several mods) -- so everyone was much more familiar with it.

On the third hand, jal has promised to test it soon, and I'm a bit surprised that Combuster hasn't tested it yet (after bugging me about it on the other thread) -- and Brendan's testing has already been very helpful. And, of couse, quok has now offered some beta-testing time. So it looks like there is still some response left to go.

On the fourth hand, while the debugger part of my code is quite mature, the X-GUI part is in its earliest possible beta-testing stage -- and (unfortunately!) has turned out to be unstable in a way that I don't understand well at all. So, I can see why some people around here would hesitate.

And, on the fifth hand (look how many hands I've got! ), I posted a stubbed semi-functional standalone version of just the GUI frontend on the GTK forums website ( http://www.gtkforums.com/forum-16.html ) last night, for some GTK experts to scrutinize. There have already been 3 downloads there, and I hope for some additional feedback from them, very soon. So there is more response than just what you are seeing here.

It's very unfortunate that Alboin was unable to overcome his problems just with compiling bochs -- because he clearly was willing to put some effort into the beta-test.

But also, in some sense, I am very disappointed in GTK. All my code works perfectly on my system, but even with just Brendan and Stevo14 testing it, it is clear that the GTK libraries are not stable relative to Xlib and the available X-window managers. Unless it is possible to find workarounds to increase the stability, I am beginning to think that this X-window version may be useless, except in special cases.

quok wrote: Unfortunately I haven't yet had the time to test this, but I fully plan on it.

Bewing, I'll even get it working with autotools for you, so it's fully integrated and hopefully that'll fix all these compile problems.

First though, I need to fix my wife's laptop, and evidently figure out what she did to her Palm that causes it to just reboot constantly, heh.

I hope to get to testing this new GUI later today, though!

Thank you very much, quok -- I appreciate that. As I've said before, this is my first ever attempt at creating an Xlib based program, and I'm just doing it as a gift for you guys, and I certainly need the help.

I am still wondering if it is even possible to create an end-user patch that can make things work (without autoconf to rebuild the configure script, or without making a permanent modification to Makefile.in). So I am very interested to see what you manage to come up with, there. I suppose you could directly patch the 2.3.7 configure script, but ewwwwww.

If the bochs guys decide to permanently integrate this version of my code into the next version of bochs, I'm sure they would be happy to be told exactly how to modify configure.in -- but they are smart enough to figure out that part of it for themselves, otherwise.

I'm curious bewing.. you keep mentioning the keywords: "X-Window/Xlib and Linux".

What exactly is prohibiting someone from compiling this on a Mac with the native GTK+ port?

I think I only mentioned Linux once, in the thread topic -- so that people would understand that it is not the Win32 version anymore.

But as for the other half of your question:

There are about 8 different "VGA Window" drivers in bochs: X, win32, amiga, carbon, sdl, rfb, beos, and wxWidgets. Each of them needs a patch, in order to work with some form of my frontend. WindowsNT (plus the guy who botched the wxWidgets debugger) did the win32 patch, the x-version is what we are looking at here & now, I'm having trouble compiling the sdl version, the wxWidgets one may be impossible -- and the rest I am planning to leave for someone else (I do not have the hardware, etc.). The patches are fairly similar, but not precisely identical.

So, the precise answer to your question is that they could just so long as they correctly patched the bochs carbon interface for themselves, or used X emulation for the VGA window + the native GTK interface.

PS. If you have a Mac, and want to test it, I'd be happy to supply an untested patched copy of carbon.cc that I think should work -- and the same goes with SDL, RFB, or any of the others.

bewing wrote: PS. If you have a Mac, and want to test it, I'd be happy to supply an untested patched copy of carbon.cc that I think should work -- and the same goes with SDL, RFB, or any of the others.

My primary dev machine these days is OS X 10.5.5, heh. I love this macbook pro, almost had a heart attack when it just stopped charging the day. I got that fixed though, yay Apple store!

On the third hand, jal has promised to test it soon, and I'm a bit surprised that Combuster hasn't tested it yet (after bugging me about it on the other thread) -- and Brendan's testing has already been very helpful. And, of couse, quok has now offered some beta-testing time. So it looks like there is still some response left to go.

To be honest I was planning to, but I have a sheer lack of time (two deadlines past week), and the only moment I actually did try I figured that I was still installing stuff to my new laptop. (and X was still missing). Got another busy week to go but I'll try to fix more time for this. Probably during some boring college with required attendance

Myself, I'm not in any hurry. Stanislav is really hoping to get all the versions sufficiently stable by January for the next bochs release. But the "logic" part of my code is stable -- it's just these GUI problems to solve, one at a time, until it's "good enough". So don't rush yourself. A week or two from now is fine.

Weird. Although I specify --with-x, x.cc does not get compiled, and hence enh_dbg.cc doesn't compile ("undefined reference to `debug_cmd_ready'"). Must have something borked. Perhaps I can find out tomorrow...

JAL

Interesting. That might indicate that some of these compilation problems that people are having are a bug in the bochs configure script.

Just out of curiousity, did you happen to stare the "make" process with a make clean, or make dist-clean?

bewing wrote:Interesting. That might indicate that some of these compilation problems that people are having are a bug in the bochs configure script.

Just out of curiousity, did you happen to stare the "make" process with a make clean, or make dist-clean?

bewing, why don't you release sources based on CVS and let Voler (or anybody else) to make configure scripts to support it ?

Stanislav

bewing wrote:Just out of curiousity, did you happen to stare the "make" process with a make clean, or make dist-clean?

dist-clean, but I also started from scratch (new dir, untarring sources). I may have some time tonight to sort it out, but with the coming holidays, don't expect too much after that...

EDIT: ok, found it. I had --enable-plugins in my config script. This means that your modifications don't work with that flag, which is I think not desirable. Something to be looked at...


JAL

stlw wrote: bewing, why don't you release sources based on CVS and let Voler (or anybody else) to make configure scripts to support it ?

I will, I will ....
But Volker's configure scripts do not help me at all during this initial debugging phase.

jal wrote: dist-clean, but I also started from scratch (new dir, untarring sources). I may have some time tonight to sort it out, but with the coming holidays, don't expect too much after that...

Not a problem. Anything is better than nothing.

EDIT: ok, found it. I had --enable-plugins in my config script. This means that your modifications don't work with that flag, which is I think not desirable. Something to be looked at...

I'm pretty sure that my mods have nothing to do with that error. I'm pretty certain that you just found a generic bochs bug, like Brendan did -- the question is whether it's a configure script bug, or a C bug. But I will definitely look at it.
Since your copy was a tarball, I assume you are using the June 3 release version?

bewing wrote:

EDIT: ok, found it. I had --enable-plugins in my config script. This means that your modifications don't work with that flag, which is I think not desirable. Something to be looked at...

I'm pretty sure that my mods have nothing to do with that error.

They do. The thing is, when --enable-plugins is specified, the x.o and other libs are compiled into a plugin (whatever format, I think it's a .la, although I'd expect a .so or something), which means they are not statically linked, in which case your enh_dbg or what's it called cannot be linked since it needs definitions from x.cc.

But I will definitely look at it.

Please do. You may have to specify some non-statically linked lazy-binding whatever (I'm not very versed in the whole Linux stuff).

Since your copy was a tarball, I assume you are using the June 3 release version?

I've got the 2.3.7 release. Don't know whether that's June 3.


JAL

Ah, thanks for the explanation. I didn't understand that before about the non-static nature of plugins.

bewing wrote:Ah, thanks for the explanation. I didn't understand that before about the non-static nature of plugins.

Neither did I. I had to 'debug' the Makefiles to see what was going on...

B.t.w., I have the first change request: in the stack dump view, make the hex value a fixed eight digits, without a trailing '0x', so comparable to the way the register contents is displayed (I could easily do this myself of course, but hey :)).

JAL