It's Comes Plaintiff's Exhibit 1614 [PDF], an email thread begun by Dennis Adler to Jeff Price, with ccs to Bill Miller and David Cole, at Microsoft, and the subject line is "Undoc APIs document". The thread goes from April 7 to April 12, 1993.

The topic is undocumented APIs, obviously. In the email, Adler speaks about Microsoft using undocumented APIs for a competitive advantage, and he makes it sound like typical M.O. at the company. He suggests the company shift course, but his email is responded to by Miller, telling him that Adler isn't in sync with management's view on the subject. By June, he seems to have gotten in step, because Novell attached another email of his [PDF] as an exhibit to their response. In the April email, though, Adler describes a pattern of conduct, by my reading:

*****************************************

Erik Stevenson

_________________________

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 ar 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

From: Brad Silverberg [brads]
Sent: Friday, August 11, 1995 2:08 PM
To: Brad Struss, Paul Maritz
Cc: Cameron Myhrvold, Doug Henrich
Subject: RE. Shell extensibility and ISVs

- athena is part of windows. don't know what you mean about athena as "a product to be sold in the near future". athena is just part of windows and windows can and will use the shell extensions.

- the decision to not expose the shell extension api's was based on a set of considerations which are no longer operable. the win95 shell will be on winnt and the shell extensions will run fine ther -- there is no issue about supporting on nt.

- the win95 team did "make darn sure NT is kept in mind" from the beginning for the shell, which is why it ported so easily. we have the x-platform responsibility and we deliver on it. we have one shell team -- the psd shell team, which dropped off the code to bsd to do the nt adaptation. they are not to be "enhancing it". just a straight adaptation (unicode, tweaks for portability, etc): thdecision to not expose the shell extension api's eir changes will be merged back into the code base.

__________
From: Brad Struss
To: bradsi; paulma
Cc: cameronm; doughe
Subject: FW. Shell extensibility and ISVs
Date: Thursday, August 10, 1995 4:18PM

Last fall Bill made the decision not to expose the ability to extend the Explorer. In looking at thee prerelease Athena PIM, it now appears that full Explorer integration is supported in both Windows NT and Windows 95. This obviously has ISV impact and we are potentially exposed here from a PR and trust perspective.

To recap the history, it was decided last fall that the Explorer extensibility mechanism that had been documented in early beta would not be supported moving forward. This decision was based upon the difficulty the Windows NT team would have in supporting these interfaces and on the need for MS to figure out our general extensibility strategy. Since the MSN team was dependent upon using these interfaces, a compromise solution was agreed to that allowed a modified version of the interfaces to support MSN to come up in a separate explorer window (vs the old way of actually being listed in the left hand pane of the Explorer window along network neighborhood, etc.) These interfaces were not planned to be supported beyond the initial release of Win95 and would be doc'd as b-list appis to be given out on special request so that other ISVs could develop an app similar to the MSN client if they so desired. As a result of this change, we proactively notified ISVs (Stac, Symantec, Netsoft, Oracle, etc.) who were actively developing using these interfaces and told them that: (1) the functionality of running in an integrated window was gone and (2) they were strongly discouraged from using the modified apis aat all because of compatibility risks. This caused significant changes in a many of their development plans, but they understood and pushed forward. The prerelease Athena PIM now displays capabilities contrary to what we have been telling our ISVs.

Can you please advise on our strategy for these interfaces moving forward?

Brad

______________________

From Scott Henson
To: Cameron Myhrvold; Doug Hennich
Cc: Brad Struss, Jerry Drain, Tammy Steele
Subject: Shell extedecision to not expose the shell extension api's nsibility and ISVs
Date: 08 August 1995 10:54PM
Priority: High

This mail is intended to summarize what I am seeing internally on this subject and to voice a STRONG concern for our ISVs!

The problem is that approximately a year ago we told ISVs that a set of interfaces (known as namespace extensions) were no longer going to be a part of the standard Win32 API set -- they were moved to an unsupported status or "b-list". The rationale at the time was that the interfaces were difficult to support especially on NT. The specific reason is that when an ISV implements a namespace extension they live in the process space of the operating system. Thus, if an ISV writes their namespace extension poorly they can bring down the entire shell. This is still the case today. Another reasonn was that the Ren team (Office 96 PIM) was going to hold the key for all future shell innovation (thus the split of the Cairo shell team). Given this, we went and told the ISVs that there was a lot that they could do in the system with respect to extensibility BUT they COULD not integrate into the explorer (like the control panel and briefcase) as we had previously mentioned was possible.

So for the last year we have been distributing "b-list" documentation to ISVs that were interested in the interfaces but always told them that this was not a desirable thing to do because these interfaces would most likely disappear in the future and there would be an equivalent way to do this in the future when the problems were solved. In the meantime there has been interest throughout the company in extending the shell in the way that the control panel and briefcase do.

So the PSD shell team has given them the docs and told them that we have distributed this ISVs and that they are writing to these extensions and they would most likely become part of the standard Win32 API set. For the most part this is fine from my perspective because MSN already has buyoff from the NT team to implement what they are currently using on Windows 95 which is to instantiate themselves into a separate instance of the Explorer. From a robustness perspective this is fine because if the app is bad, then they just bring down that instance of the explorer.

HOWEVER

This is not the limit of what is going on internally. As I mentioned there is a lot of internal development going on where various groups are implementing these interfaces to varying degrees. Again I don't mind if these various groups are doing this development work as long as it is in the way that MSN is doing it (coming up with their own view, separate from the system). We can then move the interfaces back to the standard Win32 set and with a little ISV re-education on our part all is well. Today my perception changed drastically. I have just installed Athena (the lightweight PIM from the PSD group) onto my system and to my dismay they are not only using the namespace extensions but they are also displaying themselves in the scope (left) pane and view (right) pane. This is the EXACT thing we told ISVs they could (and should) not do!

In short we have a product that will be sold in the very near future that will implement interfaces that we told ISVs they should not use because we would not be able to support them moving forward. In the meantime we were developing a product that did exactly that. I can't even express how BAD this is! We loose everything when we do this! Credibility, trust, leverage, the works! What's strange about all odecision to not expose the shell extension api's f this is that it looks like this product works fine on NT as well.

SO WHAT NEEDS TO BE DONE?

Assuming that we are going to support these APIs as a part of the standard Win32 API set we should document them -- QUICK! Our ISVs are already months behind. They key thing we need to understand is if we want ISVs to extend the shell in the way that Athena is doing it currently or the way.

>From my perspective this is a reflection much larger problems. We need to get our act together internally on a shell extensibility strategy. Is Office going to ever be key holder for shell innovation? Is this going to continue to come from the PSD shell team? If so, we need they need to make darn sure that NT is kept in mind when they do things. The only real way for that to happen is to effort and the PSD effort into one team. Otherwise there is no forcing function for development issues like this. Otherwise one team constantly plays cleanup and only the short-term approach wins. Not good. The other problem is that none of this seems to get communicaated to DRG - this is important. We have to hear a rumor from someone and then run around like crazy trying to figure out what's going on. For cryin' out loud - the NT folks did not even know what Athena was!

In any case the decision to unify our teams and strategy needs to take place at a higher (and much more objective place). Any input you might have is greatly appreciated.

- Scott

A SIDE NOTE
We also need to get our PIM strategy together. Why in the world do we have Schedule +, Ren, Pegasus (I understand this somewhat), and Athena? This is going to be phenomenally confusing for our customers.