Programming with DOS Debugger (2003) | Hacker News Reader

Programming with DOS Debugger (2003)

susam.net

42 pointssusam26 comments

Ooh, I used to play around a lot with DEBUG.EXE when I was like 12. To this day, almost without looking at the keyboard, I can enter some assembly that enters Mode 13h and draws stuff on screen.

These days, I sometimes play with it to debug a pet project (Lithium, an x86 assembler and toy Lisp compiler targetting bare metal and .COM binaries, written in Clojure). And sometimes I discover things I wasn’t aware of: https://blog.danieljanus.pl/2014/04/06/dos-debugging-quirk/

Are you running on QEMU? How do you make t stop after every step? And why did t did not stop at mov bp,sp for you?

I can't get tracing to work at https://copy.sh/v86/?profile=msdos

Modified OP's code to add more steps to see some stepping through but T makes the program run all the way to termination - https://i.imgur.com/hiYeC2x.png

Looks like v86 doesn’t implement the INT 3 (0xCC) opcode, which the debuggers use to step through: https://github.com/copy/v86/discussions/653

I tried in DOSBox. It was years ago, so I don’t remember all the details. Maybe it’s a DOSBox issue that has since been fixed!

I think the CPU emulator of that website is just buggy

Do you know why in nathell's link the first t does not stop at mov bp,sp? It stops at other lines but not that one. Could that be a buggy emulator too?

I think the UI is just confusing. T means „execute the instruction at CS:IP, advance IP and display the next instruction to execute”. So the first T executes the first instruction but displays the second.

I'll try it later on a physical machine.

I'm a serious retro-computing fan, and as a result of my activism one of my sons friends has re-discovered his families Commodore PC-20-II DOS PC in the attic.

We resurrected it with great joy and interest as to what we would find on this machine - apparently it had been in his family since it was bought, brand new, back to his grandfathers house, where it was used for a few months (!) before being 'put in the attic because it was broken'.

So, we dig it out, boot it up, and try to figure out what exactly is broken. I immediately notice that any .COM file I execute gradually gets bigger .. yes, its got one of the very first TSR .COM infecting viruses on it, and thats why granddad put it in the attic ..

So we have now isolated it and gotten it booting, and are using the onboard DEBUG.COM to attack the virus, neutralize it, control it and see what else we can do with it. Just the presence of DEBUG.COM alone has made this an exciting and fun project for the kids, who are learning all about filesystems and DOS .com/.exe differences, and TSR's and BIOS calls and so on ..

This aspect of FUN is seriously missing from modern computers!

I think what is missing is the ability to really influence "what the computer does" with the tools it got shipped with. Yes, it is no problem to just download python or scratch or what else, but what is missing is the feeling i got on my C64 when it first booted: This opportunity to just start to play around, write little programs and just directly tell the machine "what to do".

Oh, this makes me remember that I had a 386 PC with the "yanke doodle" virus on it, which was fairly harmless and just played a song once a month on the speaker.

I lived with the virus and at one point I printed all the assembly in it with my matrix printer and tried reverse engineering it. But it was just way too much code for me to understand it all.

I could write symbolic assembly within Nokolisp. Sentences were feeded straight into DEBUG and numbers were absolute addresses within COM-file. This is superfast fibonacci.

    (defun fib2
     (x)
     (AX-reg x)
     (assembly
      (CALL 272)
      (JMP 320)
      272
      (CMP AX , 2)
      (JC 304)
      (push AX)
      (sub ax , 1)
      (call 272)
      (MOV BX , AX)
      (POP AX)
      (PUSH BX)
      (sub ax , 2)
      (call 272)
      (pop BX)
      (add AX , BX)
      (RET)
      304
      (RET)
      320)
     (AX-reg))

It was trivially easy back in the day to use DOS DEBUG to rewrite COMMAND.COM so that instead of giving an error message like "Command not understood" or whatever the default was, it instead responded with, eg:

"My hovercraft is full of eels"

The height of school humour. As long as the replacement was shorter than the original it was just a text substitution.

I did similar things as a kid. But I used Norton Disk Editor. It made it a lot easier.

When I was a kid I managed to lose the contents of my hard drive because I overwrote the FAT when playing with DEBUG to understand how it worked.

Oh well, I guess that day I learned something after all.

I remember MASM and Codeview. I cracked Lotus 123 2.0 with it to remove copy protection so it could be installed on a Netware drive.

My first assembly programs were written using debug.exe as the assembler. That allowed to go beyond batch files.

I did something similar. I ended acting as a human two-pass assembler before I before I got a real assembler.

My source was in text files. I'd script them into DEBUG to assemble them just like in the article. I'd put NOPs in place of branching instructions, script the source into DEBUG, and then use the output to get the calculated offsets for the intended branches. Then I'd go back and put the branches and offsets into the code.

Nothing frustrated me more than having to insert code and recalculate all subsequent branches. I ended up peppering a lot of NOPs into my early programs so I'd have "spare" bytes to use for instructions I needed to add.

Getting a real assembler made a huge difference in my workflow. Translating DEBUG scripts into MASM/TASM-compatible source wasn't awful either.

This is going to be ridiculous, but I didn't know that DEBUG.EXE (or DEBUG.COM as I remember it?) could be used to assemble! (maybe my version couldn't, now that I think of it). I found it when I was a 10 year old, and I could only use it to disassemble memory, and input hex values into memory. So I would write my program on paper, hand assemble it, and then enter the hex codes into debug.com. If it crashed, too bad, I would have to reenter it all over again.

I did have a lot of time away from the computer (my parents only allowed one hour per day), so this was overall a pretty good workflow. I did learn a fair amount doing this.

A lot of my early x86 assembly language programming was done in debug.exe before I could afford MASM.

One command that is burned into my memory was invoking the low-level formatting routine on a hard drive:

    g=c800:5

I'm afraid to ask why that particular command is so well memorized for you, but at the same time I'm curious...

At risk of piling on. I too used DEBUG in my youth to write programs on school computers.

For a change of pace anyone coming here who hadn't heard of DEBUG.EXE? How old are you???

I thought everyone did this at that point in time.

The most interesting thing I did with debug.exe was to remove the silly write protection our schools PCs had in 7-8th grade and the installed some shareware (I think!) C++ compiler that I had found one the front page of a magazine. I didn't even really program C++ back then, mostly assembly and basic.

Removing the write protection was as simple as overwriting an ISR or something similar. It took very little time anyway.

I did not until about 18 - 20 and only heard of it as a historical artifact.

Currently 21.

Who remembers when it was DEBUG.COM?

I remember that in the first chapters of their Assembly Language Book, Peter Norton and John Socha used DEBUG to teach the principles of assembler and build a few simple programs. After this introduction, they moved to MASM and TASM for the remaining chapters.

Awesome book, it taught me a lot.

Reply on news.ycombinator.com