The old DEBUG program can load COM files bigger than 64KB, but that doesn’t mean they actually load as a program

Some times ago, I described why a corrupted binary sometimes results in the error "Program too big to fit in memory". Commenter Neil was under the impression that nonrelocatable programs files could be larger than 64KB and used the DEBUG command to verify this assertion.

While it's true that DEBUG can load files bigger than 64KB, that doesn't mean that they will load as a program. If DEBUG decide that you didn't give it a program (the file extension is not EXE or COM),¹ then it treats the file on the command line as a data file and loads it into memory in its entirety, provided it fits in memory in its entirety. When it does this, the BX register contains the upper 16 bits of the file size, and CX contains the lower 16 bits. This is also the format that is used when writing files back out: Use the n command to set the name of the output file and set BX:CX to the file size.

Even though DEBUG has been obsolete for over a decade, it is still useful for exactly this purpose: You can use it as a hex editor for files less than around 512KB.

But don't deceive yourself into thinking that you created a COM file that is bigger than 64KB.

¹There is another extension which has special meaning to DEBUG, but it's not relevant to the discussion.

Comments (22)
  1. Danny Moules says:

    "There is another extension which has special meaning to DEBUG"

    Would that be .hex, then?

    "but it's not relevant to the discussion."

    There was absolutely no chance this wouldn't come up in the comments, disclaimer or not :p

  2. JoostM says:

    If I recall correctly, .BIN files loaded at address 0x000 instead of the 0x0100 for .COM files.

  3. Greg D says:

    I fondly remember using DEBUG on my ridiculously simple ASM programs back in the days before I had anything else.  :)  It was a useful program!  (Though I wasn't doing a whole lot with it– I think the most complex program I had to write for that class just output the first X numbers of the Fibonacci sequence)

  4. sukru says:

    It might be a good time to ask what happened to debug. I cannot find it on my Win 7 machine anymore… :(

    One more thing, checking the old discussion archive I've learned that the later versions of Command.Com was actually an EXE file! –…/519388.aspx

  5. Tanveer Badar says:

    Evil debug scripts were fed to debug with -a and stuffed into autoexec.bat on 9x, resulting in reboot cycles after executing int 17 h. ]:)

    Debug was fun.

  6. ErikF says:

    @sukru: DEBUG was always only a 16-bit program.  With Windows 7 getting rid of the 16-bit stuff, so went DEBUG….

    As an aside, the amount of things that DEBUG can do is quite impressive given its size!  I remember playing with it after I graduated from playing with BASIC and learning other programming languages.  It gave me my first look at how programs worked behind the curtains and made me appreciate the enormous effort needed to get a computer to do anything.  (I also learned about EXE2BIN later on and even used it a couple of times before I learned how to get the compiler to directly generate .COM files!)

  7. John Muller says:

    I use it still to check the encoding of text files, particularly for the Unicode 'Byte Order Mark' (BOM)

    But then I also open executables in Notepad and browse them… anyone got a hammer? I need to tighten some screws.

  8. Antonio Rodríguez says:

    @ErikF: Windows 7 isn't getting rid of "the 16 bit stuff". Windows 7 32 bits is perfectly compatible with both DOS and Win16 applications (in fact, it is MORE compatible than Windows XP because it fixes the 16/32 bit handle translation bug present in XP and older OSes). It's Win64 who removes the NTVDM 16 bit virtual machine and breaks compatibility with DOS and Win16. But there has been three releases of Win64 (XP, Vista and now 7) in the last six years. Windows 7 is just the first version of Windows widely used in 64 bit.

    Anyway, DEBUG, being a simple imitation of the Monitor built into the ROM of every Apple II, remembers me of times when things were simpler, when you could understand perfectly how each piece of the system worked. These were, as they say, the days when men were men, and they wrote their own device drivers. Sadly, now we are over a lot of layers which hinder our understanding of what's bellow our feet…

  9. Crescens2k says:

    @Antonio Rodriguez

    The reason why x64 versions of Windows don't allow NTVDM or WoW is very important, and it wasn't done to just break compatability. Whats more, if you look at the server versions of Windows then you will know that 2008 released both x86 and x64 versions, but 2008 R2 only released an x64 version (I know that there is an IA64 version of server, but that isn't directly runnable on the x86 hardware). So only the client version of Windows was the only one with 16 bit compatability. So they have gotten rid of the 16 bit stuff in the server versions already, who's to say that the next version won't get rid of it in the client version too.

  10. Pedant says:

    Ah, good ol' debug.  I used that recently for the first time in a good 20-odd years.  For reasons which now escape me, but I'm sure made perfect sense at the time, I was doing so on a floppy boot disk within Virtual PC.  And I had forgotten how 16-bit addressing worked.  Hours of fun!

    I don't know why Microsoft bothers making Xboxes, really.  You should just hand out copies of MS-DOS and let kids make their own entertainment.  Ee, when I were a lad, &c.

  11. Jonathan says:

    @Crescens2k: 64-bit Windows doesn't run Win16 apps, but it does have NTVDM and can run 16-bit DOS applications.

  12. Dave says:

    No 64-bit Windows has had NTVDM because x86-64 CPUs do not support simultaneous real mode and long mode.

    DOSBox, for example, can work in 64 bit Windows because it emulates the CPU.

  13. Neil says:

    If that was me, then I obviously didn't look hard enough: EDIT.COM is 69,886 (0x110FE) bytes, and DEBUG.EXE loads it in such a way that it runs. Obviously I don't know whether MS-DOS itself loads EDIT.COM in the same way.

    None of this should be treated as invalidating anything Raymond has said, but just to point out that the picture is still incomplete.

    [I didn't realize that I had to give a complete picture. I was just looking at one small part. Here's a look at another small part. -Raymond]
  14. ender says:

    Microsoft could have easily supported 16bit Windows (and DOS) programs on x64 – after all, Windows NT for non-x86 platforms included an x86 emulator for NTVDM, they just chose not to.

  15. Klimax says:


    Given number of quirks to be found in 16-bit apps (be it for dos or win) I doubt it would toousefull without extensive effort.

    (And support for non-x86 platforms was killed before release of Win2000)

    I prefer to have new things in x64 then support for old software which can hapippily run on x86.

  16. Stephen says:

    EDIT.COM is actually an EXE file, it starts with MZ. Lots of DOS COM files became EXE files as new versions of DOS were released, but they kept their .COM extension for compatibility reasons…

  17. Joseph Koss says:

    The purpose for providing an x86 emulator on the older non-x86 NT's was to run x86 applications in an era where most applications were x86. It was never specific to 16-bit. These days, most applications are still x86 but almost none are 16-bit. Since x64 can run 32-bit x86, the need for an emulator is almost zero.

    Things like DOSBOX do more than emulate an x86 CPU. They also emulate common hardware from back in the day, such as SoundBlaster 2.0/Pro's, so that games from that era will run.

  18. bzakharin says:

    I seem to recall that an "edit.exe" was available to download from the MS website around the time Windows 95 came out (but I think it worked in older DOS versions as well). It was "new and improved" (though I don't recall what the new features were), but dropped its dependence on QBasic. I think, however, that the version of Edit that came with Windows 98 had a .COM extension once again. I wonder what that was all about?

  19. Antonio Rodríguez says:


    I didn't said that Win64 excluded NTVDM in order to break compatibility; I just said that it breaks compatibility because it doesn't include NTVDM. I didn't want to complicate my comment, so I chose not to enter into the technical reasons behind it. NTVDM runs in Virtual-86 mode instead of emulating the CPU in software, and X86-64 processors do not support the Virtual-86 mode when in long (64 bit) mode. Because of that, you would need a complete rewrite of NTVDM as an x86 emulator in order to work in Win64, and Microsoft chose not to spend resources on it. Maybe it was the right option, or maybe not. But it was technologically sound.

    Anyway, removing 16 bit compatibility in the server side is easy: a server will only run server services, and it has no need to run 15-year-old legacy applications. But the client version of Windows, which is used by zillions of business that still depend on mission-critical 16 bit applications, is a horse of a different color. That, and the need to support 32 bit applications incompatible with UAC, made Windows XP Mode a more viable option than rewriting NTVDM. That it is available only in Business and Enterprice versions of Windows 7 is a good hint of that.

  20. Neil says:

    Thanks, that second small part (also summarised by Stephen) was mostly what I needed.

  21. Neil says:

    OK, so although it looked like DEBUG loaded .COM files the same way that it loads non-executable extensions, it doesn't set up an environment block or other metadata necessary for the file to execute correctly. So for instance if you rename a .COM file to .BIN then you can't load and run it in DEBUG. (Well, possibly excepting MS-DOS 1.0, in which DEBUG couldn't even load .EXE files.)

  22. facts says:

    NTVDM does not run in Virtual-86 mode. W9X did, but not NT.

Comments are closed.

Skip to main content