1. 9
  1. 5

    Wow, this brings back some great memories! Sometime in high school I wrote a whole little “snake” game in DEBUG (using mode 13h) just because it seemed like fun at the time. It was super hard to play because snake velocity was in pixels/sec and the non-square pixels made the X and Y speed slightly different. Fun times.

    I guess it’s easy to think about those times and feel like we’ve lost the simplicity, but the reality was that we were messing with DEBUG because its all we had (OK, we had Turbo Pascal and QBasic too). The way the free software and Linux ecosystems have opened up tools and technology to folks without money since the 90s is amazing. I can’t imagine what cool stuff we could have built with today’s tech.

    1. 2

      A little late to the party here, but DOS World magazine used to do this all the time to “distribute” tiny utilities. See page 13 of this issue for an example: https://archive.org/details/dosworld020199503/page/n13/mode/2up

      Trying to reverse engineer those little things really got me interested in how everything actually worked under the hood.

      1. 2

        I wrote some tiny things with debug, but quickly hit the wall this article is pointing to: it requires you to know offsets for data in advance, which makes it hard to write anything non-trivial. This was a great lesson in why an assembler is called “assembler” and the difference between that and raw machine code.

        At the time, MASM was expensive and not that easy to find. Presumably due to low volume of sales, it was later bundled into Visual Studio and I’ll bet 99% of people with it installed don’t know they have it today. I’m also fairly sure it was freely available in the Vista/Win7 SDKs.

        Note that windbg has a facility similar to debug of dynamically encoding instructions, although it’s not built-in to Windows, but is freely downloadable.