|
Exhibits from Comes v. Microsoft That Rebut Microsoft's Appeal Brief
This is an addendum to the article "Microsoft Files Brief in Novell's WordPerfect Antitrust Appeal" dated January 26, 2013. A helpful anonymous comment linked to some exhibits that mention APIs and why they matter so much. The exhibits are from another antitrust case against Microsoft that settled during trial, Comes v. Microsoft. The judge made the exhibits public. And some of them appear in the Novell v. Microsoft case. So if you are new to this story, you may find it useful to take a look. They contradict Microsoft's brief. For example, here's
Exhibit 1413 [PDF], which shows that as far back as 1992, Microsoft executives were aware that access to source code was their advantage, but that they should provide APIs to other companies, because it was an issue that was never going to go away otherwise:
From bradsi Thu Aug 27 08:40:39 1992
To: cameronm jonl mikemap paulma
Subject: undoc api's
Date: Thu Aug 27 08:40:38 1992
Status: RO
we can doc the api's we know the apps group (and other isv's) use. this is good practice. though it's not as straigihtforward as it appears, since some of the calls depend on context and an understanding of the source, which is explained in detail in mail i forwarded from david d'souza.
the biggest advantage our apps group has is access to the operating systems source. as long as this continues, the issue will never go away.
in fact, jimall has long been assuming that the aps group did not have source access. he has been telling isv's this, too. when i told him yesterday that this was not the case, he had that "oh shit" look on his face.
the apps group does not need access to the source. it's a matter that they have grown accustomed to it. the fact that other companies have been able to product world-class windows products (eg, Borland Quattro ro, Paradox, Lotus Ami Pro 3.0, Freelance, etc) is proof.
As to (a) doc the api's we know apps group is using, and (b) give the apps group the same access to source we give to other isvs. (ie, in certain limited circumstances.] if we don't do (b), the issue will never die.
That good advice was not followed, and in 1993, we see in
Exhibit 1614 that the reason, the real reason, they undocumented APIs while continuing to use them themselves, was because it gave Microsoft an advantage:
From:
Dennis Adler
To: bradsi; davidcol
Subject: FW: Undoc APIs document
Date: Monday, April 12, 1993 5:49PM
fyi....
___________________
From: Bill Miller
To: Dennis Adler
Subject: RE: Undoc APIs document
Date: April 12, 1993 12:52PM
thx for the input. Unfortunately, this is a doc that reflects
management's view on this entire subject. Jeffpr inherited the project.
I plan to kill it. Unless we (billg/mikemap) are willing to acknowledge
our "sloppiness", I don't believe that a piece like this
helps.
From Dennis Adler
To: Jeff Price
Cc: Bill Miller; David Cole
Subject: Undoc APIs document
Date: Wednesday, April 07, 1993 7:51PM
Short and sweet (or sour). I've read thru most of the materials you
sent along, and they are awful! You never address the issues Schulman
raised in his mail. You continue to say, "There was no advantage to MS
in using these APIs." Get real. You mean to tell me that the Word &
Excel teams put in a bunch of API calls that they did not think would
help them in a particular area? I hope not!
There is even one case (QCWin) where the "documented" use for the API
SetMessageQueue enables QCWin to wait until the app it is debugging has
a msg queue in place before sending it messages; this is clearly
advantageous. By ignoring the very valid points Schulman has raised,
you make a sham of the entire exercise of documentating the APIs now.
It comes across as a cover-up, plain and simple. In fact, you are
saying that Schulman is either confused or lying. That does not seem to
be the case to me.
I gave up reading the whole document, as this tone of denial continues
ad nauseum. Why not just document the APIs, preface the document with
some HONEST history (yes, we did use undoc'd APIs, yes we now have a
policy in place of not doing that -- a policy that was not in place
previously, and here is the documentation for these APIs that we have
utilized).
Stop trying to pretend that we did not do this to gain a competitive
advantage, however slight. If that is not why these programmers used
the undoc'd APIs in there code, then give me a plausible explaination
for why they did... truthful would be nice too.
The people who read this document are not stupid, and they would have
to be to believe what was written. I think this doc can do as much (or
more) harm as good as presently written.
/Dennis
In 1995, Novell, after bringing bugs to Microsoft's attention that Microsoft refused to fix, decided to offer customers patch disks to respond to problems they were experiencing in WordPerfect and PerfectOffice from the bugs, for a cost to Novell of $11,500. Here's
Exhibitt 2350:
NOVELL CONFIDENTIAL
Product and Price Change Notification
Attach a copy of the standard business and financial plans
[See PDF for form, dated 7/10/95, to which is attached the following:]
Patch Disk for WordPerfect and PerfectOffice
The Windows Product Marketing team, in conjunction with development, has decided to produce and distribute a "patch" disk for both PerfectOffice and WordPerfect 6.1 for Windows. To reiterate, the reason we have decided to produce a patch is to address two main concerns:
1) Win95 compatibility
2) High priority bugs
It should be noted that these bugs, for the most part, are not problems with our software (the Win95 bugs are problems we addressed with Microsoft which they refused to fix). In both cases, the patch will be limited to one diskette.
These patch disks provide updates to WordPerfect 6.1, Presentations 3.0, and the PerfectOffice 3.0 Desktop Application Director (in the PerfectFit directory). The patch disks address key complaints that technical services and large accounts are currently receiving, such as memory leaks, Support of DOS in a network environment (DuPont, 100,000 users), ODMA problems, temp files eating up hard disk space, problems with styles, DDE link problems, and printing problems with Presentations.
In addition some known problems with running PerfectOffice 3.0 on Windows 95 have been addressed such as prompting for network ID when opened, bad title bar display, Show Me problems with Coaches,and Grammatik GPF's.
The time line for completion of the patch disks are as follows;
6/27 - Gold master candidate released to testing -- testing conntinues throughout weekend
7/5 - First Article candidate released to MFG.
7/6 - Manufacturing to begin duplicating disks
The disks will be available for download off our Novell home page and over our electronic bulletin board services. The disk will also be available directly, via our 800 numbers. The disks are sent out free of charge.
| PerfectOffice and WPWin |
| Patch Disk |
Est. Units to be Shipped (first 6 months)
(Based on 50 calls/wk for 25 weeks) = 1,250
|
Costs: |
| Materials = $.68 |
| Telephone (ave. 2 mins/call): = $4.00 |
| Handling = $3.52 |
| Shipping = $1.00 |
| Total per unit = $9.20 |
| Total cost for this project: $11,500.00 |
As for Microsoft's contention that nobody ever complained about the APIs, that isn't what I see in Exhibit 2365:
From: Richard Jones
To: Internet:yves@microsoft.com
Date: 7/21/95 9:48am
Subject: A couple of issues
CONFIDENTIAL
Hi Yves,
I wanted to check that you received our Alpha II CD early last week. I checked with our Beta administrator and it was sent to John Ludwig.
I have one issue that was escalated to me by our messaging group concerning MAPI. Here is the message:
"My MAPI service providers that used to work in the M7 time frame (January beta) no longer seem to work. Can we get documentation on the changes that have been made to the SPIs (especially transport and address book) since M7.
Thanks,
Bruce Greenblaatt"
Bruce had sent this request almost a month ago to NOVSUP and has received no response. Could you help us out please?
If there are any issues you need resolved with us, please let us know.
BTW: any more news on us getting a beta copy of "Maple"?
Thanks.
Richard Jones
cc: Internet:johnlu@microsoft.com Ben Hendrick, Bruce ...
And in
Exhibit 2375, we see more complaints:
CONFIDENTIAL
From: Todd Millett
To: Internet: novsup@microsoft.com
Date: 8/2/95 4:10pm
Subject: Windows 95Password Provider Header
To whom it may concern:
Below is the text of 2 messages sent previously regarding header files and
libraries
for implementing a Windows 95 Password Provider. To date, we have had no
response,
but we still need this information. Can someone please respond with the
information
we need?
Thanks,
Todd Millett
Novell, Inc.
**********************
*******
We have the 950 DDK, and in the network.doc file, located on that CD, these
same
constants are mentioned, as are the API's we need to implement:
PPGetPasswordStatus
and PPChangePassword. There is a whole chapter (Chapter 6) on this subject,
which
contains the same information that was in the "Utilizing the Windows 95
Password
Control Panel" doc.
It is also well documented in the NETWORK.HLP file on the DDK CD.
In short, we have everything but the headers and libraries to actually implement
this
functionality. If these constants and API's have been removed, why are they so
well
documented? Also, if they have been removed, how do we integrated password
changes
with Windows 95?
Any help would be appreciated.
Thanks.
Todd Millett
Novell, Inc.
>>> yvesm 07/20/95
11:31pm >>>
Todd
I believe the constants PS_ONOFF, PWDCHANGE_MASTERPWD_NOTIFY have been
removed as well as the APIs you are referring about. The document
"Utilizing the
windows 95 password has not been updated yet.
Also you'll find the latest files in the 950 DDK that we sent to
Novell last week. However, I'll make sure you receive the updated version of
the
document on how to the windows 95 password.
Thanks
Yves Michali
CONFIDENTIAL
____________
From: Todd Millett [SMTP:TODD_MILLETT@novell.com]
Sent: Wednesday, July 19, 1995 9:56 AM
To: 'novsup@microsoft.com
Cc: Carla Heesch@novel1.com; WIN95@nove1l.com
Subject: Password Provider constants
We are trying to implement a Windows 95 password provider for our
Netware client. We have the document "Utilizing the Windows 95 Password
Control
Pane1", which documents the API's we need to support. However, we can't
find the
various constants which are referenced (such as PS_ONOFF,
PWDCHANGE_MASTERPWD_NOTIFY), nor the API's themselves, referenced in any header
file
we have. We have looked in
NETSFI.H and
NETMPR.H, but they are not there.
Could you please direct us to the proper header and library we should be using
for
these calls, or send them if they are not included in the standard SDK or
DDK?
Thanks,
NL2 0003819
NWA 000412
Todd Millet
Novell, Inc
CC: WIN95
CONFIDENTIAL
NL2 G0003820
NWA 000413
And for any, like the judge, who imagine that Novell had the option to just use what they had, notice Exhibit 2667, which is later in time, but is an email from 1997 from Novell to Microsoft stating that the API problems with Microsoft continued, and that Microsoft would use a required API but wouldn't document it, leaving Novell to try to guess how to fix the breakage, and note too that when they contacted Microsoft, they got no help, with is exactly what Mr. Gibb testified was the big change that occurred after Bill Gates decided to undocument the APIs in the litigation:
From: Rob Steele
To: Frank Nutt
Date: 3/10/97 5:21PM
Subject: Problems with Microsoft continue...
Frank,
I appreciate your help in getting the image of "Memphis" (Windows 97 ) code. We understand that selected sites have received "Nashville" (Internet Explorer 4.0) which was supposed to be in Windows 97. It is critical that we get this code as other developers have. We need to test our GroupWise WebSight integration and other programm interaction areas.
Also, the other issue we spoke of still looms heavily. It is the one where the new MAPI32.DLL that is deployed as part of Office 97 breaks GroupWise 5 operation. There are now "required" calls/properties that are not documented as such therefore we are at the mercy of the Developer support line. They have very limited assistance verbally and no written documentation on the changes. For for a product API standard, we should have ahve these changes spec'd out for us long before they ship it. These calls have been customized and tailored to Outlook and force us to do the same... which we would do if were knew the extent or specifics of the changes.
Also, our developers had to call the Word 97 Developer support for assistance with some integration problems only to find out (verbally) about two new registry entries that had been created and must be set for things to operate successfully. Again, no documentation on these calls.
Any contact with a MAPI or Windows Messaging member of management so that we could get this resolved would be appreciated... and as soon as possible as we have a "broken" solution out there as we speak.
Thanks.
Rob Steele
Product Line Manager
Novell GroupWare Division
steele@novell.com
CC: Ed McGarr, Eldon Greenwood, John Gailey, Paul Smaart, Stewart Nelson
And to rebut the Microsoft contention, accepted by the judge, that there was no plausible middleware threat, note this email, Exhibit 2369, regarding a 1995 meeting between Intel and Microsoft, where a Microsoft employee lists things to work on, and one is to get Intel to help them "to shut down folks that are trying to promote middle-ware":
From Marshall Brumer
Sent: Wednesday, July 26, 1995 5 07 PM
To: bens, bfox, bradsi, carls, shnsjo, dbayer, jallard, johnlu, marshalb, paulma, paulo
Subject: Intel/MS Internet/OLS Meeting
Intel attendees
Steve McGeady - VP Internet Group (Internet Technology Lab - IAL)
Mike Maez - VP Internet Group (Internetwork Product Division - IPG)
Ron Whittier
Frank Gill
Dave Landsman
Russ Barck
Rob Sullivan
Frank Ehng
MS Attendees PaulMa, BradSi, JohnLu, CarlS, ChrisJ, JAllard, PaulO, BenS, DBayer, BFox, MarshalB
SUMMARY
Intel and MS both presented their internet strategies. Key areas to work together on are Web Server, Client side and security/realtime services
DETAILS
Intel Group started in May 95. Presentation give by McGeady Intel sees most of the Internet being controlled outside the MS/Intel platform. This is the growth area they are going for.
Their key objectives 1) get fatter pipes 2) get telecom/ISP companies to deploy higher speed access into PCs in homes/businesses 3) build value-add corp/small bus Internet Web Servers 4) get ISVs to deploy apps that use more mips 5) encourage the dev of open, interoperable Internet standards for security and real-time media.
They have benchmaark data around UPH (URLS/Hour) that shows NT not doing very well at all. We should be comparing numbers and working together. JAllard should work with Steve/Mike to resolve these issues.
ChrrisJo presented MS strategy. JAllard and DBayer with backup on NT and MSN
Discussion
- Security issues
- We are doing some work here already and they are tied into this
- Need many certificate issuing scenarios
- We take a raincheck on this and will addrss it later - PaulMa is driving this within MS and for Intel
- Contact somewhere in the JimAll team
- Web Server
- Real Time Media
- This has gone on in our iTV work, not our Internet work
- After our re-org, this is in systems - how do we re-vector this for mid-band internet/cable modems
- NT Internet servers
- Already agreed to exchange benchmarking code for sync up on numbers
- Work with JAllard to resolve any issues here
- They corp servers are not currently NT servers
- Client SW
- They don't have an agenda to drive different interfaces here
- They will track things like HotJava pretty closely (as are we for adoption or fit to architecture if needed)
- They are starting to benchmark this on Sun and NT systems
- MSN
- They want to watch this - remotely located, privately managed parts of MSN
- Business side
- Opportunity to develop the market for small business
- NT based web servers for this - how close to an appliance can this become
- Can we work together to create these capabilities in an applicance form
- We need to figure out who in BSD should meet with Mike Maertz on this - PaulMa owns
-WebServer+BackOffice as a small business solution
- Make sure we don't end up promulgating standards in competition with Intel
- Meet in next 6-8 weeks between our security/protocol (Allchin and Rashid) folks and McGeaady
- We want Intel to understand what we are doing on the client and help us with it
- Help us to shut down folks that are trying to promote middle-ware
- We both need to understand how to make this happen
- Paul to synthesize this at the Aug2 exec meeting
- We need to give much more detail here for them to understand this
- End Aug early Sept for follow on meeting
- Ron's 3 pronged deal of where MS/Intel should work together
- Client
- Web Server
- Security and Real Time protocols
Paul also noted that there are very few people using the Internet today vs.how many will be using it in the future that we want to influence
ACTION ITEMS
- Follow up on benchmark numbers on Windows NT - JAllard
- Plenty of follow-up needed from the discussion section
Last Updated Monday, January 28 2013 @ 03:44 AM EST
|
