LA Law
On Wednesday, February 23, 1994, a federal jury in Los Angeles delivered its verdict in the case of Stac Electronics vs. Microsoft Corporation. Stac had sued Microsoft, charging that DoubleSpace in MS-DOS 6 infringed on Stac's LZS data-compression patent. Microsoft countersued, charging among other things that, by reverse-engineering the undocumented "preload" interface in DOS 6 and using it in Stacker 3.1, Stac had misappropriated Microsoft's "trade secrets." The trial began on January 18, just after the devastating Los Angeles earthquake, and, as a paid consultant and potential expert witness for Stac, I had a front-row seat at the proceedings.
The jury's verdict was, in its own way, a small earthquake. The jury awarded Stac $120 million in damages for patent infringement by Microsoft; this is $10 million more than Stac asked for. In turn, the jury also awarded Microsoft $13.6 million in damages for trade-secrets misappropriation by Stac. Microsoft lost both its own patent-infringement claim against Stac (Microsoft had bought a data-compression patent which predated Stac's) and a "breach of contract" claim.
In sum, Microsoft lost every part of this case except its trade-secrets misappropriation claim.
While the large patent-infringement award to Stac seems like the big news, the smaller trade-secret award to Microsoft is at least as interesting, because of its direct connection to reverse engineering and the use of undocumented interfaces in the PC software industry. Even a brief article in the New York Times (February 24) picked up on the fact that the trade-secret claim "centered on Stac's use of what is known as an undocumented call in MS-DOS."
By making Stacker 3.1's use of the undocumented preload interface out to be "trade-secrets misappropriation," Microsoft put reverse engineering and the use of undocumented interfaces on trial. And the eight-person LA jury agreed with Microsoft that Stac's use of Nu-Mega's Soft-ICE debugger to reverse-engineer the undocumented preload interface, and Stacker 3.1's use of the preload interface when running under MS-DOS 6, constituted trade-secrets misappropriation.
The jury's decision seems odd because Stac's reverse-engineering of the undocumented preload interface, for use in Stacker 3.1 under MS-DOS 6, is no different from dozens of previous uses of undocumented interfaces. Microsoft has never before claimed that undocumented interfaces were "trade secrets."
The list of utilities that employ undocumented DOS or Windows interfaces is quite long. A few examples include the Norton Utilities, Central Point PC Tools, 386MAX, QEMM/386, DesqView, NetWare, and Sidekick. Microsoft has never claimed that any of these products were misappropriating trade secrets. In fact, Stack itself used other undocumented DOS calls in Stacker 1, 2, and 3.
This is the first time that calling an undocumented function has been viewed as stealing a trade secret. Either Microsoft has decided to call into question the entire past history of the PC software industry, or it somehow views Stac's use of the undocumented preload interface as different from all previous uses of undocumented calls.
The preload interface is what IO.SYS in MS-DOS 6.0 and higher uses to load a block device driver named DBLSPACE.BIN early in the DOS boot sequence, before processing CONFIG.SYS. A description of all the preload calls is given in Geoff Chappell's DOS Internals (Addison-Wesley, 1994). A partial description of the preload is given in Undocumented DOS, second edition (Addison-Wesley, 1993).
Frankly, the preload interface is no big deal. As Chappell puts it, the preload "has the appearance of a hack." Figure 1 shows a pseudocode summary of this $13.6 million interface, as seen from IO.SYS's perspective. According to Microsoft, this interface is a valuable "trade secret" that took one man-year to develop. To be preloaded, a driver must respond to these calls. What Stac did was figure out this interface, and modify Stacker to respond appropriately so that it would be preloaded under DOS 6.
It is difficult to see what makes this interface a valuable trade secret. With the publication of Chappell's book, and to a certain extent with the earlier publication of the second edition of Undocumented DOS, it's no longer a secret. In any case, it seems no different from any other undocumented DOS interfaces, such as the network redirector, the List of Lists, the Swappable Data Area, the once-undocumented interfaces used by TSRs, or the COMMAND.COM installable command interface, all of which applications have been using for years.
Consider Microsoft's response to my article, "Examining the Windows AARD Detection Code" (DDJ, September 1993). This article was explicitly based on reverse-engineering an encrypted piece of code in WIN.COM that attempts to detect if the user is running Windows on a non-Microsoft version of DOS. The AARD code could only achieve its purpose if other vendors didn't know what the code was testing for. If any piece of commercially available code were a "trade secret," it would have to be this. Yet, in Microsoft vice president Brad Silverberg's response ("Letters," DDJ, January 1994), not once did he claim that this code was a trade secret, or that I shouldn't have reverse-engineered it. Why the preload interface is a trade secret, while the AARD code--which actually requires secrecy to serve its purpose--is not, is a mystery.
Another example of how Microsoft's case against Stac represents a 180-degree turn from previously held positions is the "Microsoft Statement on the Subject of Undocumented APIs," issued on August 31, 1992 in response to a controversy in the press over the book Undocumented Windows. A Q&A section in Microsoft's statement included the question, "Why are there undocumented APIs?" The answer provided half a dozen reasons, but the explanation that undocumented APIs are trade secrets was nowhere among them. To the question, "How do ISVs uncover undocumented APIs?," Microsoft answered that "Finding these APIs is quite simple using the many debuggers available in the market." That, naturally, is what Stac tried to point out during the trial.
So what explains the jury's verdict? Remember that Microsoft didn't win its "breach of contract" claim, so the standard "You may not reverse engineer, decompile, or disassemble the software" boilerplate in Microsoft's beta agreements and shrink-wrap licenses was not an issue. These attempted limitations on reverse engineering have not been found enforceable, and the Stac verdict does not seem to change this.
Instead, the jury seems to have been convinced that Stac "copied the design" of the preload, a phrase repeatedly used by Microsoft. Perhaps the jury, in awarding damages to both Stac and Microsoft, felt that there was some parallel between Microsoft's patent infringement and Stac's reverse engineering.
The "copied the design" phrase is interesting, since Microsoft made no copyright infringement claim against Stac. Microsoft's expert witness said that Stac didn't copy the "literal program code itself." But, he said, "they copied the design part." This refers to nothing more than the fact that Stacker 3.1 can be preloaded under MS-DOS 6, just like DoubleSpace.
This nebulous "copied the design" slogan obscured the point that Stac merely figured out how to be compatible with an interface in MS-DOS 6. Stac didn't release a competing DOS, but a product that used an undocumented feature in DOS. Stac didn't copy the feature or design in their product; they interfaced with it. This distinction between copying and interfacing is clear to any programmer who has ever figured out an API and called it. However, the jury decided that using the BOOT command in Soft-ICE to reverse engineer an undocumented interface, and then using this interface, is equivalent to copying a design.
Stac never saw Microsoft's source code; it learned everything it needed using Soft-ICE on the binary MS-DOS code, but the jury may have thought that Stac had taken MS's source code, viewing this as parallel to MS's infringement of Stac's patent. An important part of Microsoft's case was a persistent use of the term "source code" to describe disassembled listings. Microsoft made frequent, irrelevant reference to how it "protects the underlying source code as a trade secret."
Since Stac had never seen or taken Microsoft's actual source code, Microsoft had to make it seem as if disassembly could produce an equivalent to the original source code. Thus, referring to Stac's reverse engineering, Microsoft's expert witness said that Stac "spent a great deal of time effectively putting the comments back into the disassembled code." This reflects a basic misunderstanding of what reverse engineering can and can't do. It can't "put back" the original source-code comments, variable names, or function names. A developer can, of course, come up with new comments and names. But he cannot "put back" anything that has been removed during compilation or assembly. Reverse engineering cannot turn a binary product back into the original source code for the same reason that you can't turn a McDonald's hamburger back into a cow. Yet, this "put back" phrase, and the image of source-code copying it suggested, may have carried some weight with the jury.
If reverse engineering and calling an undocumented interface now constitute "copying a design," it is not clear how developers are supposed to develop their products when sufficient documentation is absent. Microsoft's expert witness (whose most recent publication dates from 1974) merely recommended what may have been appropriate in the period predating the PC mass-market software industry: You must ask the vendor (whom, perhaps, you know on a first-name basis) for additional information.
In deposition testimony quoted during the trial, Microsoft's expert was asked, "Do you know what general industry practices are in circumstances in which there isn't enough information about the operating system available from the operating-system vendor?" His answer was simply "No." During trial, Microsoft's attorneys suggested that "when you wanted information, you called the person who owned the product."
Thus, Microsoft's position is to turn back the clock: Trust the vendor. No means of independent discovery are required, since the operating-systems vendor will supply all you need. Anything the vendor doesn't supply, by definition you don't need.
Microsoft chairman Bill Gates testified on January 28. At one point, Gates was asked by a Stac attorney if good examples of reverse engineering would include buying a toy and figuring out how it was made, chemically analyzing a cookie to determine its ingredients, or General Motors buying a Japanese car and taking it apart. Gates agreed these were all good examples of reverse engineering, but "I know in our industry that type of reverse engineering is prevented."
This was the position that Microsoft put before the jury: that reverse engineering, and the use of undocumented calls, is uncommon (indeed, "prevented") in the PC software industry. This, Micorosoft knows, is simply not true.
It is possible that the verdict will have little effect. After all, Microsoft claims that Stac's reverse engineering of preload is somehow "totally different" from any previous reverse engineering that has gone on in the PC software industry. This is absurd, but for those developers who have used an undocumented interface, it is convenient. Probably the safest way to avoid a trade-secrets misappropriation claim from Microsoft is to not sue Microsoft for patent infringement. Consider, too, that because of the Justice Department investigation of Microsoft, the company may not have as free a hand as it would like in taking this verdict as a precedent for further action against DOS-utilities vendors.
Both Stac and Microsoft immediately asked the judge to set aside the jury's decision, and both companies will surely appeal. The final chapter has yet to be written in this case.
Still, the Stac verdict does seem to establish the right for a company such as Microsoft to declare, out of the blue, that one of its undocumented interfaces is suddenly a trade secret. In cross-examination of MS-DOS product manager Brad Chase, a Stac attorney asked how Microsoft decides whether it's okay to reverse engineer the preload. Chase's answer: "There's no set rules. It's done on a case-by-case basis." Taken seriously, this no-rules rule could turn undocumented interfaces into an unpredictable legal minefield.
Copyright © 1994, Dr. Dobb's JournalWhy is This Interface Different from
Copying the Design?
Trust Us
A Chilling Effect?
Figure 1: The $13.6 million interface: The DOS 6.0 preload.
use 21/4B03 (Load Overlay) to load file named \DBLSPACE.BIN
check that offset 12h in file == 2E2Ch // signature ",."
fp = offset 14h in file // function pointer to driver
(*fp)(ax = 6, es:bx = DD init packet) // modified device driver init
size = (*fp)(bx = 4) // query size
(*fp)(bx = 6, es = new location for driver) // relocate
(*fp)(bx = 2, ah = 55h, al = number of drives) // mount drives
(*fp)(bx = 0) // preload done: driver should hook INT 2Fh, etc.
for each device= line in CONFIG.SYS
if it's a block device driver
call 2F/4A11 bx = 0 // documented GetDriverInfo
(*fp)(bx = 2, ah = 55h, al = number of drives)
DBLSPACE.SYS /MOVE:
2F/4A11 bx = -1 to get driver size
2F/4A11 bx = -2 to move driver