Heh, I was about to point to that same paragraph because of how disingenuous the term "backwards compatibility" is. I'm sure the author wasn't intentionally trying to revise history and probably didn't think about the term much, but to set the record straight, DOS wasn't a successor to CP/M, but a "quick and dirty" clone, then later an actual competitor. COM files were included in DOS to make sure programming for it was similar to programing for CP/M.[1]
The story (which I'm sure many of you know) was that in 1979, Seattle Computer was selling an 8086 board, but CP/M didn't run on that CPU yet. So Tim Paterson solved the problem by whipping up QDOS to help sell more boards, cloning the architecture and APIs of CP/M directly from the manuals (without access to the actual source code).[2]
The simplest sort of executable code is a COM file (doesn't get much simpler, actually), so if you're copying the way an OS works, that's pretty much where you'll start. It was about being a familiar paradigm for programmers, not some sort of cross-platform binary compatibility to an out of date OS as insinuated by the term "backwards compatible".
"Intel documented how the original software developer could mechanically translate an 8-bit program into a 16-bit program. Only the developer of the program with possession of the source code could make this translation. I designed DOS so the translated program would work the same as it had with CP/M – translation compatibility. The key to making this work was implementing the CP/M API."
I have a couple of friends who had that original Seattle Computer CPU board and the QDOS that came with it. I was very jealous. The sale to Microsoft came out of the clear blue.
Again, I don't think the author thought about it much. But at the time, CP/M wasn't a legacy system, and COM files were integral to both systems. Imagine if the sentence was something like, "Windows 1.0 used a mouse pointer, which existed to be backwards compatible with the Mac."
Sure, but an earlier system nonetheless. Similarly, I'd describe Windows 95 as backwards compatible with Windows 3, even if one might describe Windows 3.1 as a contemporary system at the time of 95's release.
The author is Raymond Chen, a developer on the Windows team who has been writing well-researched articles about backward compatibility in Windows and MS-DOS for the better part of two decades, so I think it's safe to say he's very well informed on the subject.
But I don't think he's "rewriting history" at all, intentionally or otherwise: QDOS/MS-DOS was originally designed to provide a largely CP/M-compatible runtime environment to ease porting, hence "backward compatibility" — "backward", not because MS-DOS was a "successor" or because CP/M was obsolete, but for the simple reason that this compatibility was both one-way and limited to features found in pre-existing versions of CP/M.
The story (which I'm sure many of you know) was that in 1979, Seattle Computer was selling an 8086 board, but CP/M didn't run on that CPU yet. So Tim Paterson solved the problem by whipping up QDOS to help sell more boards, cloning the architecture and APIs of CP/M directly from the manuals (without access to the actual source code).[2]
The simplest sort of executable code is a COM file (doesn't get much simpler, actually), so if you're copying the way an OS works, that's pretty much where you'll start. It was about being a familiar paradigm for programmers, not some sort of cross-platform binary compatibility to an out of date OS as insinuated by the term "backwards compatible".
1. https://en.m.wikipedia.org/wiki/COM_file
2. http://bitsavers.org/pdf/imsai/dos-a/05_CPM_Interface_Guide_...