Friday, August 17, 2007
Beyond this technical achievement is the success CP/M had in the marketplace. It stands alone as the catalyst that launched the microcomputer industry as a successful business. Without those signs of success, companies like IBM wouldn’t have been tempted to enter the business and fuel its growth.
The Significance of the BIOS Interface
The concept of a software interface between separate programs or program components has been around for a long, long time. The most obvious example is the Application Program Interface (API) that all operating systems provide to application programs.
But interfaces can exist at other levels, not just between the OS and applications. Interfaces are used whenever two components must interact, but the components are developed independently or may need to be changed independently.
Much has been made of the layers of interfaces used by CP/M. (John Wharton: “Gary’s most profound contribution”; Harold Evans: “truly revolutionary”, “a phenomenal advance”; Tom Rolander: “supreme accomplishment”, “originator of that layering of the software”.) The core of CP/M was the Basic Disk Operating System (BDOS). On one side of the BDOS was the API exposed to application programs; on the other side was the Basic Input/Output System (BIOS) that connected the BDOS to specific computer hardware.
Certainly the idea of these layers of interfaces was not new to the computer industry. For example, UNIX (like all operating systems) provided an API for application programs, and connected to the hardware with an interface to low-level device driver software. These are equivalent layers to the CP/M’s BDOS and BIOS, but much more sophisticated. So I am a bit mystified as to what is so revolutionary about CP/M’s design.
Of course, being the first microcomputer OS, CP/M was the first to put these layers on a microcomputer. So I guess in distilling down the essence of an OS so it would fit on a microcomputer, we can give Kildall credit for not distilling out too much and leaving out the interface layers. Except that he actually did, originally. As described in his memoirs, quoted by Evans, in early versions of CP/M he had to rewrite the parts that manage the hardware “so many times that the tips of my fingers were wearing thin, so I designed a general interface, which I called the BIOS.” I read somewhere that the BIOS interface was first added to version 1.3 of CP/M. It may well be that Kildall had not seen a device driver or BIOS-level interface before. But the advantages that became obvious to him had been just as visible to his predecessors.
I equipped my first computer, an IMSAI 8080, with the North Star floppy disk system. It came with North Star DOS, which was the first OS that I personally used. It, of course, had a low-level interface so it could be tailored to work with any hardware. This is where my experience with interface layers began. I had not seen CP/M at the time.
CP/M & the DOS Connection
I can think of no specific technical innovations demonstrated by CP/M. The new idea was simply that you could do it – you could actually put a general-purpose operating system on a microcomputer. It worked and the market loved it.
DOS was built on top of this general groundwork. Kildall distilled the OS to a minimal, useful set of capabilities that would fit on a microcomputer. This simplified my task in setting the functionality of DOS. It was a matter of adding or subtracting to an existing & working set rather than developing the list from scratch.
DOS has been accused of being a “rip-off” or “knockoff” of the CP/M “design” or “architecture”. I guess this may refer to the fact that DOS has the same interface layers. Or it may refer to the similar function set. In that sense, since Kildall picked an appropriate set of functions, any subsequent microcomputer OS would have the same ones and would be some sort of “knockoff”.
Wednesday, August 8, 2007
Paterson v. Evans lawsuit dismissed
In his book They Made America (Little, Brown & Co., 2004), author Harold Evans revives claims that DOS is based on the late Gary Kildall's CP/M, using words such as "slapdash clone" and "blatant copies". I sued the author & publisher for making false and defamatory statements.
The case was dismissed last week shortly before it was to go to trial. The main reason this happened is because the judge ruled that I am a “limited purpose public figure.” This sets a very high bar of protection for free speech, leading the judge to then rule that the book represented protected opinions.
Facts not in dispute
What may be most surprising about the issue is that there is no significant dispute on the actual relationship between DOS and CP/M. The relationship is simply this: DOS implements the same Application Program Interface (API) as CP/M. The API is how an application program (such as a word processor) asks the operating system to perform a task, such as to read or write a disk file.
There is no suggestion that I copied any CP/M code when I wrote DOS. (To this day, I have never seen any CP/M code.) And the internal workings of DOS are quite different. For example, unlike CP/M, DOS used the FAT (File Allocation Table) system for organizing disk files, which made it much faster but meant floppy disks were not interchangeable between CP/M and DOS.
One point of disagreement: In his memoirs (quoted by Evans), Kildall claims that I dissected CP/M to learn how it worked. This is not true, and it doesn’t even make sense. Since DOS worked so differently, there would have been nothing I could learn from CP/M’s internal workings to help in writing DOS.
What do I mean by “implement the same API”? Every operating system has basic functions like reading and writing disk files. The API defines the exact details of how to make it happen and what the results are. For example, to “open” a file in preparation for reading or writing, the application would pass the location of an 11-character file name and the function code 15 to CP/M through the “Call 5” mechanism. The very same sequence would also open a file in DOS, while, say, UNIX, did not use function code 15, 11-character file names, or “Call 5” to open a file.
Since CP/M and DOS both had the same API, you would think that a program for one would run on the other, right? Wrong. CP/M was only for 8-bit computers based on the 8080 or Z80 microprocessors. DOS was only for 16-bit computers based on the Intel 8086 microprocessor. At the time DOS was written, there was a vast library of 8-bit CP/M programs, none of which could run on 16-bit DOS computers.
While 8-bit programs could not run on 16-bit computers, 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.
So sue me
When you boil it all down, the thrust of Evans’ story is that Kildall and his company, Digital Research (DRI), should have sued for copyright infringement and DOS would be dead. CP/M would have then been chosen for the IBM PC (because it was the only choice left), and the history of the PC would be much different.
While DRI was free to sue for copyright infringement, the likely success of such action is still controversial at best. The question was whether the published API, used by all the applications that ran under CP/M, was protected from being implemented in another operating system. There are experts who say no, and there are experts who say maybe, but from what I can tell as of 2007 there is yet to be a successful finalized case.
I say that because Evans & I each brought our own copyright experts into our negotiations to settle the case. Mine was Lee Hollaar of the University of Utah, while Evans used Douglas Lichtman of the University of Chicago. Lichtman provided a handful of case citations to show “that the issues here are not clear in either direction, and, in a hypothetical copyright suit filed by Kildall, he might have won and he might have lost.” But the only case that seemed to support DRI’s side was a preliminary injunction in 2003 (Positive Software v. New Century Mortgage). We didn’t think it really applied, and as a preliminary injunction it hadn’t gone through a full trial, let alone appeal. I would suppose this is the best he had. Hollaar said to me “I feel that it's clear from the cases under similar circumstances that you would have won.” I have wished my suit against Evans could have really become a copyright suit about CP/M & DOS so this could be settled.
If tiny Seattle Computer Products had been sued by Digital Research back when DOS was new, I’m sure we would have caved instead of fighting it. I would have changed DOS so the API details were nothing like CP/M, and translation compatibility would have been lost. But in the end that would have made absolutely no difference. No one ever used or cared about translation compatibility. I had been wrong to think it was a valuable feature.
Lichtman mentioned to me that he was working for SCO in their lawsuits against Linux. If I understood him correctly, SCO was trying to establish that an API can be protected by copyright, so it could be used to collect royalties on Linux, whose API is the same as or similar to UNIX.