Another Alternate GUI for Bochs

[stlw]

Would be nice to know how. Do you have any ideas you could share ?

Any function/module/method that needs to be atomic, and cannot be made stateless, needs a lock. It seems quite simple to me. Since we are working with a maximum of 8 concurrent threads/CPUs, the lock will probably be quite simple. As far as I know, the current memory routines are also basically stateless. Yes, two cpus can read or write the memory at the same time, in multi-threaded cpu_loops. That is exactly how a multi-CPU real-world machine works, too.

Hardware does a lot to help things working. It implements hardware memory ordering, lock atomicity and apic accesses are serialized by going through apic bus.
BTW, everything is solvable but I need to find a good multiplatform way to do threading/locking
pthreads is not portable enough, so it should some cover above pthreads in UNIX and obove Win32 threads in Win32.

Stanislav

[bewing]

The threading will all be handled by the frontend debugger -- which must be built to be OS-specific anyway. If the simulation is using a generic debugger (such as the internal debugger) then it will simply only run in single-threaded mode.

The locking is indeed a bit of a problem -- because there is no portable way to make a complex lock operation atomic -- so that partially rules out "atomic set and test" algorithms.
But there are ways around that.

And so far, bochs is running flawlessly as a multi-threaded app. My OS is booting and running, inside bochs, perfectly. Currently, it is in single-CPU mode -- but the cpu_loops are being run from two separate threads in my frontend, and from the internal debugger. I only know of one routine, so far, that is going to need a lock -- besides the devices.

[bewing]

and if you think you need ANY modification in Bochs CPU - you just ask and get them.

OK, I would like to make a change. Let's see if we can agree on it.

bx_guard.interrupt_requested is causing me problems because it is not cpu-specific.

The variable is not really needed. I would like to remove it completely from bochs.
BX_CPU(cpu)->guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
does exactly the same thing, and it is cpu-specific.

The iodebug.cpp routines that set bx_guard.interrupt_requested directly should all call bx_debug_break() instead.

In those cases where all the CPUs need to be forced to break (on a real or fake control-C), or where the cpu number is unknown, bochs can simply loop over all BX_SMP_PROCESSORS.

I would also like the cpu number to be passed to bx_debug_break() as an argument. Maybe the stop reason should be passed, too.

[stlw]

OK, I would like to make a change. Let's see if we can agree on it.

bx_guard.interrupt_requested is causing me problems because it is not cpu-specific.

The variable is not really needed. I would like to remove it completely from bochs.
BX_CPU(cpu)->guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
does exactly the same thing, and it is cpu-specific.

The iodebug.cpp routines that set bx_guard.interrupt_requested directly should all call bx_debug_break() instead.

In those cases where all the CPUs need to be forced to break (on a real or fake control-C), or where the cpu number is unknown, bochs can simply loop over all BX_SMP_PROCESSORS.

I would also like the cpu number to be passed to bx_debug_break() as an argument. Maybe the stop reason should be passed, too.

No, you are not right. The line
BX_CPU(cpu)->guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
alone doesn't do anything do Bochs, it is just do supply a reason of the break into debugger. The reason is Ctrl-C.
The thing that actually do the break into debugger is bx_guard.interrupt_requested.

And I don't understand why do you need a way to break specific CPU into debugger and keep running with all the rest. It looks strange to me.
When you break into debugger you should have control over all the stuff and not over single CPU.
I think it is much more reasonable that all the CPUs will break into debugger at the same time.
I could try to make bx_guard.interrupt_requested into the CPU and it will be CPU specific but I don't know if this so good idea.
You know, sometimes such kind of problems could be avoided by making your design differently.

BTW, I am inteersting which kind of usage model you see for such multi-threaded debugger where every CPU debugged in separate thread and run in separate thread.
I see only complete mess here.

Stanislav

[stlw]

So, this is a formal test request for my beta version (0.3). The download on this post contains (very easy) instructions for hand-patching the code into bochs -- it should be compatible with any bochs ver 2.3.X -- I hope.

If you patch it into a different version than 2.3.7, I would be esepcially interested to hear how it goes.

The patch applied to CVS very fine (after I changed watchpoints back to be matching your usage).
But I can't compile it under cygwin, get thousands of compilation errors and warnings.
I really wanted to apply this patch into Bochs CVS soon but I just can't until it perfectly compiles under Cygwin and most known MS compilers.
The list of compilation errors on the first stage is:
====== Cut Here ======
In file included from win32dialog.cc:910:
win32_enh_dbg.h: In function `bx_bool AskText(HWND__*, const TCHAR*, TCHAR*, TCHAR*, int)':
win32_enh_dbg.h:312: warning: passing NULL used for non-pointer converting 3 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h: In function `int DoMatch(const char*, const char*, bx_bool)':
win32_enh_dbg.h:383: warning: array subscript has type `char'
win32_enh_dbg.h: In function `LRESULT LVProc(HWND__*, UINT, WPARAM, LPARAM)':
win32_enh_dbg.h:732: warning: passing NULL used for non-pointer converting 4 of `LRESULT CallWindowProcA(LRESULT (*)(HWND__*, UINT, WPARAM, LPARAM), HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h:732: warning: passing NULL used for non-pointer converting 5 of `LRESULT CallWindowProcA(LRESULT (*)(HWND__*, UINT, WPARAM, LPARAM), HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h:734: warning: passing NULL used for non-pointer converting 3 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h:734: warning: passing NULL used for non-pointer converting 4 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h:736: warning: passing NULL used for non-pointer converting 3 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h:736: warning: passing NULL used for non-pointer converting 4 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h:738: warning: passing NULL used for non-pointer converting 3 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h:738: warning: passing NULL used for non-pointer converting 4 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h:743: warning: passing NULL used for non-pointer converting 4 of `LRESULT CallWindowProcA(LRESULT (*)(HWND__*, UINT, WPARAM, LPARAM), HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h:763: error: `LVM_SUBITEMHITTEST' undeclared (first use this function)
win32_enh_dbg.h:763: error: (Each undeclared identifier is reported only once for each function it appears in.)
win32_enh_dbg.h:764: error: 'struct LVHITTESTINFO' has no member named 'iSubItem'
win32_enh_dbg.h:765: error: 'struct LVHITTESTINFO' has no member named 'iSubItem'
win32_enh_dbg.h: In function `void upr(char*)':
win32_enh_dbg.h:994: warning: array subscript has type `char'
win32_enh_dbg.h: In function `int FillSSE(int)':
win32_enh_dbg.h error: expected unqualified-id before '.' token
win32_enh_dbg.h error: expected unqualified-id before '.' token
win32_enh_dbg.h: At global scope:
win32_enh_dbg.h warning: malformed '#pragma pack(push[, id], <n>)' - ignored
win32_enh_dbg.h warning: #pragma pack (pop) encountered without matching #pragma pack (push, <n>)
win32_enh_dbg.h: In function `void MakeRDnames()':
win32_enh_dbg.h warning: array subscript has type `char'
win32_enh_dbg.h: In function `void SetBreak()':
win32_enh_dbg.h warning: passing negative value `-0x000000001' for converting 3 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h: In function `LRESULT B_WP(HWND__*, UINT, WPARAM, LPARAM)':
win32_enh_dbg.h error: `LVM_SETEXTENDEDLISTVIEWSTYLE' undeclared (first use this function)
win32_enh_dbg.h error: `LVS_EX_FULLROWSELECT' undeclared (first use this function)
win32_enh_dbg.h warning: passing negative value `-0x000000001' for converting 3 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h warning: passing negative value `-0x000000001' for converting 3 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h error: `NMLVKEYDOWN' undeclared (first use this function)
win32_enh_dbg.h error: `key' undeclared (first use this function)
win32_enh_dbg.h error: expected primary-expression before ')' token
win32_enh_dbg.h error: expected `;' before "ll"
win32_enh_dbg.h warning: comparison between signed and unsigned integer expressions
win32_enh_dbg.h error: `CDDS_PREPAINT' undeclared (first use this function)
win32_enh_dbg.h error: `CDRF_NOTIFYITEMDRAW' undeclared (first use this function)
win32_enh_dbg.h error: `CDDS_ITEMPREPAINT' undeclared (first use this function)
win32_enh_dbg.h warning: comparison between signed and unsigned integer expressions
win32_enh_dbg.h error: `CDRF_NOTIFYSUBITEMDRAW' undeclared (first use this function)
win32_enh_dbg.h error: `CDDS_SUBITEM' undeclared (first use this function)
win32_enh_dbg.h error: 'struct tagNMLVCUSTOMDRAW' has no member named 'iSubItem'
win32_enh_dbg.h error: 'struct tagNMLVCUSTOMDRAW' has no member named 'iSubItem'
win32_enh_dbg.h warning: comparison between signed and unsigned integer expressions
win32_enh_dbg.h warning: comparison between signed and unsigned integer expressions
win32_enh_dbg.h warning: passing negative value `-0x000000001' for converting 3 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32_enh_dbg.h warning: passing negative value `-0x000000001' for converting 3 of `LRESULT SendMessageA(HWND__*, UINT, WPARAM, LPARAM)'
win32dialog.cc: At global scope:
win32dialog.cc:32: warning: 'showCPU' defined but not used
win32dialog.cc:33: warning: 'cpu_param' defined but not used
make[1]: *** [win32dialog.o] Error 1
make: *** [gui/libgui.a] Error 2
====== Cut Here ======

Also I have some general complain about the code - it has too many 'magic constants'.
I prefer usage of defines/enums everywhere. According to my opinion each entry of rV array MUST be accessed using define.
The same for magic switch constants in switch(LW) in WM_COMMAND handle.
Now if you suddenly add some constant in between - it is impossible to understand which values should be where !
But of course the most important - is to pass compilation

Stanislav

[bewing]

Try adding a #define _WIN32_IE 0x0400
to the top of the file. Then please recompile and post a new list of errors.

I prefer usage of defines/enums everywhere. According to my opinion each entry of rV array MUST be accessed using define.

In general I disagree. That completely defeats the purpose of having an array.
Arrays in loops cannot be accessed with defines or enums. If you are only going to be accessing each entry individually, they might as well just be independent varaibles.

In this case, I stated that this is a preliminary copy of the code.
The loops on these arrays are short enough that they can be "unrolled" without much pain. So, I am already intending to convert the register numbers to #defines in the next version.

The same for magic switch constants in switch(LW) in WM_COMMAND handle.

I agree with this. They will all be in a enhdbg_res.h file in the next version that I will be posting shortly.

The line
BX_CPU(cpu)->guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
alone doesn't do anything do Bochs, it is just do supply a reason of the break into debugger. The reason is Ctrl-C.
The thing that actually do the break into debugger is bx_guard.interrupt_requested.

The internal debugger is already using BX_CPU(cpu)->guard_found.guard_found as a stop code. When, for example, the CPU->mode_break detects a mode change, it ends up setting BOTH -- then cpu.cpp detects bx_guard.interrupt_requested and does a break, and dbg_main detects guard_found.guard_found as a stop code on the cpu loop.
There is no reason to be using both. All instances of bx_guard.interrupt_requested can be replaced with guard_found.guard_found and the sim will run perfectly. All you need to do is change your mind about the function of guard_found.guard_found.

When you break into debugger you should have control over all the stuff and not over single CPU.

Most debuggers will only display one CPU at a time. So you only need to break one at a time.
Also, a breakpoint in the simulated code will only break one CPU at a time. There is no reason for the others to stop.
Also, if a breakpoint breaks one CPU, and ALL of them stop -- then how do you (the user) know which one hit the breakpoint? It is very clear if only one CPU stops.

BTW, I am inteersting which kind of usage model you see for such multi-threaded debugger where every CPU debugged in separate thread and run in separate thread.
I see only complete mess here.

This is how a real computer with more than one CPU works. It *IS* a complete mess, and it is important that bochs model that mess accurately.
When you have more than one CPU, they do not stay synchronized. One CPU may need to run a billion more lines of code than another, before they reach a software synchronization. It is not convenient to model this, if all the CPUs are forced to all run 5 lines of code each, every time.

Also, this simplifies the design of the "continue" loops in the debugger. Each CPU can be "continued" separately -- as if it were a single CPU, without any need for completely artificial "quantums" and cpu-switching.

There can be a separate command that will "step" all of the CPUs together.

[stlw]

Try adding a #define _WIN32_IE 0x0400
to the top of the file. Then please recompile and post a new list of errors.

I added it on top of win32_enh_dbg.h and got EXACTLY the same list of errors, the define doesn't affect the compilation at all.
What you should probably - is avoid using non-standart control which not exists in Win32API implemented in cygwin ...

Stanislav

[stlw]

The line
BX_CPU(cpu)->guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
alone doesn't do anything do Bochs, it is just do supply a reason of the break into debugger. The reason is Ctrl-C.
The thing that actually do the break into debugger is bx_guard.interrupt_requested.

The internal debugger is already using BX_CPU(cpu)->guard_found.guard_found as a stop code. When, for example, the CPU->mode_break detects a mode change, it ends up setting BOTH -- then cpu.cpp detects bx_guard.interrupt_requested and does a break, and dbg_main detects guard_found.guard_found as a stop code on the cpu loop.
There is no reason to be using both. All instances of bx_guard.interrupt_requested can be replaced with guard_found.guard_found and the sim will run perfectly. All you need to do is change your mind about the function of guard_found.guard_found.

OK, I have simple proof for you. Add the line BX_CPU_THIS_PTR guard_found.guard_found = BX_DBG_GUARD_CTRL_C somewheere in thee middle of the cpu_loop and hope it will break into debugger every instruction. It will not.
The thing that breaks you into internal debuger from cpu_loop is 'return' operand. If for example dbg_check_end_instr_bpoint returns 1 - it should break into debugger and it will. Nothing else is controlling this behavior. guard_found is ONLY for information, to supply debugger where, when and why we took that debugger break.
Actually I already completely removed BX_DBG_GUARD_CTRL_C from the CVS, you could take look and see - it still works and even keep breaking on Ctrl-C.

Stanislav

[stlw]

Most debuggers will only display one CPU at a time. So you only need to break one at a time.

And keep others running and completely lose control over it ?
They will change you a memory meanwhile, remember. And actually also could post you som interrupts and this way change you CPU state.
I am already not talking about system time that will keep running.
I thought debugger should help you to debug and not vise versa.

Also, a breakpoint in the simulated code will only break one CPU at a time. There is no reason for the others to stop.

There are a lot of reasons to stop. If you need a debugger - you want to track some failure. If you want to track some failure - you need to stop at some known state point and start tracking. You killing the whole purpose of debugger

Also, if a breakpoint breaks one CPU, and ALL of them stop -- then how do you (the user) know which one hit the breakpoint? It is very clear if only one CPU stops.

To supply you which CPU hit the watchpoint is trivial. Also trivial to make the watchpoints CPU specific. No need to do any complete mess for that. Actually CPU specific physical watchpoints can have some meaning but of course non-cpu-specific watchpoints are more important. You don't know who changed your variable and you want to stop when it changed - this is the puprose of data watchpoints. If you stop only on one specific CPU - you miss who changed your variable. If you keep running some CPU after hitting watchpoint - you can't say who hit either.

None of existing multithreaded debuggers I know do this. Including Intel CPU test probe hardware devices used for same puprose.
Once you want to stop for debugging - you stop EVERYBODY.
This doesn't mean of course that you should not run CPUs in parallel, BTW. They should run in parallel. But debugger break signal is ONE for all of them.

Stanislav

[bewing]

There are no non-standard controls used. Every control that is used is on this msdn list.

It is your compiler that is not windows-compliant.
The system .h file that contains these controls is called commctrl.h

Some of these controls DO have minimum OS requirements. If you look in that non-standard .h file of yours, you will see that all of the constants that are missing in the compilation are IN the file, but have #ifdefs around them. The reason they are not compiling is that you are not providing the right #defines for the #ifdefs from your compiler's command line. Find out what #defines you need, and then the compilation will work better -- except that there are two small bugs in the code you have, and the #pragmas that WindowsNT wrote seem to be slightly non-standard. I have better code with no pragmas and no bugs, and will send it to your osdev mailbox today, I think.

OK, I have simple proof for you. Add the line BX_CPU_THIS_PTR guard_found.guard_found = BX_DBG_GUARD_CTRL_C somewheere in thee middle of the cpu_loop and hope it will break into debugger every instruction. It will not.

If I add the line BX_CPU_THIS_PTR guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
to cpu_loop, and in bx_bool BX_CPU_C::dbg_check_end_instr_bpoint(void), I change the following test,

Code: Select all

	// convenient point to see if user typed Ctrl-C
	if (bx_guard.interrupt_requested && (bx_guard.guard_for & BX_DBG_GUARD_CTRL_C))  {
		BX_CPU_THIS_PTR guard_found.guard_found = BX_DBG_GUARD_CTRL_C;
		return(1); // Ctrl-C pressed
	}	// convenient point to see if user typed Ctrl-C

to say:

Code: Select all

	if (BX_CPU_THIS_PTR guard_found.guard_found == BX_DBG_GUARD_CTRL_C)  {
		return(1); // Ctrl-C pressed
	}

to replace the useless bx_guard.interrupt_requested with guard_found.guard_found, as I said would be
better, it works perfectly, and breaks on every instruction.
It is unfortunate that you got rid of BX_DBG_GUARD_CTRL_C. Now I will have to use a kludge instead.

To supply you which CPU hit the watchpoint is trivial. Also trivial to make the watchpoints .

I am not concerned about watchpoints. I am concerned about mode breaks. Please tell me how I am supposed to do the following:

The user has CPU(x)->mode_break set on two CPUs, of an 8 CPU system. One of the CPUs sees a mode change. It sets bx_guard.interrupt_requested. The whole simulation stops. Now: how do I show the user what caused the simulation to stop? How do I know it was a mode change? How do I know which CPU it was? You are leaving me no way to find out.

There are several other error conditions that set bx_guard.interrupt_requested, without telling me which CPU caused the error. This is also worthless.

[stlw]

It is your compiler that is not windows-compliant.
The system .h file that contains these controls is called commctrl.h

Some of these controls DO have minimum OS requirements. If you look in that non-standard .h file of yours, you will see that all of the constants that are missing in the compilation are IN the file, but have #ifdefs around them. The reason they are not compiling is that you are not providing the right #defines for the #ifdefs from your compiler's command line. Find out what #defines you need, and then the compilation will work better -- except that there are two small bugs in the code you have, and the #pragmas that WindowsNT wrote seem to be slightly non-standard. I have better code with no pragmas and no bugs, and will send it to your osdev mailbox today, I think.

I am sure it is just a story with compilation misconfiguration in Bochs under cygwin. But I can't solve the problem so fast, even new, when I now direction where to look.
It will take me might be a week of playing and trying to understand what the compiler wants.
But also another solution might be to reduce the Windows version requirements you have. Do you really need all these controls ?
It is OK to disable part of debugger functionailty if these controls are not available due to Windows version installed.
Remember, you told about compatibility yourself
I also think the best solution might be if you not compiling the win32_enh_dbg as .h file but add another .cc file instead.
And hopefully no threading or your new stuff yet. Hopefully not too much requirements in one shot

I am not concerned about watchpoints. I am concerned about mode breaks. Please tell me how I am supposed to do the following:

The user has CPU(x)->mode_break set on two CPUs, of an 8 CPU system. One of the CPUs sees a mode change. It sets bx_guard.interrupt_requested. The whole simulation stops. Now: how do I show the user what caused the simulation to stop? How do I know it was a mode change? How do I know which CPU it was? You are leaving me no way to find out.

There are several other error conditions that set bx_guard.interrupt_requested, without telling me which CPU caused the error. This is also worthless.

This is really good point. You know, legacy Bochs internal debugger had no support for many CPUs or even for x86-64 and I have no time for adding all this stuff.
So I am adding step-by-step the stuff I need for myself or users request
And only now internal debugger starting to become functional for all this stuff.
It is really good idea to add an info about which CPU caused a stop, I will add it to CVS soon.
And BTW, there is no need to change guard interfaces for this.

Stanislav

[stlw]

There are no non-standard controls used. Every control that is used is on this msdn list.

It is your compiler that is not windows-compliant.
The system .h file that contains these controls is called commctrl.h

Some of these controls DO have minimum OS requirements. If you look in that non-standard .h file of yours, you will see that all of the constants that are missing in the compilation are IN the file, but have #ifdefs around them. The reason they are not compiling is that you are not providing the right #defines for the #ifdefs from your compiler's command line. Find out what #defines you need, and then the compilation will work better -- except that there are two small bugs in the code you have, and the #pragmas that WindowsNT wrote seem to be slightly non-standard. I have better code with no pragmas and no bugs, and will send it to your osdev mailbox today, I think.

Actually I have some good news as well. I added "#define _WIN32_IE 0x0400" in the beginning of win32dialog.cc and managed to compile the code successfully.
I had to do only one more change - fixed double dot in

Code: Select all

val = BX_CPU(CurrentCPU)->xmm[i]..xmm64u(1);	// get the value of "xmm(i)_hi" register
val = BX_CPU(CurrentCPU)->xmm[i]..xmm64u(0);	// "xmm(i)_lo"

I still have ~40 warnings which I prefer to have fixed but they are not showstopper already, I could start with my testing !
BTW, at least one of them is REAL bug - in function FillAsm the variable 'p' accessed without being initialized.
The same for currlin valiable in FillPAGE function.

Stanislav

Stanislav

[stlw]

Now, when I managed first time to run your version, I could complain

Here is the list of my questions/complains I got after 5 minutes of playing with your debugger.

1. I don't see the menu which WindowsNT had in his debugger. The menu had many useful stuff.

2. The third (most right) window with memory dump is always empty. I have no idea how to add something to be printed there.
Anyway, just double click on the window is fine, or the menu. Any hotkey or other black magic is not a good idea !

3. I don't see any other reigister except very basic ones - no CRs and no segment registers. Where they disappeared ? WindowsNT version had them all.

4. It would be good idea to show some kind of promt between debugger outputs (of different commands) in the window. It is very hard to distinguish between them.

5. What is the N in 'step n" button ?

6. What is the meaning of 'proceed' button ?

7. The same question I had for WindowsNT - I would like to be able to resize debugger output window and make it small as 2 lines or big as half screen or even more.

8. Double click on, say, LDTR registers shows a dialog - do not know to set that register - double click on any other register has no effect.

9. If I press power down in simulator window - I would expect the debugger will close as well. In your GUI I have to press power down when simulator is running or strange sequence of power down + continue in the debugger.

Actually I still cannot access ANY of debugger functionality from GUI interface - it is just not available from anywhere.
I think something is globally broken in this first build.

Stanislav

[bewing]

Yes, I knew about the error in FillSSE. It is fixed in the new version.

Your menus are missing, clearly.
All the functions you cannot see are in the menus. They are also available as hotkeys, of course.

So now we just need to figure out why your compilation did not include the enh_dbg2.rc file. If the patch worked, then it should have been included from the win32res.rc file. Is your enh_dbg2.rc file in the main bochs directory? If you cat win32res.rc, do you see the #include "enh_dbg2.rc" at the end?

Filling the memory dump window is done from the menu (or hotkey). Showing other regiisters is done from the menu. Internal debugger prompts are displayed/hidden by a selection in the menu. The meaning of Step N? It is the same as in: bx_dbg_stepN_command. Proceed? It is the internal debugger "p" command, but I am getting rid of it.

7. Resizing is very hard. I don't feel like writing 300 lines of code to do it.

8 & 9. I will look at them again, and see if they work.

And in the version I will send you shortly, the threading is commented out, except for the fact that I am bypassing the internal debugger.

The issue about stop reasons has nothing to do with the internal debugger. I am not using the internal debugger for anything anymore.

OK, I fixed the error in FillPAGE.
There is no error in FillAsm, because i=BufLen is always 0 the first time through the loop, and p is initialized immediately. I changed it a little anyway, to prevent the warning.

The minimum OS requirement is Win98 -- there is no way to go to Win95 and have any of it run, at all.

In this version, the program cannot be turned into a .cpp file, because that would mean modifying the Makefile, which cannot be done with a patch.

[stlw]

Yes, I knew about the error in FillSSE. It is fixed in the new version.

Your menus are missing, clearly.
All the functions you cannot see are in the menus. They are also available as hotkeys, of course.

So now we just need to figure out why your compilation did not include the enh_dbg2.rc file. If the patch worked, then it should have been included from the win32res.rc file. Is your enh_dbg2.rc file in the main bochs directory? If you cat win32res.rc, do you see the #include "enh_dbg2.rc" at the end?

Filling the memory dump window is done from the menu (or hotkey). Showing other regiisters is done from the menu. Internal debugger prompts are displayed/hidden by a selection in the menu. The meaning of Step N? It is the same as in: bx_dbg_stepN_command. Proceed? It is the internal debugger "p" command, but I am getting rid of it.

7. Resizing is very hard. I don't feel like writing 300 lines of code to do it.

8 & 9. I will look at them again, and see if they work.

And in the version I will send you shortly, the threading is commented out, except for the fact that I am bypassing the internal debugger.

The issue about stop reasons has nothing to do with the internal debugger. I am not using the internal debugger for anything anymore.

OK, I fixed the error in FillPAGE.
There is no error in FillAsm, because i=BufLen is always 0 the first time through the loop, and p is initialized immediately. I changed it a little anyway, to prevent the warning.

The minimum OS requirement is Win98 -- there is no way to go to Win95 and have any of it run, at all.

In this version, the program cannot be turned into a .cpp file, because that would mean modifying the Makefile, which cannot be done with a patch.

Oops, it looks like patch merge error. I added the win32_enh_dbg.rc to the rc file manually and now it works fine.
Forget everything I asked before, I will try to come with new questions soon
For now - only one question:

- Showing the registers looks a bit weird. The FPU registers are not displayed correcty - the exponent is missing. The FPU tag/status and etc are not displayed at all.
The SSE registers display is useless. Instead of displaying single 16-byte value it shows some weird 0.000+e000. The MXCSR is also missed.
Also CR2 is missed in CREG display.

- Also please remove debug printf from xnn registers display.

I would ask you NOT add any interface changes (even commented) over the version I sent you recently.
It is working and starting to split into some another code will make merge hard to impossible !
You will have to maintain two branches if you want to go and develop smth completely different.
The code that going to be integrated into CVS for next Bochs release going to based on version I have now.

Stanislav