bewing's complete bochs rewrite: test request

[bewing]

Yeah, well ... that part of enh_dbg.c was not written by me. That comes directly from the original bochs enhanced debugger: http://forum.osdev.org/viewtopic.php?f=2&t=17546

And woops! I also messed that line up with a global search/replace many months ago. The type is supposed to be Windoze wchar_t. You can either fix it by hand, or I'll fix it in my next patch.

Right now I'm working on getting the gdb stub running.

[Creature]

I checked out from the svn and tried to build with msvc 2010, and eventuall get this:

Code: Select all

// HIHI!! this typedef doesn't exist yet!

What does it supposed to mean?

I think we can all admit we've written crazy things in our comments/code. I once remember browsing through the Quake 3 code and reading something like:

Code: Select all

int ****;

...

and

Code: Select all

// WOOPS, I broke the code.

Then again I admit having written similar things in frustration as well (but did change them later ).

Anyway, back on-topic: Damn bewing, you're really fast in getting all these things working.

[bewing]

Anyway, back on-topic: Damn bewing, you're really fast in getting all these things working.

A little too much free-time during this recession.
But I'm going to be slowing down soon, too. The point is that my own OS had most of these functions in it, up 'til now -- fully debugged, in ASM, with comments. So I had a perfect testcase. For a few of the recent improvements, I had testcases provided by brynet, Kevin, Combuster, and quok. There is a chance that a fuzz-tester that Stanislav pointed out may find another double handful of tiny bugs. And then I'm out of testcases. So I'll need to figure out how something works, then build each new feature into my OS at the same time as I'm building it into Rebochs -- and test both against each other. Which means I'll be coding at less than one quarter the speed, I think.

[elderK]

Holy crap Bewing! Good going!

[Jezze]

I noticed quokforge is down. Are the sources available somewhere else?

[Brynet-Inc]

I noticed quokforge is down. Are the sources available somewhere else?

I have my working copy of the svn repository from May 2013. Send him a PM and see if he's found hosting elsewhere for it.

http://brynet.biz.tm/pub/rebochs-trunk_r128.tar.gz

[Arto]

For those interested, this is the latest status summary for Rebochs that I could find:

21:29:22 <shikhin> bewing: Weren't you the guy writing rebochs?
21:32:30 <bewing> shikhin: Yes, I am indeed writing rebochs.
21:33:06 <shikhin> You are? Or were? Last I checked, ReBochs was pretty dormant. It's a neat project; you should bring it to usable standards.
21:33:48 <bewing> Are. My last submit was about 3 weeks ago. I know I am going slow on it.
21:34:26 <bewing> But I am writing an OS, a compiler, an assembler, my own language, my own IDE, and rebochs at the same time.
21:34:42 <klange> bewing: I can see how that would delay things.
21:34:43 <shikhin> ...
21:35:49 <bewing> If anybody wants to help besides brynet and eryjus, all help is welcome. They only do testing for me.
21:36:43 <shikhin> What state is rebochs at, as of now?
21:38:03 <bewing> I can boot DOS, OpenBSD and my OS. APIC support is fragile. FPU support is only half built.
21:38:29 <shikhin> Oh, nice.
21:38:50 <shikhin> Wait, then. Don't idle your time away at #osdev. Go, work!
21:39:04 <reavengrey> bewing: official repo is still on quokforge?
21:39:07 <bewing> Last I saw in OpenBSD, there is some issue with the keyboard model (duplicating keystrokes).
21:40:06 <bewing> Yes, that's the official/only repo. Sadly, there is an issue on quokforge with posting pre-built images, so it's pretty much down to git/svn and building from source.
21:40:20 <bewing> Fortunately, that part works very well.
21:40:30 <klange> But can I build rebochs for my OS?
21:40:48 <bewing> Oh, and my video support is still not particularly functional.
21:41:22 <klange> Bochs' build scripts are not particularly supportive of cross-compiling. They have done many silly things to me...
21:41:59 <bewing> Yeah, that was one of the things that started me on the rebochs project initially. I HATE the bochs build scripts. UGH!
21:44:11 <bewing> klange: I suspect you can easily build rebochs on your os. But you'd probably have to disable the GUI debugger in the .h file. I doubt you've got a full GDI manager built yet.
21:44:55 <thePowersGang> is rebochs a fork and cleanup, or a rewrite?
21:45:31 <bewing> Complete rewrite, every single byte of it. It's a tenth th size of bochs and runs 10 times faster.

[SoLDMG]

Well, I have to say, this is pretty impressive.

[jal]

Well, I have to say, this is pretty impressive.

QFT.


JAL

[Roman]

21:34:26 <bewing> But I am writing an OS, a compiler, an assembler, my own language, my own IDE, and rebochs at the same time.

Reminds me about myself

[no92]

Me too.

I'm writing an OS, a compiler and an assembler at the same time, as well as designing a lot of specs. There's a wiki page describing us: Alta_Lang

[bewing]

I just poked quok about quokforge being down. Turns out it's just a DNS problem, and hopefully it'll get updated and work again. I'm expecting to make some major upgrades to the code this year -- we will see how that works out. Maybe I'll end up hosting the repo myself, or moving it somewhere.

[jal]

Keep up the good work!


JAL

[bewing]

By the way, guys -- maybe any of you windoze gurus could help me out here with a GUI problem workaround. Under Win, the main debugger window consists of 3 listviews. To get all the functionality, each listview is both superclassed and subclassed.

With one tiny little bugfix from the "current" version on quokforge, the code displays properly in everything from Win98 to WinXP, compiled with everything from VS97 to VS'10. When I move the code to a Win8 64bit machine and try to compile with VS'12 or VS'13, only one of the main windows displays (admittedly the display is correct!) and the other two are completely blank forever.

Clearly this is a microsoft bug -- probably in the new 64 bit commctrl.dll. Which means I can't fix it; I can only work around it and report it.

I tried contacting a microsoft guy about it. His almost literal reply was, "Win32 API? What's that? Listview? What's that? Commctrl? What's that?"
So not only are they trying to deprecate strlen(), open(), fopen(), and printf() -- they are also deprecating their entire old API.
They promised that if I would create an entire testcase that demonstrated the problem, they would forward it to the guy they have locked in the basement, who is the only guy left that deals with Win32.

So, the question is: have any of you seen such behavior before on Win8? Did you find a workaround?

[jal]

So, the question is: have any of you seen such behavior before on Win8? Did you find a workaround?

I can't comment on the actual question, as I don't have any Windows GUI programming experience. However, since nowadays everyone has at least Windows 7, and with Windows 10 on the horizon, I would sincerely advise you to drop support for decade old systems, and go for support of the latest version of Windows only (7+).


JAL