DEBUG.EXE is so cool! I love how you can just start assembling a program piece by piece and easily experiment with what random instructions do. It feels like duch a great tool for learning assembly, even despite it being so barebones.
I wish I knew a modern tool that was similar to it.
To me, that sounds similar to the Unicorn emulator. It has a Python API so it can be used in a REPL that way, but there are also interfaces built on GDB, Rizin, or Cutter for interacting with it.
It looks like this started as a blog post in 2003 (https://susam.net/programming-with-dos-debugger.html). If the code was imported to git from another VCS, it’d retain the timestamp. Git timestamps are normally taken from the system clock, but are fully client-side, and can be anything.
That’s exactly what happened. Back in my university days, I ran a small intranet web portal on our university LAN and occasionally wrote simple technical articles for it. Back then, I would manually type in machine instructions into DEBUG.EXE to learn assembly. I wrote the blog post you referenced to share this learning method with my fellow students. For anyone wondering why I used DEBUG.EXE, it was simply what I had available back then, as I hadn’t yet discovered more sophisticated tools like NASM.
As for the Git commits, yes, they were imported from another version control system, CVS, if I recall correctly.
I was goofing around with 16 bit assembly on DOS around that same time too. I didn’t have my own computer till…. I think it was 2002, and it was my mother’s old pentium 1 box she handed me down. The Windows API looked complicated but asm on DOS was nice and easy - it is nice to do a little setup block (mov ax, 13h; int 10h;) then write a few bytes and have stuff drawn on screen. And it performed well enough to have fun with! I did later figure out the Windows API (and nowadays I like a fair amount about it), but that same kind of pixel pushing was much slower there, so never quite the same as the good old dos vga asm.
In the absolute scheme of things, that’s not particularly clever. It does, however, emphasise what’s been lost now that most debuggers insist on having an executable file as a prerequisite.
What /was/ clever was the Kermit bootstrap program, which implemented a very simple file-transfer protocol using only printable characters, so that the .com file containing it could be moved around with no risk of its being mnagled en route. In total, I think it was somewhere around 100 bytes.
What /was/ clever was the Kermit bootstrap program, which implemented a very simple file-transfer protocol using only printable characters, so that the .com file containing it could be moved around with no risk of its being mnagled en route. In total, I think it was somewhere around 100 bytes.
What actually was clever is the (now missing?) tool that generates such printable x86 executable code.
The Kermit bootstrap program just was an excellent use case for it.
DEBUG.EXE is so cool! I love how you can just start assembling a program piece by piece and easily experiment with what random instructions do. It feels like duch a great tool for learning assembly, even despite it being so barebones.
I wish I knew a modern tool that was similar to it.
In Amiga we had the venerable AsmOne.
(Today we have AsmPro and AsmTwo)
Maybe not so modern, but there was a nice interactive x86 assembly environment / tutorial called Ketman - https://web.archive.org/web/20070227110806/http://www.btinternet.com/~btketman/tutpage.html
To me, that sounds similar to the Unicorn emulator. It has a Python API so it can be used in a REPL that way, but there are also interfaces built on GDB, Rizin, or Cutter for interacting with it.
I am sorry, I really don’t understand what is so interesting about this? This is just the standard hello world program for DOS. What am I missing?
also, how did you make your first commit in 2003?
It looks like this started as a blog post in 2003 (https://susam.net/programming-with-dos-debugger.html). If the code was imported to git from another VCS, it’d retain the timestamp. Git timestamps are normally taken from the system clock, but are fully client-side, and can be anything.
That’s exactly what happened. Back in my university days, I ran a small intranet web portal on our university LAN and occasionally wrote simple technical articles for it. Back then, I would manually type in machine instructions into DEBUG.EXE to learn assembly. I wrote the blog post you referenced to share this learning method with my fellow students. For anyone wondering why I used DEBUG.EXE, it was simply what I had available back then, as I hadn’t yet discovered more sophisticated tools like NASM.
As for the Git commits, yes, they were imported from another version control system, CVS, if I recall correctly.
You can edit commit dates https://stackoverflow.com/questions/454734/how-can-one-change-the-timestamp-of-an-old-commit-in-git. I betcha that’s when the author first did this and when adding it to git, edited the date to match the original file creation day.
I was goofing around with 16 bit assembly on DOS around that same time too. I didn’t have my own computer till…. I think it was 2002, and it was my mother’s old pentium 1 box she handed me down. The Windows API looked complicated but asm on DOS was nice and easy - it is nice to do a little setup block (mov ax, 13h; int 10h;) then write a few bytes and have stuff drawn on screen. And it performed well enough to have fun with! I did later figure out the Windows API (and nowadays I like a fair amount about it), but that same kind of pixel pushing was much slower there, so never quite the same as the good old dos vga asm.
good times. good times.
In the absolute scheme of things, that’s not particularly clever. It does, however, emphasise what’s been lost now that most debuggers insist on having an executable file as a prerequisite.
What /was/ clever was the Kermit bootstrap program, which implemented a very simple file-transfer protocol using only printable characters, so that the .com file containing it could be moved around with no risk of its being mnagled en route. In total, I think it was somewhere around 100 bytes.
What actually was clever is the (now missing?) tool that generates such printable x86 executable code.
The Kermit bootstrap program just was an excellent use case for it.