R.I.P. MS-DEBUG 1981 - 2009

AlphaZeta writes "After 28 years, MS-DEBUG is finally being phased out in Windows 7. Over the years, people have been using MS-DEBUG for writing code (virus/malware, you name it) and debugging. "

Comments

Sad day

[Masa]

So much fond memories...

The Debug.exe was actually my first contact to programming and the first language I learned, was x86 assembler.

It was MS-DOS 2.xx and all my friends played with C64s and coded all kinds of cool things. My parents couldn't afford a C64 but they somehow got an old PC free. Demoscene was a new and hot thing in those days and me and my friend programmed our first demo completely using the Debug.exe. Merging the two code-bases was an interesting task, when all you had was two pieces of binary and some unused memory space for copy 'n' paste. The demo actually was quite cool. Unfortunately I have lost my only copy.

I used it to write and modify code

[AaronW]

Back in the DOS 2.1 days when I got my first computer I didn't have any manuals. I quickly found debug, though, and saw all the strings in command.com. A bit later I actually used it for things like disassembling the boot sector and even writing some tiny programs via machine code since Microsoft's assembler and linker costs a fortune at the time and I was in junior high and beginning high school. I even used it to crack a number of programs via the disassembler command. There was also an improved version of debug I managed to get a hold of called symdeb.

When I got the Borland (RIP) Turbo Assembler and their debugger I stopped using it.

I haven't touched it in many years, especially since I moved away from Windows in the early 1990s, migrating first to OS/2 and later to Linux.

Re:I used it to write and modify code

[mzs]

Here is another former TASM user piping up.

I remember when I was kid (pre-TASM) and my dad got a blazing fast internal ISA 2400 baud modem (hee hee). But it would not work right in Windows 3.0, it worked fine in a DOS program. Back then you had to assign an IRQ and port. The internal cards used the same as COM1 and COM2, but it should have been okay. The ISR should have checked the first card and then chained to the next. But it simply was not working, we had a serial port mouse and the other serial port was used for a printer (the machine had two printers one for carbon copy forms the other a laser printer for letters on the parallel port).

So after trying everything that I could think of I called MS support. Back then things were VERY different. The lady that answered spoke pacific NW English and was incredibly competent. She explained that some BIOSes were buggy and did not do the IRQ chaining correctly. We could not find an IRQ that was free that the modem card had a jumper for so she walked me over the phone commands to do in debug to patch a driver in Windows 3.0 to get around this issue. I was a freshman in high school at the time, that really left a mark on me. I had just learned how to use edlin before that. Soon after I got a copy of Turbo Pascal from this Polish guy I knew and I never looked back.

Before then I had only done Basic and later TASM (no relation Turbo ASM, that is what the cartridge+floppy interface was called, probably Tandy ASM) programming on a CoCoII. But that few minutes in debug got me hooked on modern systems and led to C/C++ TASM by the time I finished high school. I got a summer job just so I could afford Borland C++, it was something like $400 (student discount, I could not sell programs I compiled), the printed manuals it came with were incredible. DOS, Windows, dBase, WP all had incredible printed manuals too. Man have times changed.

Before TASM I sure did used debug a lot. It was a cheap assembler, disassembler (I needed to figure out some VGA routines from Borland), and you could use it a lot like you would dd on unix too.

Re:Article not quite right ...

[petermgreen]

Afaict debug is a 16 bit does tool for creating and debugging 16 bit dos apps. Since 64 bit windows doesn't support dos apps (or 16 bit windows apps for that matter) it wouldn't make much sense to include something that both is one and is a tool for working with them.

P.S. I find it amusing that wine on 64 bit linux can run 16 bit windows apps yet 64 bit windows can't.

But Visual Studio has its own Debug mode

[Orion Blastar]

so we don't need debug.exe anymore.

Anyone remember Borland Turbo Debugger or Microsoft Codeview? I used to use them to debug programs as well in Assembly Language.

feh

[ClioCJS]

bad move. debug.exe was the only way i could recover a harddrive that had a messed up partition table. No, neither fdisk nor the linux equivalent could fix it, not even with a full low-level format. only debug.exe. It was a damned weird situation. Linux lied and said it was fixed; Fdisk told the truth and said it couldn't fix it. Debug worked tho!!

It's not like it hurts by sitting there on the harddrive, taking up a whopping 28K (or however big it is)....

Re:feh

[evilviper]

Interesting, I never heard of anyone using DeBug like that, how'd you do it?

I wrote most of the FAQ for Computing.net forever ago:

http://www.computing.net/faq/contentdos/badsector.html

I think its been close to 15 years ago now... Little things you put out of your mind until someone brings them back up. Strange to see what a following my work has gotten these days.

Re:feh

[TheRaven64]

Wow, I'm glad I had Norton Utilities. It gave a nice hex editor view of files, or of regions of the disk. One of the fun things you could do with it was see how Elite savegames worked, and discover why copying them always failed. It turns out that Elite would write the data into a 512 byte sector and then truncate the file. The game data would still be on disk, but after where the OS thought the file ended. If you modified it in any editor, the entire disk block would be written back out and the bit of the file containing the real data would be clobbered. If you edited it in nu you could change the values after the supposed end of the file.

Awwww....

[feepness]

This was how I cracked Ultima V. They had a special sector on the floppy(!!) and read code off it, put it in the right place, and then ROT13ed that code.

I traced through until I was past that point, added nops where the read/ROT13 was, and rewrote the exe. I thought I was a genius.

RIP MSDEBUG.

Already gone...

[faragon]

... for XP64 and Vista64.

Here is my last tribute:


C:\Users\faragon>copy con hifolks.com
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz^Z
1 files copied.

C:\Users\faragon>debug hifolks.com
-a 100
187E:0100 jmp 112
187E:0102 db "Hello Slashdot!$"
187E:0112 mov ah,9
187E:0114 push cs
187E:0115 pop ds
187E:0116 mov dx,102
187E:0119 int 21
187E:011B int 20
187E:011D
-w
Writing 00048 bytes
-q

C:\Users\faragon>hifolks.com
Hello Slashdot!
C:\Users\faragon>

Re:Article not quite right ...

[EvanED]

P.S. I find it amusing that wine on 64 bit linux can run 16 bit windows apps yet 64 bit windows can't.

Actually, I'd be interested in knowing how this works (assuming it's true). Does Wine do some sort of binary translation? To my knowledge 16-bit instructions aren't available in 64-bit mode, so it can't just be running it natively. Does it do that with all programs, or just 16-bit ones? Anyone know?

Re:Wrong, Wrong and Wrong

[mzs]

"due to the fact that the x86-64 CPUs cannot switch to 16-bit mode."

????

AMD64 CPUs most certainly support real mode. In fact that is how they boot, how else would you expect the VGA bios to execute during boot?

They also support Virtual 8086 mode which you are confusing with 16-bit mode. The issue is that in Long mode (which is all that 64-bit MS OSs supprort) you cannot run in those modes. Instead you either run in 64-bit mode or compatibility mode (32-bit or 16-bit, no extra regs). MS certainly could have provided a way to switch between Long mode and Legacy mode but chose not to. Then when encountering a real mode program it would switch to Legacy mode. These switches are not cheap though, you'd likely have do things like quiesce DMA, and that is why MS decided to ditch it. In fact there was a similar issue with the 80286 and 16-bit protected mode, essentially a soft reset was needed to get back into real mode but that was done back then (with the advent of Windows 3.0) since so many programs would have been unusable otherwise.

Re:Article not quite right ...

[petermgreen]

Actually, I'd be interested in knowing how this works (assuming it's true)
It's most definately true

Actually finding out how wine does 16 bit code is trickier. I've found out from the documentation that it involves something called "winevdm.exe.so" but i dunno how that binary does it. I guess it would be possible to RTFS but I don't care enough to do that.

To my knowledge 16-bit instructions aren't available in 64-bit mode, so it can't just be running it natively
You can't do 16 bit real mode code under a 64 bit kernel. I'm not sure what the situation is with 16 bit protected mode code (wikipedia claims it's possible but doesn't provide a citation for that claim)