MS-DOS Programmer's Reference - Microsoft

Includes version 5! For me, this makes it pretty fancy, as I cut my teeth on MSDOS 3.3. I got this in the early '90s - it was already in a second-hand bookshop, and I pleaded with my parents for this and a copy of The Spectrum ROM Disassembly. I'm sad to say that I never really dug into this at the time - I'm sure there could have been some bonus adventures buried in here, although I think I probably managed to pick up enough from other sources.

Anyway, having sat on my shelves for nearly 30 years, I thought I'd read it. There are interesting lessons in history, and sometimes reading things from simpler times gives you better insights into the present.

The structure is a mixture of readable overviews of areas, mixed with pure reference data on data structures and system calls. I think this makes sense - you need the exhaustive enumeration, but that's not enough to get started, and those overviews allow you to see how it fits together better.

Despite that, it's still structured a little oddly. The data structures form a short appendix to each chapter, one chapter per subsystem, but then all the actual system calls/interrupts are put together in a separate (extremely long!) chapter. It feels inconsistent.

As you might expect, I did not read this cover-to-cover. I read the explanatory bits properly, and skimmed the pure reference, digging a more deeply into those parts that interested me. To be honest, the quality is not awesome. It's not dire, but if this were the early '90s and I wanted to do some serious programming, and this were my only reference (no net access, no Stack Overflow!), I'd have a lot of questions. It feels like corner cases and subtleties are missed, in both the explanations and reference. I'd end up having to guess/experiment or reverse engineer DOS.

Trying to diagnose what's missing, I think a decent number of examples would do the trick. e.g. Actually demonstrate minimising your memory footprint before exiting as a TSR. I remember when I was leading a project with medium-complicated algorithms, the best documentation was a link to the academic paper, a quick explanation, and a worked example. I think it's also interesting that we have a school of thought that unit tests can actually form one of the better API definitions. So, yes, examples would be nice.

It could be that "Oh yes, that's not reference, you want this other MS Press book for that, but strangely the only other MS book referenced in this whole thing is a stuck-in card for the MS Mouse Programmer's Reference, which doesn't exactly flesh this book out.

From the content angle, and the technology it describes, the transition from MSDOS 1.0 to MSDOS 2.0 is very clear; the point at which it stopped being a toy CP/M rip-off. FCBs are out, file-descriptors are in, these functions are now superseded, you may now have subdirectories (with lots of entries!). There are the inflection points where the modern world has arrived, and DOS starts to make upper memory and the HMA available. And there's a bunch of poorly-defined stuff about task-switchers, hinting at a relatively well-developed dead end. I enjoyed the chapter on device drivers, which allowed me to finally understand what those .sys files were, underneath the hood.

Is this worth reading? Very likely no! The only value is in nostalgia, and even then it's of the "I'm glad I didn't have to do serious DOS development during this period, with this kind of documentation!" kind. It slightly makes me want to try a little bit of real mode programming again, but to do so I'd be far better off with Turbo Pascal 5.5 and associated books (some of which gave me my very first insights into computer science, as opposed to just programming - maybe worth another retro-review sometime!).

Posted 2022-05-08.