Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by CmdrTaco on from the gone-the-way-of-edlin dept.

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. "

5 of 240 comments (clear)

  1. Sad day by Masa · · Score: 4, Interesting

    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.

  2. Re:Article not quite right ... by petermgreen · · Score: 4, Interesting

    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.

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  3. feh by ClioCJS · · Score: 4, Interesting
    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)....

    --
    -Clio
    Karma: Bad (mostly from not giving a fuck)
    Blog: http://clintjcl.wordpress.com
  4. Re:Wrong, Wrong and Wrong by mzs · · Score: 4, Interesting

    "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.

  5. Re:I used it to write and modify code by mzs · · Score: 4, Interesting

    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.