OSDev.org

Firestryke31 wrote:What complex behavior do you think you'll need? ...

The colored text in the Register window is useful, but not vital. The colored text in the ASM window *IS* vital. The colored text in the MemDump window is also pretty vital, but that's based on Watchpoints, which are not really running yet.

And you don't even know about resizing and docking yet. Try grabbing one of the 3 main windows, and moving it on top of one of the others. Then just try to get that to work in WxWidgets. I dare you.

The "typedefs" are standard Bochs coding, and I like them.

And no, the GUI calls me, and then I call the GUI back. I've been programming Win32 for a decade, and I know what I'm doing there.

bewing wrote:I'll post your workspaces soon. Thanks for those.

I agree that GTK is a total PoS, but after lots of struggles I don't think I have any better choice available on posix systems to get the complex graphics behavior that I need -- even to just barely match what I can do moderately easily on Win32. And even on Win32 I think the GDI design is unnecessarily difficult.
What I find amazing is that some crazy people managed to write complete Ubuntu desktops and apps using GTK. I'm not sure how many people died in the process, but I'm sure it was a few.

Any reason Qt is not an option? I've managed to do some ridiculously unusual things in Qt (One app, for example, is completely custom themed, including the title bars, without a line of platform specific code to do so) without encountering issues with it. Qt's bitmap drawing interface (QPainter) is much like GDI's, except less complex, though I have never used it that extensively (Due to lack of need primarily).

The only "disadvantage" that I can see is that Qt is C++, but, well, so is wxWidgets. And Qt is far, far better designed than the ugly monstrosity that is wxWidgets, which can only be compared favourably with MFC, which isn't saying much.

bewing wrote:

Firestryke31 wrote:What complex behavior do you think you'll need? ...

The colored text in the Register window is useful, but not vital. The colored text in the ASM window *IS* vital. The colored text in the MemDump window is also pretty vital, but that's based on Watchpoints, which are not really running yet.

And you don't even know about resizing and docking yet. Try grabbing one of the 3 main windows, and moving it on top of one of the others. Then just try to get that to work in WxWidgets. I dare you.

The "typedefs" are standard Bochs coding, and I like them.

And no, the GUI calls me, and then I call the GUI back. I've been programming Win32 for a decade, and I know what I'm doing there.

That kind of behaviour sounds like the stuff which is almost trivial with Qt

bewing wrote: And you don't even know about resizing and docking yet. Try grabbing one of the 3 main windows, and moving it on top of one of the others.

Uh, I don't know if it's just this particular binary, or if it's something you haven't implemented yet or if I'm just doing it wrong, but at the moment nothing happens. Just 3 independent windows that cover each other like normal.

And TBH I don't see the point of the text mode console that can't be done with a text file and some menu options. I never did, even with the normal Bochs.

Owen wrote:

bewing wrote: Any reason Qt is not an option? ...

AFAIK, Qt either doesn't run on, or is not often ported to, OSX and BSD. I think it also doesn't run on Cygwin -- not that I care all that much about Cygwin usage. I haven't looked into it that deeply, but I agree that from what I know it is better designed than GTK or WxWidgets -- maybe Win32 too, for all I know. On the other hand, AFAIK, Qt (like GTK) is also built on top of XWindows, which is a nasty, buggy, monstrous library to begin with.
At some point, I wouldn't mind trying to create a Qt toolkit for the GUI debugger, just to see how slick and bugfree it is. I wouldn't mind making a Javascript one either -- to maximize portability. The Win32 one maximizes speed and stability.

@Firestryke: well, I do use the gui debugger extensively. It is a very very important part of how I debug my OS. Different programmers have different debugging techniques. People like me do a lot of singlestepping through ASM code, and we need to see the registers change while we do it. Some things, like docking, were meant for other people to customize some personal preferences. But most of the way the gui debugger works is designed to enhance the productivity of someone who needs exactly this type of debugger. The GUI debugger will be optional in this code, when the textmode and "none" debuggers exist.

Qt does indeed work on BSD and Mac OS X (..and many other platforms/toolkits), as for the "XWindows" library.. there is no such thing.. there is a Xlib which is indeed difficult to work work, but in recent versions of X a new library called XCB exists and Xlib is essentially a wrapper around it now, you can use XCB directly if you want.. but neither are "toolkits", they're much more powerful then that.

Qt is used by the KDE DE, which is most definitely available on BSD and several other OS's, including Windows.

Personally I prefer GTK+ apps, wxWidgets offers backends for both Qt and GTK+ so that would solve integration with various environments.

BTW, I replied to a post of yours back on page 1 bewing.

The X Window System is a formally defined library of primitive functions and objects that was created at MIT in 1984. It has since been extended. But it is a standardized library -- in the same way that the C library is a standardized library.

I knew about KDE. I didn't know that Qt had been ported that far. That is very interesting. Thank you for that piece of info.

And you did indeed completely identify the cause of GTK bug#3. Congrats. 3 gold stars for you. I was overflowing a 16 byte automatic-variable buffer.

And I already have my own internally defined copies of strcpy and strncpy -- I really don't feel like adding more.

Hi Bewing,
Its against my professional ethics to contribute to your project right now.But I have quit my current job.I can come up with test cases and tests by the end of next month or the beginning next month.Is that okay for you ?PM me incase of any concern.

Not writing unit tests is not excusable however
--Thomas

If you want to have your own project of creating unit test functions for CPUs, that would be very helpful. You do not need to contribute to my project directly to be helpful. I would be very interested to see how qemu and bochs perform with your unit tests.

Writing complete unit tests for an X86 would take two or three man-years for an experienced ASM programmer to do, in my estimation. Unit test code needs to be PERFECT, and there will be a lot of it.

This is a hobby. I do not have that kind of time to invest, and that would cause an unacceptable delay in releasing a nearly perfect piece of code (which rebochs will be in a few months). A two or three year delay to add one more '9' of reliability to the model is equally inexcusable.

bewing wrote:The X Window System is a formally defined library of primitive functions and objects that was created at MIT in 1984. It has since been extended. But it is a standardized library -- in the same way that the C library is a standardized library.

No, X is a network-aware protocol and the library you use is entirely irrelevant.. it serves a very simple purpose, to provide a graphical display interface.

The new XCB library brings you closer to the X protocol, on a much lower level.

I'm glad you found your bug, keep your stars though.. clearly you need all the shiny objects you can get.

bewing wrote:If you want to have your own project of creating unit test functions for CPUs, that would be very helpful. You do not need to contribute to my project directly to be helpful. I would be very interested to see how qemu and bochs perform with your unit tests.

Writing complete unit tests for an X86 would take two or three man-years for an experienced ASM programmer to do, in my estimation. Unit test code needs to be PERFECT, and there will be a lot of it.

The guys below developed CPU unit testing project and successfully run with VirtualBox, QEMU and Bochs.

http://security.dico.unimi.it/kemufuzzer/

Stanislav

bewing wrote:Dumping things to disk is one more future feature that is somewhere on my todo list. Maybe I'll move it up.
For the moment, I think I'll try adding an Int13h command to your code to dump data back out to the disk image file.

In my case, i have a separate function which reinitializes the emulator with tests as bios one by one, lets it run until hlt is encountered or step count exceeds the limit, and compare the memory with the result file, writing out discrepancies. That way the thing could be fully tested in one key press when i change something in the code.

bewing wrote:there is no corresponding res_*.bin file for jmpmov.bin -- is there not one? Or did it just not happen to get into your zipfile?

Contrary, that one stands apart from the test suite, being for the very basic things. It's success is if it ends at the address 0xF400C.

Thanks, Stanislav! That's extremely helpful!

And thanks for the additional info, Artlav.

@Brynet: Your 2nd major crashing issue should be resolved now. If you would be willing to verify that, it would be helpful.

Brynet-Inc wrote:Qt does indeed work on BSD and Mac OS X (..and many other platforms/toolkits), as for the "XWindows" library.. there is no such thing.. there is a Xlib which is indeed difficult to work work, but in recent versions of X a new library called XCB exists and Xlib is essentially a wrapper around it now, you can use XCB directly if you want.. but neither are "toolkits", they're much more powerful then that.

Qt is used by the KDE DE, which is most definitely available on BSD and several other OS's, including Windows.

Personally I prefer GTK+ apps, wxWidgets offers backends for both Qt and GTK+ so that would solve integration with various environments.

BTW, I replied to a post of yours back on page 1 bewing.

wxWidgets doesn't have a Qt backend. Qt, on the other hand, does come with QGtkStyle - or, in other words, if it detects a Gtk using desktop (GNOME, XFCE), it will automatically load gdk and extract the style information it needs from it. Gtk, on the other hand, does not have a builtin style for drawing widgets natively on Qt desktops, and the only option which exists is pathetically buggy.

wxWidgets API is also a horrid abomination which completely ignores some of the best aspects of C++ in order to reimplement them awkwardly the C way (I'm looking at you, wxArray, and that you are essentially std::vector reimplemented with macros instead of tenplates).

The final thing I have against Gtk is this: Gtk looks native nowhere except a Gtk desptop. Everywhere it looks and behaves like Gtk, even when trying to pretend to fit in. Qt, on the other hand, uses the platform's native drawing tools everywhere.

Owen wrote:
wxWidgets API is also a horrid abomination which completely ignores some of the best aspects of C++ in order to reimplement them awkwardly the C way (I'm looking at you, wxArray, and that you are essentially std::vector reimplemented with macros instead of tenplates).

No argument here. Why reimplement half of the STL when it not only meets the requirements you want, but is far more tested and works well with other libraries? You can even inherit and extend them if there's a couple of features you want missing (i.e. ASCII->Unicode support). This is the thing I don't like about it, but the single cross platform API for native controls make up for it.

The final thing I have against Gtk is this: Gtk looks native nowhere except a Gtk desptop. Everywhere it looks and behaves like Gtk, even when trying to pretend to fit in.

this++;

But perhaps we should either stop discussing the UI toolkit or split the topic as things have digressed from the original point of the thread. If it is split, then to the mods: Have fun filtering the posts that have both on- and off-topic stuff.