decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books


Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook


Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

A Comes Exhibit: "Undoc APIs document" - Update: And Another
Wednesday, November 25 2009 @ 04:58 AM EST

I'm deep into trying to list all 158 exhibits to Novell's response to Microsoft's cross motion for summary judgment in the WordPerfect antitrust litigation. We are also trying to go through all the exhibits from the Comes v. Microsoft antitrust litigation, because Microsoft and Novell were having trouble finding relevant materials in discovery, since the database they have available is not easily searchable. We have not finished, but I did find one Comes exhibit so far that I think you might find of interest. So I thought I'd take a break and share it with you.

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


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.


Update: Here's another.This second exhibit is Comes Plaintiff's Exhibit 2383, an email thread that ends with one from Brad Silverberg to Brad Struss and Paul Maritz, with a cc to Cameron Myhrvold and Doug Henrich dated August 11, 1995, subject line "RE: Shell extensibility and ISVs" which discusses a "decision to not expose the shell extension api's" regarding explorer, which left ISVs months behind Microsoft:
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?



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.


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.


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

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.


A Comes Exhibit: "Undoc APIs document" - Update: And Another | 86 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
OT - Off Topic thread starts here
Authored by: Totosplatz on Wednesday, November 25 2009 @ 05:41 AM EST
Please make links clicky

Greetings from Zhuhai, Guangdong, China; or Portland, Oregon, USA (location

All the best to one and all.

[ Reply to This | # ]

NP - News Picks Articles Comments Thread
Authored by: Totosplatz on Wednesday, November 25 2009 @ 05:45 AM EST
Please make links clicky, news picks article title in subject if possible...

Greetings from Zhuhai, Guangdong, China; or Portland, Oregon, USA (location

All the best to one and all.

[ Reply to This | # ]

Corrections, if any
Authored by: Totosplatz on Wednesday, November 25 2009 @ 05:47 AM EST
Correction hint in the subject, if possible...

Greetings from Zhuhai, Guangdong, China; or Portland, Oregon, USA (location

All the best to one and all.

[ Reply to This | # ]

A Comes Exhibit: "Undoc APIs document"
Authored by: Anonymous on Wednesday, November 25 2009 @ 06:11 AM EST

I haven't read the docs yet, but Schulman must be the Schulman who wrote for
Dr. Dobbs in those days.


[ Reply to This | # ]

management's view
Authored by: nola on Wednesday, November 25 2009 @ 06:36 AM EST
Unfortunately, this is a doc that reflects management's view on this entire subject

How sad, but how expected.

[ Reply to This | # ]

Unless we (billg/mikemap) are willing to acknowledge our "sloppiness".....
Authored by: tiger99 on Wednesday, November 25 2009 @ 06:44 AM EST
Not much chance of that, I think. Is Gates capable of knowing that he is sloppy,
far less admitting it? I think the abysmal quality of M$ products suggests not.

[ Reply to This | # ]

PJ: Found another document !
Authored by: Anonymous on Wednesday, November 25 2009 @ 08:27 AM EST
Exhibit 2151 is a letter from Bill Gates, talking about iShellBrowser, and he says:
I have decided that we should not publish these extensions. We should wait until we have a way to do a high level of integration that will be harder for the likes of Notes, Wordperfect to achieve and which will give Office a real advantage.

and later:
Our goal is to have Office 96 sell better because of the shell integration work

[ Reply to This | # ]

Is the document in there too?
Authored by: rsteinmetz70112 on Wednesday, November 25 2009 @ 11:21 AM EST
These emails refer to another document. Do you know what it is? Do you have it?

Rsteinmetz - IANAL therefore my opinions are illegal.

"I could be wrong now, but I don't think so."
Randy Newman - The Title Theme from Monk

[ Reply to This | # ]

This Dennis Adler guy has brains
Authored by: The Mad Hatter r on Wednesday, November 25 2009 @ 11:43 AM EST

And quite frankly they should have listened to him. It would have cost them a
bit in sales possibly, but it would have helped a lot in court, and with
developers, who now have the impression that they cannot trust Microsoft.


[ Reply to This | # ]

For those trying to keep track, a cross reference.
Authored by: Anonymous on Friday, November 27 2009 @ 10:58 PM EST
You know that Microsoft loves to code name projects.
Years later, how do you decipher them?
Get a program! You can't tell the players without a program!

In this case, MSDN's Channel Nine, a developer network and
forum. See this raw URL,
I left it "dead" because some folks might want to avoid
Microsoft hosted sites.

-------- Plan text copy --------

[b]Current CodeNames[/b]
Avalon Windows Presentation Foundation, WPF is the
presentation subsystem class libraries in WinFX.
Aero UI in Windows Vista
Aruba Windows Media Platform for Blackcomb
Ajax New Set of asynchonous technologies for web
applications enabling richer user experiences
Blackcomb Successor to Vista
Cairo Base collection of technologies which largely
evolved into the core technologies in 1.Vista.
Cider VS Designer for Windows Presentation Foundation
Longhorn Windows Vista
Monad Longorn Command Shell. Msh is the new
Vienna Office Live Communication Server 2005
Whidbey Visual Studio .NET 2005
Orcas Visual Studio 2008
Hawaii Future version of Visual Studio (after the Orcas
Whitehorse VS.NET 2005 Design Tool Suite
WinFx The set of next-generation managed APIs provided by
Yukon SQL Server 2005 scripting and automation environment
for Windows
Acrylic Microsoft Expression Graphic Designer. A new
professional graphics software.
Sparkle Microsoft Expression Interactive Designer.
Quartz Microsoft Expression Web Designer.
WinFS Next-generation Unified Storage Sub-system for

[b]Operating System Components / Versions[/b]
Avalon Windows Presentation Foundation, WPF is the
presentation subsystem class libraries in WinFX.
Asteroid Windows 2000 SP1
Aero UI in Windows Vista
Bearpaw Windows Terminal Services for Windows Server 2003
Blackcomb Is the server version of Vista
Bobcat Windows Server 2003 Small Business Edition
Cairo Base collection of technologies which largely
evolved into the core technologies in Vista.
Chicago Windows 95
Daytona Windows NT 3.5
Detroit Windows 95 OSR 2
Freestyle Windows XP Media Center Edition
Frosting Windows 95 Plus!
Harmony Windows XP Media Center Edition 2004
Impala Windows NT4 Embedded
Indigo Communications services used in Vista, also called
WCF(Windows Communication Foundation)
Janus Windows 3.1
Lonestar Windows XP Tablet PC Edition 2005
Longhorn Windows Vista
Mantis Windows XP Embedded 5.1
Memphis Windows 98
Mesquite Batch Management tools for Windows NT/Windows 2000
Millenium/Georgia Windows ME
Mir Internal Mercury release
NAS 3.0 Windows Storage Server 2003
Nashville Internet Explorer 4, for Windows 95
Neptune Cancelled successor to Windows 98
Newshell Alpha shell update for Windows NT 3.x
Panther Abandoned port of Windows NT, replaced by Chicago
Slalom Windows Media Center for Vista
Sparta Windows for Workgroups 3.1
Springboard Backporting of Vista technologies to Windows
Snowball Windows for Workgroups 3.11
Sundown Windows XP 64-bit
SUR Patch to Windows 3.51
Symphony Windows XP Media Center Edition 2005
Whistler Windows XP
Windows Windows 1.0
Windows 286 Windows 2.0
WinFx The set of next-generation managed APIs provided by

[b]Server Products[/b]

Starfighter SQL Server 6.0
Hydra SQL Server 6.5
Sphinx SQL Server 7.0
Plato SQL Server 7.0 OLAP Services
Shiloh SQL Server 2000
Liberty SQL Server 2000 64-bit Edition
Rosetta SQL Server 2000 Reporting Services
Aurum SQL Server 2000, data mining toolkit
Yukon SQL Server 2005
Katmai/Acadia SQL Server 2008

Osmium Exchange Server 5.5
Platinum Exchange Server 2002
Titanium Exchange Server 2003
Kodiak Abandoned successor to Exchange 2003.
Magma Embedded Exchange

Tahoe Sharepoint Server 2001
Matrix Sharepoint Portal Server v2

Latinum BizTalk 2000
Bizet BizTalk 2002

Falcon Message Queue Server (MSMQ)
Viper Transaction Server 2.0
Hydra Windows NT Terminal Services
Babylon Host Integration Server
Cedar COM Transaction Integrator for CICS and IMS (COMTI)
Wolfpack Cluster Server
Vienna Office Live Communication Server 2005
Hermes System Management Server
Kahiltna Commerce Server 2.0
Comet ISA 2000

[b]Mobile PC[/b]
Lonestar Windows XP Tablet PC Edition 2005
Haiku Post-2007 mobile PC hardware design

[b]Mobile Platforms[/b]
Alder Windows CE 2.1
Apolllo Windows CE for Auto PC
Axe Embedded Toolkit for Windows CE 2.0 and 2.1
Brich Windows CE 2.11 and 2.12
Cedar Windows CE 3.0
Chainsaw Windows CE Platform Builder 3.0
Galileo Windows CE for Handheld PC 2000
Goldeneye Windows CE for AutoPC
Gryphon Windows CE 2.0 for palm-sized PCs
Hai Ku Multimedia Extension for Windows
Hermes Windows CE for webphones
Jameson Windows CE.NET Update
Jupiter Windows CE for Handheld PC Pro 3.0 (or Macallan
Windows CE.NET Corporate Edition??)
Laguna Upcoming version of SQL Server, for Windows CE
McKendrick Windows CE for Media2G0
Mercury Windows CE for Hanheld PC
Merlin Pocket PC 2002 (or Windows CE 2002??)
Mira Windows CE for Smart Display Devices
Orion Windows CE for Chinese Handheld PC
Ozone Pocket PC 2003
Pegasus Windows CE 1.0
Rapier Windows CE for PocketPC 2000
Stinger Smartphone 2002 (or Windows CE for Smartphones 1.0??
Starlite .NET Compact Framework 1.0
Talisker Windows CE .NET
Tazz Microsoft Phone
Visine Novell Netware Migration Tool
Venus Windows CE for webTV
Wyvern Windows CE for Color Palm PC

|Trident|Dynamic HTML|
Springboard Microsoft's security excellence and review
project, who's fruits were deployed via Office 2003 SP1,
Windows XP SP1 and Windows Server 2003 SP1
Palladium An on-again off-again secure runtime
environment called Next Generation Secure Computing Base
AirStream Services for wireless connections to
Avalanche Internet-Information-Services 5.0
Argo Query-Services for SQL-Server 2000
Aruba Windows Media Platform for Blackcomb
Athena Outlook Express
Athens New prototype PC design (with HP)
Blackbird MSN SDK
Blizzard Business oriented Set of Services in .NET My
Basecamp VPN dial-up networking update (PPTP) for win95
Calais Smart-Card Technologies
Cascade Windows Active-Directory
Cayman NetMeeting 3.0 Version 3.01 4.4.3400
Chrome ChromeEffects (GUI-Feature)
Cirrus Access 1.0
Comet Network-Tools for Windows 2000
Corona Windows Media-Technologies 9.0
Coyote Distributed Views for SQL-Server 2000
Darwin Windows Installer 1.1 Version 1.1
Dart Setup for Oracle, SQL-Server ODBC-driver
DaVinci Database-Design & Query-Tools
Denali Active Server Pages
Europa New GUI for the MSN-Community
Fahrenheit A defunct collaboration between Microsoft &
SGI Graphics to combine Direct3D and OpenGL by creating a
unified 3D API. -Direct X Version 10.0-
Falcon Windows Messaging Queuing Server
Fusion Technologies for DLL improvements
Gemini Succesor GUI "Europa" for MSN-Community
Gibraltar Internet-Information-Server 1.0 Version 3.0
Grizzly Workflow-Designer for SQL-Server 2000
Hailstorm XML Message Interface
Hailstorm .NET My Services
HardeningPack Internet Explorer Enhanced Security (Windows
Server 2003)
Hydra Windows NT Terminal Services
Idaho Preliminary/alpha version of the next Windows-
Jakarta JAVA-Engine for Internet Explorer 3.0
Kagera (Kajera??) OLE-DB Provider for ODBC-Data
Kahuna Windows Live Mail
K2 Internet-Information-Server 4.0
Lightning .NET Common Language Runtime (CLR)
Luna Theme technology for Windows XP
Luxor OLE-Provider-Services for Yukon
Magic Carpet Passport-Technologien
Marvel Microsoft Network (MSN)
Merlin Microsoft® Internet Explorer for Dreamcast
(cancelled circa 1999).
Mercury DUN 1.2 update for Win95
Monad Longorn Command Shell. Msh is the new scripting and
automation environment for Windows
NGWS (Next Generation Windows/Web Services) .Net
Normandy Microsoft Commercial Internet System (MCIS)
Oprah Netmeeting
O'hare Internet Explorer 1.00.
Plato OLAP-Server air jordan 11
Project 42 (from Lightning) .NET Common Language
Runtime (CLR)
Ren Outlook
Quartz Direct Show
Sideshow Task Shelf of Longhorn (MS research)
Slate Microsoft Management-Console (MMC)
Spark Integration of Windows SharePoint Services and CMS
Steelhead Windows NT Routing & Remote-Access Services
Tahiti SharedView Beta2
Talisman 3D Graphic- und Multimedia Architecture
Tensor OLE-DB Extensions for OLAP
Touchdown Outlook 97 (Also mentioned:Public folders
for MS Exchange)
Trident Dynamic HTML (DHTML)
Tungsten Microsoft Rights Management Services (RMS)
Whisper Speech Recognition (speech-to-text)
Xenon Xbox 360

[ Reply to This | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )