Why does NTVDM create empty IO.SYS and MSDOS.SYS files?


A:-)Brunuś asks why NTVDM creates empty IO.SYS and MSDOS.SYS every time it starts up.

For compatibility, of course.

Specifically, it was added for one particular program that searched for the MS-DOS system files, and if they are missing, it got confused and corrupted your CONFIG.SYS file.

This reminds me of another program we discovered in Windows 95 that parsed your SYSTEM.INI file, and if any line in that file was longer than 80 characters, it deleted your SYSTEM.INI file outright. That'll teach ya.

Comments (23)

  1. Tanveer Badar says:

    Was that program a virus? What the hell were those programmers thinking deleting a system file, any system file.

    1. Joshua says:

      It’s probably trying to modify it and has some really bad code handling parse failures.

    2. The MAZZTer says:

      If you installed Myth II to C:\ (eg not in a directory of its own, just C:\) and then uninstalled it it wiped the entire drive. Never attribute to malice that which can adequately be explained by stupidity.

      In this case, they probably had code to parse out their own INI files and wiped it if they believed it was corrupt. They likely reused it for parsing SYSTEM..INI without thinking.

      1. Antonio Rodríguez says:

        Most MS-DOS programs, and many early Windows ones, assumed the program’s directory belonged to the program. Most of those programs didn’t provide an uninstaller (uninstalling was as simple as deleting the program). And of those that did, they usually didn’t bother to keep a list of installed files, but instead did a recursive delete.

        1. A favorite blog: https://blogs.msdn.microsoft.com/robmen/ “when setup isn’t just xcopy”

    3. Antonio Rodríguez says:

      These were the times where you wrote programs in plain C or assembler. In both cases, strings were static byte (“char”) arrays, with a fixed length. A parser was usually a fixed-length string buffer plus a state machine. You read one line from the input file, parse and/or modify it, write it to the output file, and update the machine’s state. After finishing, you delete the original file and replace it with the modified one. That way, you could process arbitrary sized files using a very limited amount of memory. If the buffer is 80 bytes long (who would ever write a line longer than the screen’s width?) and the program didn’t handle errors correctly, you can guess what happens with longer lines :-) .

  2. Ted Spence says:

    Question: On the right hand side, you have all these fascinating categories. Would it be possible to request a category called “It rather involved being on the other side of this airtight hatchway” so we could read all the great security vulnerability reports that turned out to be non security vulnerabilities?

    1. I really have only four categories (History, Code, Other, Non-Computer, Tips/Support), with a Microspeak subcategory. The rest are legacy and not really used. They used to be hidden from the page but I haven’t gotten around to hiding them after the migration to the latest blogging platform.

      1. Roman says:

        That’s unfortunate. The airtight hatchway series is one of my favorites.

        1. zboot says:

          You missed the fifth category in the list of 4. . .

          1. Sorry, I don’t follow. There are five categories (Code, Non-Computer, Other, History, and Tips/Support).

    2. Brian_EE says:

      In the upper right corner of the webpage (at least when viewed on a desktop browser) there is this icon that looks like a magnifying glass. If you click it and type the words “Airtight Hatchway” into the textbox, it will search and show you all of Raymond’s articles about dubious security vulnerabilities.

      Works just as well for any of the other series (thermonuclear, wisdom 7th graders, etc) as well.

  3. Yukkuri says:

    More app compat war stories please :) so hilarious

  4. slipstream says:

    so what happened if you ran that program on a version of DOS that used IBMBIO.COM and IBMDOS.COM rather than IO.SYS and MSDOS.SYS? did it also corrupt CONFIG.SYS there?

    1. I don’t know. Maybe it checked for the IBM versions too?

    2. I wouldn’t be surprised if it reformatted your hard drive. As bad as most Windows software is, DOS software is a whole ‘nother world of badness.

  5. cheong00 says:

    Ah… those setup programs in the old days.

    I remember one they renames your current config.sys and autoexec.bat to config.old and autoexec.old, then replace them with the version come with the program, without bother trying to merge the changes.

    Then again, with multi-config, it could be tricky. And btw, at least they remember to give you a backup. And btw2, if you something try to install the program twice in a row, the backup got replaced by their version too. //faceplam

  6. > This reminds me of another program we discovered in Windows 95 that parsed your SYSTEM.INI file, and if any line in that file was longer than 80 characters, it deleted your SYSTEM.INI file outright.

    Nowadays, it is called a malware. It is hard to imagine there was a time when apps were allowed to do whatever they wanted.

    1. Antonio Rodríguez says:

      Remember that these were the days of limited resources, where programmers were supposed to know what they do.

      1. SimonRev says:

        Yet they didn’t have the benefit of the modern Internet or really much of anything other than a book or two.

        If it wasn’t plastered in their book, the only other real option was to attempt to reverse engineer whatever system they were working on and do their best. Also in those days, merely parsing an ini file would be something you wrote from scratch and you probably only had a couple different files to test against. Bugs were inevitable.

        1. Very true. Need is pretty much what dictates the complexity of a system, especially the constraints.

          When the software community is small, well, you slap a compatibility shim into the OS to virtualize SYSTEM.INI file access and don’t dignify it with such a long word as “virtualize”.

          For a medium community, NTFS permissions, UAC and write virtualization would do fine.

          For a large community, it is application virtualization all the way! No app sees anything beyond its sandbox, hardware access needs permissions, etc. Why would an app need to see the whole file system anyway, when it is not supposed to bother with it?

      2. Antonio Rodríguez says:

        That was my point. Coding decisions that nowadays would give us goosebumps, were perfectly understandable 20-30 years ago. Because of the limited machine resources, scarce documentation, and little need of forward (or backward) compatibility. There were very few programming taxes back then (and even those would go unpaid most times).

        For example, many games of the era simply instructed to boot the system from a clean boot diskette if the current installation of DOS didn’t leave enough free conventional memory for the game to run. The developers could have adjusted the game so it ran with 550 KB of free conventional memory, but instead many of them required 600 KB (or even 620!), and left the burden on the users. And, for the ones too young to remember MemMaker or QEMM Optimize, it was often difficult to get over the 620 KB line… But that’s another story, and it must be told at another time.

Skip to main content