To the Ineffable All,

I have a old, old DOS 2.0 exe file that I am debugging.  Everything goes fine with my DOS debugger (D86), until the it encounters an INT 10, AH=0, AL=10H, Set Video Mode.  That instruction clears the screen, and leaves the debugger brain dead, with barely enough smarts to process its quit command.  In other words, the program while  running through the debugger, shoots itself.  I suppose I could rig up some kind of dual monitor setup, but that would be a hassle.  Anyone know how to make the program run in one window, and the debugger in another?  Both the debugger and program have to run in a DOS window on XP.  Thanks,  Ratch
Posted on 2010-02-07 16:21:17 by Ratch
32-bit windows XP emulates DOS, including the Set Video Mode function. The exact method of emulation most probably interferes with the debugger. If you want REAL emulation, get the original DOS disks and run boot in Bochs. Only then will you be able to see EXACTLY what is going on.
Posted on 2010-02-07 17:27:42 by ti_mo_n

    Sorry I did not get back to you earlier.  I think I know EXACTLY what is going on.  The program is wiping the debugger out because they are using the same DOS window, same monitor, and the same video card.  So running on a true blue DOS O/S will not help me too much.  What I really need is a debugger that keeps its DOS window and the user window separate as far as software and hardware are concerned.  I don't know if that is possible when both the debugger and the program use the same video card, and the user program issues a  INT 10, AH=0, AL=10H, Set Video Mode that reinitializes the whole display.  How do programmers debug programs that utilize video display BIOS interrupts anyway?  At least one inquiring mind would like to know.  Ratch
Posted on 2010-02-08 21:58:35 by Ratch

Most debuggers use some kind of video mode/buffer swapping to save user screen when debuggee stops and restore it when you choose to run debuggee again. At least AFD and Turbo Debugger do it even in NTVDM. I've just checked it for simple mode 10h (640*350*4bpp) "Hello, world!" .Com program.
Posted on 2010-02-08 22:54:45 by baldr

Thanks for your reply.  What does AFD and NTVDM mean?  Anyway, I tried Borland's Turbo Debugger.  Although it did not crash, it lost its IP value, cleared the user screen, and could not be used for further debugging after a INT 10H, AH=0, AL=10H Set Video Mode instruction.  Ratch
Posted on 2010-02-09 00:33:03 by Ratch

AFD stands for Advanced Fullscreen Debug (1987), NTVDM is Windows NT subsystem that runs 16-bit (DOS and Windows) applications.

Which version of TD did you use? Mine (3.1) works fine (though I've tested only simple program that set video mode 10h, printed "Hello, world!" using 0Eh and set mode back to CO80).
Posted on 2010-02-09 02:35:42 by baldr
Considering using an x86 emulator like QEMU or Bochs, and taking advantage of the built-in debugger of those? Since you'll be doing emulation (rather than NTVDM's "encapsulation") you can get a "more true DOS experience", and the debugging QEMU or Bochs offers is less invasive than running a debugger in the host system.
Posted on 2010-02-09 05:01:24 by f0dder

Thanks for defining the acronyms.  I used TD Version 5.0 . So far, all I tried is a DOS box in a cmd DOS window.  Perhaps a full DOS machine will produce better results.  Ratch
Posted on 2010-02-09 10:33:05 by Ratch

    Sounds like good advice.  I will try to get up to speed on one or both methods.  Ratch
Posted on 2010-02-09 10:36:32 by Ratch
Fifteen years ago I employeed remote debugging in MS-DOS using Borland TD.EXE and TDREMOTE.EXE for video driver developement.
It was fascinating, I could step into INT10h BIOS with F7, watch the CRTC registers being updated step by step and its impact on screen of the second monitor.

I'm not sure if this will work with NTVDM, you will need null-modem cable and two DOS computers with serial port.
Posted on 2010-02-09 17:40:33 by vit$oft

TD employs smart screen swapping scheme, it almost survived mode-X (320*240*8bpp). Borland was one great SW company once upon a time.
Posted on 2010-02-09 18:30:13 by baldr
Ratch: one thing, though - last time I used the built-in debuggers for Bochs and QEMU, they were at about the level of user-friendliness as GDB... apparently there's a "new and friendly debugger GUI" (or several ones, looking at threads), but I dunno if any have been merged into the mainline bochs distribution... the default version compiled for win32 is very basic, not eving having SMP or VMX enabled.

EDIT: my bad, a graphical debugger is included with the default win32 distribution, you just have to enable it by copying bochsrc-sample.txt to bochsrc and "set stuff up" :)
Posted on 2010-02-09 21:46:44 by f0dder