OSDev.org

quok wrote:my vote is on nobody is using it, because it's not available for our platforms.

Bingo.
If there was a linux (or rather, any cross-platform toolkit) port I would certainly test it and probably use it on a regular basis. But right now it is fruitless for me to setup a building environment in windows just to test this. Not to mention that I would have to reboot every time I wanted to debug my kernel with it...

Combuster wrote:Consider how many people you make happy when you use a win32 frontend, and how many you make happy with a wx frontend.

Is it worth trading the win98 share in favor of all of linux + macos users?

In a perfect world, I would much rather have both, of course. As I said earler on this thread, a linux port would be a very nice thing. WindowsNT gave us the gift of a Win32 GUI frontend. So that is the starting point that we actually have to work with. I have made his frontend tight and slick.

Going further all depends on the PITA factors involved. Whether the toolkit is sufficiently well tested and bug-free. A toolkit with bugs is often impossible to code around.

Now that quok has given me some useful info and links, I am already looking into the potential of wxWidgets. But I am not going to be convinced by marketing hype and slapdash attempts at cross-platform coding, either. We will see how well it really works. If it does not work well, I will send them some bug reports. The bugs may be impossible for them to code around, too.

I put about four hundred hours into getting this code working slickly, and I am sure that WindowsNT did the same, to come up with the code that I started with. You can all kibitz all you like, but if you think a linux port is so great, then how about devoting a few hundred hours of your own time to the project? (PS. that was a rhetorical question, of course -- I know quite well that it isn't going to happen.)

If I have more hours to spare, and if the toolkit works well enough to be livable with, then the next version of the code will happen, otherwise not.

This Win32 version of the GUI will be used some. There are people out there doing OSdeving on Windoze. That is enough for the moment.

In 4 months we have gone from having no usable Bochs GUI frontend, to having a Win32 GUI frontend avaialble. Have we achieved Nirvana yet? Of course not. This is beta-release software. We need it tested, perhaps a few additional features added, and in a future incarnation, hopefully it will become perfect (ie. portable). Patience is necessary. Kibitzing is not.

-- And AJ, Lukem, kmtdk, 01000101, and several others are using it. So it's not quite "nobody".

Please note that what I say below is not a Windows-Linux war, I use both of them for different things.

I 'd say that whoever uses Linux (myself included sometimes) has to pay a price not paid by using free software: The price of standardization, support , and help system offered in Windows, which really is ages beyond anything else.

A user must understand that the "cross platform GUI" concept exists in theory only. In reality, none of us (Windows programmers) take time to use a so-called cross platform tool for building GUI because we consider it loss of time without reason; so I challenge any one willing to port what I initially created (and Bewing extended) to write anything they might want in plain Linux API, but they are on their own; If one is happy for using free software as an alternative to Windows, then he must be willing to understand that the rest of us mortals insist on Windows for a reason, and he must be ready to work on his own to make what he wants.

Please note that not many applications that were written in a so called "cross platform" tools actually earned popularity in Windows. Open Office, or Firefox, are not written in a cross platform tool, in case you think of them as examples of cross platform applications.

In other words, if you want a GUI for Linux, sit down and write it in raw, plain, Windows-incompatible Linux API. Do not criticize me or anyone for writing what I wrote in Windows, because I am never going to write cross platform GUI as long as the balance between Windows/Linux is 100 to 1 (If and when Linux beats Windows, I will be the first that will abandon Windows and write apps for Linux only, not cross platform). Do not criticize us for making a "non portable GUI frontend" for a "portable Application" (as I 've seen many critics in the previous thread) because there is nothing like "portable GUI".I am not able to do it, and I won't be able in the near future and even If I were able, I wouldn't bother making it.

I am sorry for being cruel, but that is the truth no matter how painful might be for anyone.

Michael


P.S.
Bewing: Can you upload a binary for me somewhere ?

well
about testing:
i would love to test your edition bewing, but last time i tryed to compile bochs ( alone) i could not, because my compiler was too new...
So i just stop trying after a hour ...
but yes, i still use WindowsNt's Gui ( and as he said: can you make a bin, and place it somewhere, that is a good ideer)
and it realy is a good type of "upgrading" to the old console edition, and i can live with the bugs ( there is quite many.. , but still usefull)

KMT dk

kmtdk wrote:well
about testing:
i would love to test your edition bewing, but last time i tryed to compile bochs ( alone) i could not, because my compiler was too new...
So i just stop trying after a hour ...

There is no such thing - compiler is too new. This only means you are not trying corrrectly. The best thing to do in this case - ask for help.

Stanislav

kmtdk, WindowsNT: Please read my message in your mailboxes re: a bin file.

Stanislav: Mostly, you are right -- but it is possible that changing compilers can crash the configure script, or be incompatible with the Makefiles.

I agree with WindowsNT -- cross-platform is still an idealistic dream at this point. There are too many bugs and incompatibilities in reality. People here have pointed to bochs as being "platform independent". The way it achieves that is to have *lots* of OS-specific "plugins" that are built in at compile time, to mask over the cross-platform incompatibilities.

On the other hand, the GTK+ translation of this GUI frontend is going extremely well so far, and I expect to post a *NIX compatible version in a few days.

First i woul like to say, what a smooth gui version ( runs much smoother than WindowsNt's gui , not to start a war ... but it is the truth)
secound: i would not hurt anyone, im just telling my opinin:

suggestions for the alternate GUI:
There are some "needs":
The need for a "trace" command ( i realy hate to use breakpoints to bypass large functions).
The need for a breakpoint window or a list, because it would help to keep a "eye" on all your breakpoints.

There are also some "not" needed but, still god thing to have:
The possibleaty to remeber settings ( i would love it xxxxx more if it could remember, where on the screen the windows were last placed, and then replaced at stratup [because im using 2 screens ....], but not breakpoints, but the view settings as well as front)
2: when pointing a "breakpoint using F6, could the marked color change ?, cause it confuses that you cant see "something" new ..


Then there is 1 thing i would like to be able to change:
the apperence of the 3 "child windows" .
by my default opinin; they are placed wrong.
but creative

last:
1: is it first when you enters pagede mode, that you can see page tables ? ( dont have the time to test all posibileties .. )
2: does the register dump change if i enter long mode ?, or how do i only see 16 bit ? ( since 32 bit cant be "changed" ?? )

but else a good debugger.

KMT dk

I am not sure I understand precisely what you mean by your points, but I am glad you posted them. Glad that you like it, so far, too.

1. The default positioning (Docking Order) of the list windows is user-configurable at compile-time. So it is unfortunate that you needed me to build a bin file for you. If you can move things the way you want at runtime, then you can set them permanently that way at compile time. I can easily recompile it for you, if you tell me your preferences.

2. Bochs does not save any kind of "settings INI file" -- so it is completely impossible to save any runtime settings.

3. 'Trace' command: could you please describe more about how you would like this command to work? Bochs only has breakpoints -- so whatever the command does, this GUI frontend would have to do it with breakpoints. In general, though, it sounds like you are asking for something that bochs is currently unable to do. This GUI frontend can't do anything that bochs can't do.

4. Breakpoint window: I will think about this. It sounds like a good idea. You can still type 'info b' or 'blist' into the Internal Debugger to get the standard listing, of course.

5. Color change when setting break/watchpoints: the colors DO change, of course -- but you can't see it until you click on a different line. The way that Windows colors "selected" lines blue is something I can't really change much, I don't think. I agree it is annoying. I will try changing the "selection style" a little, and see if it looks better.

6. Getting Page Tables: yes, once you set the CR0 "Paging" bit in your OS, then you can dump the Page Tables to the window.

7. 64bit mode -- yes, the entire display changes to accomodate 64bit mode, when the CPU goes into that mode. 16bit? Not even the Bochs Internal Debugger does anything special for that.

about trace:
well, normaly when you are steping, and you come to a function or a int, then you trace over the instruction ( or may reverse as WindowsNT s gui ...) insted of enter it.
about settings, what about the borch src ,,, it can save settings into that ?


KMT dk

The bochsrc file is not technically writable.

That 'trace' command in bochs is when you type 'p' in the debugger. You can still type 'p'. I had a special button for that in the previous version, but I took it back out. It just sets a breakpoint at the next instruction. I think I'll make you just doubleclick to set the breakpoint yourself. And doubleclick again to remove the breakpoint.

I also changed the breakpoint code a little, so it always shows colors now in the ASM window. I think I like how the new way works. I still need to check if I can make it work for data watchpoints, though. I'll try creating a breakpoint window, too.

cool, good
is it however posible to map the "p" command to a FX key ?

sounds good.
about the child windows:
my suggestion:
the fist shuld be disamble,
the middle could be "dump", or anything else
the last about reg dump

about saving:
you could acess the api, and then write to a file, ( of cause this is not easy)


KMT dk

Hi All,

First bugfix for the debugger GUI in Bochs CVS tree. If you have more fixed or feature additions - I am still waiting!
Stanislav

Yes, ktmdk found one other bug -- also, I have made an ENORMOUS modification to separate out all the win32-specific code into a separate file. I am still fine-tuning that code. I also added another feature, that kmtdk asked for. I am still working on the Linux conversion to an X-window based GUI. Once that is posted, we should get some extra people doing testing.

After the testing, I think I will send you the entire thing as a new version.

So what what got uploaded in the Bochs trunk? Who's maintaining it and what debugger does it use?

well
i dont know all what happend, but it is still bewing, who is maintaning the debugger. And he have not been here so much the last time, so it is probley the reason why nothing have happend here( in this thred).

KMT dk