DOSBOX debugger (installer 0.72) does not run in Windows 7.
WHY?
Look at the attached JPG. If u don't speak Russian - the alert says:
"The program "DOSBOX emulator" does not work and will be closed.
Click to close it."

I've found the heavy debugger to be incredibly useful for interrogating old assembly code of mine. I've noticed however that when single-stepping through a program, the dosbox display doesn't seem to update regularly. This can be frustrating when dealing with more complicated c-code because, for example, I tend to have to wait for an indeterminate amount of time to see a printf output.

Looking through the code it seems that the debug loop doesn't regularly call the render updates, which seem to all stem from VGA_VerticalTimer. Since this also adds several PIC events I can see why it would be a potential problem to have that regularly run while debugging, but would it be possible to force a display update with a command in the debug window? Is it in fact dangerous to run VGA_VerticalTimer while the debugger is broken on a line?

I was using auto, however a quick test with core=normal exhibits the same behavior. Specifically, the the dosbox window won't change after single-stepping over a "printf" call and in fact the only way to get an update seems to be to set a breakpoint past some code which takes a bit more time to run and hit F5.

In this case I'm testing with some straight c code compiled with borland turbo-c 2.01. Digging far enough down, the screen print inside the printf is an "INT 21h,AH=40h," dos write-to-file call with stdout (0x01) as the file handle. I believe the behavior on a direct write to video memory is the same though.

Debugger builds provided by Qbix are probably "heavy"; few bother with the middle ground. However, if you want to know for sure in any debugger build, there will be memory-change breakpoint commands (BPM/BPPM/BPLM) and CPU logging commands listed when you use the HELP command in the debugger.

ripsaw8080 wrote:Debugger builds provided by Qbix are probably "heavy"; few bother with the middle ground. However, if you want to know for sure in any debugger build, there will be memory-change breakpoint commands (BPM/BPPM/BPLM) and CPU logging commands listed when you use the HELP command in the debugger.

Thanks for your help,The Win binary executable, that I was referring to, indeed offers the BPM/BPPM/BPLM commands, so according to this criteria - this is an indication that this binary is the "Heavy Debug" version.

BTW: Do you know of any document that describes the functionality of debugger commands. I am teaching basic assembler to some young students and such description of debugger commands would come in really handy. I tried the DosBox Wiki at:http://www.dosbox.com/wiki/Main_Page...but I could not find any descriptions of the debugger commands there, e.g. the path where the HEAVYLOG command saves its results, etc...

There's a guide for the debugger in the guides section, but it's rather ancient, so might not be 100% accurate now. The guide is not in-depth; some familiarity with concepts found in other debugging environments is assumed. You can refer to the debugger source code for specifics that aren't obvious, if needed.

I am newbie on this forum and in dosbox development (and honestly in xNIX as well) so please be polity for my presumaby stupid questions.

I've tried to compile dosbox on Win 7, using latest MinGW/MSYS and pdcurses 3.4 with heavy debug option turned on. everything went fine but when debugger activated none of extended keys (arrow keys, Insert/Delete/Home/End/Page Up/Page Down) works. I've tried to use both latest SVN and RELEASE 0.74 revisions, but the result is the same. Digging into source code and debugging shown that funtion toupper changes correct key returned by getch function to wrong one for extended keys. For example: KEY_UP (0x103) turns into 0x3. What may be the reason of such odd behavior?

I've compiled doxbox successfully via MinGW+MSys in my Windows XP, event the heavy-debugger too. It needs SDL library for dosbox, and "pdcurses" for the debugger, to complete the works. I think I should post a topic to write down these steps so the others can save their time when they try to do this at next time.

Here I encounter a problem, that the dosbox.exe is 14,033KB big, and the heavy-debugger is 14,590KB too. I think it maybe contains much more "in-line debugging information" inside the EXE file. I'm working in Windows so I'm no so farmiliar to *nix, so how can I reduce the size of the output EXE file ?