In case it wasn’t sufficiently obvious already: A forensic expert now confirmed that 86-DOS, née QDOS, and (by extension) MS-DOS were not copies of CP/M, either on source or binary level. This comes hardly as a surprise, despite years (nay, decades) of vague accusations against Tim Paterson and Microsoft.
Proving that 86-DOS was a copy of CP/M was always going to be very much an uphill battle based on what was known of the operating systems. 86-DOS ran on 16-bit 8086 systems, while CP/M at the time was 8-bit only (8080, Z-80); in fact the unavailability of CP/M on the 8086 was the sole reason why 86-DOS was written in the first place.
While 86-DOS was compatible with the CP/M API, it used a completely different disk management strategy (based on the FAT idea of Microsoft’s Marc McDonald) and DOS-formatted disks were never compatible with CP/M. In addition, 86-DOS supported the 8086 segmented architecture and accepted 16:16 far pointers for input/output buffers passed to DOS (because the segment address was passed in DS, small model programs, including those converted from CP/M, could ignore this feature). There was no equivalent in 8-bit CP/M.
The DOS utilities were never particularly similar to CP/M beyond the basics—for instance COPY instead of PIP, DEBUG instead of DDT, EDLIN instead of ED. On the user interface level, there was simply no effort to make 86-DOS an exact clone of CP/M.
Then there’s the question of source code. While early CP/M was partially written in Gary Kildall’s PL/M, 86-DOS (and MS-DOS) was written in 8086 assembly. It would be possible to rewrite the PL/M source code in assembly, but that would be very inefficient. It would be especially problematic without a PL/M to 8086 translator (which presumably didn’t exist when 86-DOS was created), but if that were available, why not just use PL/M?
The infamous Jerry Pournelle story (about a hidden command in MS-DOS proving that it was a CP/M copy) has serious problems, too. There is simply no proof that there is or was a hidden command in DOS that would show anything related to Digital Research or Gary Kildall. It was perhaps a prank, of which Jerry Pournelle may have been the subject rather than the initiator. If it were true, surely someone would have found the hidden code by now; old versions of DOS were not that large.
It is also difficult to believe that IBM would not have done due diligence and ensured that Microsoft truly was the owner of the DOS copyright.
There is no question that 86-DOS took many ideas from CP/M… just like CP/M took many ideas from operating systems that preceded it. There is nothing illegal or wrong about that. On the other hand, there is zero evidence that 86-DOS (or MS-DOS) infringed on Digital Research’s copyright in any way. In the early 1980s, there were several cases where companies successfully sued copyright-violating cloners (Apple v. Franklin, IBM versus Corona, and others). If Digital Research actually had a case, surely they would have brought it to court—there was a lot of money at stake.
As an aside, in the late 1990s, after the CP/M ownership passed first to Novell and then to Caldera, the latter successfully sued Microsoft (settled for $280m). However, the subject of the lawsuit had nothing to do with CP/M but rather Microsoft’s monopolistic practices designed to exclude DR-DOS/Novell DOS/Caldera DOS from the market in the late 1980s and early 1990s.
It may be useful to briefly go over the similarities between CP/M (as it existed around 1980) and 86-DOS. The following comparision is based on the CP/M 2.2 source code, CP/M documentation, 86-DOS source code (partial) and binaries, and 86-DOS documentation.
Similarities between CP/M 2.2 and 86-DOS 1.0
The overall structure of both systems was undeniably similar: monitor (“firmware”), boot loader, I/O section (“BIOS”), BDOS (Basic Disk Operating System), and command processor (COMMAND.COM or CCP).
The structure of bootable disks was similar, with boot sector, I/O subsystem, BDOS and command processor at the beginning of the disk, followed by the data area.
The programming interface of 86-DOS was expressly designed to be compatible with CP/M, so as to allow mechanical translation of well-behaved programs. Therefore, it is unsurprising that it was very similar – console I/O, FCB-based file I/O, etc. Most system calls in 86-DOS were designed to mimic CP/M.
File names used an 8.3 format, with ? and * used as wildcards when specifying file names. Drives were designated by letters. There were several very similar commands built into the command processor: DIR, ERASE, REN, TYPE.
Differences between CP/M 2.2 and 86-DOS 1.0
The list of differences is quite long; it starts with the different CPU architecture, 8080/Z-80 for CP/M and 8086 for 86-DOS. As 86-DOS predated CP/M-86, there can be no suggestion that it might have been based on 8086-specific CP/M in one way or another.
The disk format was very different and completely incompatible, even though the user-observable behavior was roughly the same. One notable difference was that 86-DOS had no concept of user numbers.
The list of internal command processor commands was different: DIR, ERA, TYPE, SAVE, REN, and USER in CP/M 2.2, versus DIR, RENAME, ERASE, TYPE, CLEAR, COPY, and PAUSE in 86-DOS 1.0. Even the name of the command processor was different (COMMAND vs. CCP), although that had relatively little significance.
The internal COPY command in 86-DOS was different from the external PIP in CP/M. Notably the list of special devices (PRN, AUX, CON) was built into PIP in CP/M and into BDOS in 86-DOS. This was both a good thing and a bad thing.
The system API was very similar, but also significantly different. The preferred invocation mechanism in 86-DOS was INT 21h, versus CALL 5 in CP/M (supported but marked as obsolete in 86-DOS). Segmented memory was supported, a concept which didn’t exist in CP/M 2.2. Several CP/M functions were not supported in 86-DOS (e.g. function numbers 12, 24, 32), while others were different (e.g. 37 – set vector, or 38 – create new program segment).
The 86-DOS buffered input routine (function 10) supported editing based on a ‘template’ which held previous input. Such functionality did not exist in CP/M at the time. CP/M 2.2 also does not appear to have had an equivalent of the Ctrl-C and critical error handlers (INT 23h and INT 24h) in 86-DOS.
The 86-DOS FCB format was very similar to that of CP/M, but not identical. 86-DOS allowed larger files to be addressed and the FCB fields reserved for system use were likely quite incompatible (due to the different disk format).
Examining (disassembling) the actual BDOS module in 86-DOS, it is difficult to believe that it might be a copy of CP/M. For example, it uses many string instructions which had no equivalent in the 8080. Similarly the LOOP instruction is frequently used in 86-DOS—a very strong indicator that the code was written for the 8086, not copied from anything developed for the 8080.
Last but not least, the interface between the I/O subsystem and BDOS was substantially different. That’s exactly the part that one would expect to be the same if 86-DOS were a copy of CP/M. The BIOS/BDOS interface in CP/M 2.2 was lower level, with routines to set track, select sector, or seek to track zero. With 86-DOS, the BIOS simply provided an interface to read and write sectors; the BIOS took care of positioning the read/write head.
Conclusion
The relationship between CP/M and 86-DOS is not unlike that between UNIX and Linux (and before Linux, Coherent by the Mark Williams Company). Linux is a UNIX workalike, designed to be very similar but developed entirely independently. If anything, 86-DOS was less similar to CP/M than Linux was to UNIX.
Another case in point might be clones of the IBM BIOS developed by Compaq or Phoenix. These mimicked the original far more than 86-DOS ever tied to copy CP/M, yet they were entirely legal.
There is no question that CP/M was a tremendously important operating system. If it weren’t for the immense success of the IBM PC which catapulted DOS onto millions of machines, CP/M would likely have prevailed. But that doesn’t mean 86-DOS or MS-DOS were “stolen”.
I’m curious as to if a binary of the 86-DOS (pre-MS-DOS) BDOS can be isolated somehow from what resources exist, and if it could be coaxed onto a PC using the bootloader and IBMBIO.COM from PC DOS 1.0 (a trick I have used effectively for several versions of MS-DOS).
I think PC DOS 1.0 is too new/different. That said, I believe that enough source code and documentation is out there that it would be possible to port the 86-DOS “monitor” to the IBM PC.
Pingback: PC DOS 1.0, But Not Quite | OS/2 Museum
Archived copy to the “A forensic expert now confirmed” link:
https://web.archive.org/web/20120811221413/http://spectrum.ieee.org/computing/software/did-bill-gates-steal-the-heart-of-dos/0
The article was written before the DOS source code was released. Comparing the source code would likely have even better demonstrated that no code copying took place.
I believe DRI’s argument was essentially that copying CP/M interfaces constituted theft. Existing case law very much disagrees, and that is not new (see e.g. BIOS cloning in the early 1980s). DRI missed the 8086/PC boat that was not Microsoft’s fault. It just goes to show that being in the right place at the right time counts for more than anything else.
Actually, there is a follow up: https://www.researchgate.net/publication/309274064_Source_Code_Comparison_of_DOS_and_CPM
It comes to much the same conclusion: No copying of source code. The CP/M system call interface was clearly copied, but whether that constituted a copyright infringement was at best a toss up and had DRI sued Microsoft, there’s a good chance they would have lost in court.