About ten days ago, a federal jury in L.A. returned a verdict against STAC on 
a trade-secret claim by Microsoft.  The jury even awarded punitive damages because it 
considered STAC's actions deliberate.  Since then, STAC's president, Gary Clow, and others 
have devoted an enormous amount of energy on these forums trying to foster the belief that 
Microsoft will use this verdict to pursue claims against third-party developers who 
legitimately use debugging tools to achieve or maintain compatibility with Microsoft's 
operating systems.    

	These statements just aren't true.  Nor are STAC's claims that all they did was use a few  
undocumented calls.  STAC disassembled and analyzed a sizable chunk of MS-DOS itself to understand  
its internal design.  Then STAC used that knowledge to write code identical in functionality for 
STAC's own product.  The preloading program copied by STAC is one that integrates data compression  
seamlessly into the internal operations of MS-DOS to allow data compression to be performed in a 
safe, easy, and efficient manner.  This had nothing to do with undocumented system calls.  
(STAC did intercept a few internal calls but this was the least significant part of our design and 
not the reason we sued them.)    

	Information obtained during the discovery phase of the case, through diaries and testimony 
of STAC developers, and confirmed during the trial, shows that STAC did not merely analyze the  
compression integration portion of MS-DOS 6 but disassembled and copied the design, functionality,  
features, and processes of more than 3,000 lines of MS-DOS compression integration code.  (By  
comparison, the compression technology of DoubleSpace, which STAC sued Microsoft over, involved  
only about 1,500 lines of code.)  

	At the trial, STAC produced a number of expert witnesses who testified that they regularly  
"reverse-engineered" other programs, and STAC is using that as "proof" that other developers are 
on his side.  In fact, during cross-examination, every one of STAC's witnesses said they defined 
"reverse-engineering" to mean analysis for debugging or compatibility testing and not for 
disassembling and copying someone else's work.  STAC's final expert witness, Jim Sesma, a 
developer not affiliated with STAC, was specifically asked whether he had ever reverse-engineered 
or disassembled one of Microsoft's products in order to copy the internal design into another 
product.  His answer: "No, I have not.  That is not the intention of anything that I would do."  

	Our outside expert witness testified that STAC could not have done what it did with a 
simple debugger or usual debugging techniques, and that what STAC did went far beyond what 
anyone in the industry would consider necessary for compatibility.  In fact, STAC's existing 
product was already compatible with MS-DOS 6, and evidence was presented at trial showing that 
STAC had other technical avenues for preloading that would not require STAC to disassemble and 
copy Microsoft's designs.   For example, IIT's XtraDrive product replaces the boot sector with 
its own code that loads their driver into memory before loading IO.SYS, so they get a preload 
effect without having to use Microsoft's technology.  Digital Research took still another 
technical approach to integrating disk compression in DR DOS 6. STAC did not need our trade 
secrets to solve its technical problems; taking our intellectual property was merely the most 
expedient way to do so.  

	Andrew Schulman and one or two other authors have claimed in various public forums that  
Microsoft's compression integration design is not a trade secret because it has been documented 
in at least two books, including Schulman's own Undocumented DOS.  Schulman's book, however, 
documents less than 2 percent of the compression integration design.  This provides some 
understanding of the relative amount of weight in the integration design between the overall 
feature set of the program and the few internal operating system calls used.  Schulman and other 
authors substantially understate the daunting challenge of uncovering and documenting the 
complete, detailed technical design that would be necessary to replicate an entire subsystem 
within the operating system, which is what STAC did.  For example, Schulman has not been able to 
document how MS-DOS 5 (released three years ago) loads itself into high memory, and that task is 
far simpler than the compression integration of DoubleSpace.  STAC was able to copy Microsoft's 
work only after a heavy investment in developer time (documented in their own diaries) and has 
been found guilty of violating Microsoft trade secrets in doing so.    

	Note: My comments here are not pointed at Andrew.  What he has done in his research, and 
what he has published in his books and articles, is radically different than what STAC has done.
    
	Microsoft's system business is predicated on getting a large number of third parties, 
both big and small, to develop products for our operating systems. Through our developer 
relations efforts, we continue to provide technical information to outside vendors and to 
encourage support third parties to write products for our systems. In addition, from time to 
time, we will likely seek to license third-party software technology to incorporate into our 
operating system and application products.  (For MS-DOS 5 and 6, we licensed technology from 
Central Point, Roundup, Helix, Vertisoft, and Quest/Norton.)    

	Microsoft has no interest or intent in pursuing developers doing legitimate technical 
work to build products to run on MS-DOS or Windows.  It is one thing to use software tools to 
analyze an operating system to ensure that applications are compatible with it, or to fix bugs 
in your product that show up in low-level interactions in the operating system, or to work around 
bugs in the operating system itself.  It is another thing entirely to disassemble the operating 
system, copy the design of key features, and incorporate them into your own product.  Microsoft 
is not confused about the difference.  The developer community should not be confused.  Microsoft 
will work hard to encourage honest developers to build products for our systems, but we will 
absolutely take steps to protect our trade secrets from unscrupulous developers who try to rip 
off our work.  

Paul Maritz,  
Senior Vice President, Systems  
Microsoft Corporation