Gaps found in Microsoft Exchange API documentation
,----[ Quote ]
| Speaking to ZDNet.co.uk at the CeBIT conference, Joseph said Microsoft's
| start is not promising: "This could definitely make life easier for
| developers, but we have spotted over 200 undocumented exceptions, including
| one that allows you to create recurring calendar appointments in Exchange. It
| was in the documentation for Exchange 2000, but they forgot to document it
| for Exchange 2003 and Exchange 2007."
`----
http://news.zdnet.co.uk/software/0,1000000121,39364629,00.htm
More BS which is a case of working in isolation rather than with open
standards:
Sun, Microsoft open interop centre
,----[ Quote ]
| Efforts announced last September to improve interoperability of Sun's
| hardware and Microsoft's software continue to take form with the official
| opening of the Sun/Microsoft Interoperability Center.
`----
http://www.itwire.com/content/view/17071/1054/
Doug's posts about "undocumentation" below (Microsoft sabotaging competitor
interop).
================================================================================
================================================================================
From: markwa Thu Jan 25 12:08:05 1990
To: winbug
Cc: davidw; greglo
Subject: missing constants WEP_ in windows.h
Date: Mon Nov 04 15:44:06 PDT 1991
Two constants need to be defined in Windows.h
WEP_SYSTEMEXIT (system shutdown in progress)
WEP_FREE_DLL (DLL use count is zero)
I don't know what the numerics valuse are; DavidW should know.
These two constants are already documented in the Guide to Programming
chapter on DLLs.
From: bobgu Thu Jan 25 13:15:31 1990
To: markwa
Cc: jimgr; t-jeffbo
Subject: Re: Undocumentated API functions found in WINDOWS.H
> From narkwa Thu JAn 25 13:06:29 1990
The above is nice work!
Please keep in mind, however, that we still have not dealt with making
public the intrnal functions being used by Apps.
I am about 95% complate on this task as well. The current tally indicates
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/5000/PX05084.pdf
================================================================================
================================================================================
REDACTED
..
REDACTED
..
From: jimgr Mon Jan 16 14:30:16 1989
To: markwa; russw
Subject: Re: Breakdown of new api calls
Date: Thu Nov 07 15:18:11 PDT 1991
It turns out I inadvertantly left off two categories from my list:
String functions (lstrcat, IsCharUpper, etc.)
File i/o functions (_lclose, etc)
This brings the total to 59.
Please note that when I use the term "new APIs." I am also referring to
previously "hidden" functions which will now be documentated. They are
new insofar as they will be added to the documenation although they
already exist.
> From russw Mon Jan 16 13:38:12 1989
To: markwa
Subject: Breakdown of new api calls
Cc: jimgr
Date: Mon Jan 16 13:36:27 1989
I count them up and get 42 not 60
..
REDACTED
..
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/4000/PX04600.pdf
================================================================================
================================================================================
From: K.C. Johnson
To: internet:kurtd@xxxxxxxxxxxxx
Date: 10/14/97 9:26 AM
Subject: Outlook/MAPI questions.
Kurt,
Thanks for taking the time to look at these issues.
1) Outlook is doing a GetProps and/or SetProps on the following
undocumented MAPI properties. What are they?
36D0
36D1
36D2
36D3
36D4
36D5
36D6
36E0
36E1
36E4
36E5
36E6
36EB
0000
1080
2) What other properties, other than named properties, have been
introduced by Outlook?
3) What Interfaces does a message store provider have to support in
order to allow the REMINDERS feature to work in Outlook.
4) What new message classes are implemented in Outlook (i.e.
IPM.Activity, etc.). What do they represent?
5) Is there any information on the meaning and usage of the IPF subtree?
Are the Outlook folders, like Calendar (IPF.Appointment), supposed to
get created in a different subtree than IPM? How are the IPM and IPF
subtrees related?
6) Outlook is creating approximately 100 new named properties. What are
the specifications of these properties? I realize that, by definition, a
message store provider shouldn’t need to know anything specific about
the named properties being created, but in order to allow a nice
integration it is needed. For instance, it looks like a free/busy
information property is being created. What is its format? We already
have busy/free information that we would like to translate to and from
the Outlook format.
Thanks,
- K.C.-
CC: Ben Anderson, Bill Mangum, James Whitchurch, John Galley
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02778.pdf
================================================================================
================================================================================
Ryan Rlchards - Problems with Microsoft continue ........... Page 1
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 program 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 had 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@xxxxxxxxxx
CC: Ed McGarr, Eldon Greenwood, John Galley, Paul Smart, Stewart Nelson
NWA 000197
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02667.pdf
================================================================================
================================================================================
>From : Todd Millett
To: Internet:novsup@xxxxxxxxxxxxx
Date: 1/10/96 2:39pm
Subject: Windows 95 Group Policy Support
We are trying to get group policies to work with our client. However,
there is no documented method for our client to pass group information
to POLEDiT.EXE. When we looked at the GROUPPOL.INF and GROUPPOL.REG
files, it became obvious that there is some interface that we are not
aware of, which has not been documented.
The GROUPP0L.REG file sets a value under the Network Provider key:
[KKEY-LOCAL-MACHINE\System\CurrentControlSet\Services\NWNP32\NetworkProviderj
the value is:
"GroupFcn’=’GROUPPOL.DLL, NWGetUserGroups"
I assume this tells GROUPPOL.DLL which entry point to call to get the
group and user information.
How can we implement this? Where is it documented? Is this function
supposed to implemented in the Network Provider? It’s not documented
anywhere in the Network Provider spec.
Any documentation you could give us on the interface between
POLEDIT.EXE, GROUPPOL.DLL, and the Network Provider DLL would be
appreciated.
Thanks,
Todd Millett
Novell, Inc.
CC: WIN95
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02452.pdf
================================================================================
================================================================================
From: Brad Silverberg [bradsi]
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 apis was based on a set
of considerations which are no longer operable, the win95 shell will be
on winnnt and the shell extensions will run fine there - there is no
issue about supporting on nt.
- the win95 team did "make dam 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); their changes will be
merged back into the code base.
From: Brad Struss
To: bradsi; paulma
Cc: cameronm; doughe
Subject: F’W: 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 the prerelease Athena PIM, it now appears that
full Explorer integration is supported on 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 betas would
not be supported moving forward. This decision was based upon the
difficulty the Windows NT team would have 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 intial
release of Win95 and would be doc’d as b-list apis 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 interfaces,and told them that (1) the
functionality of running in an integrated window was gone and (2) they
were strongly discouraged fromn using these modified apis at all because
of compatibility risks, 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 Hennch HS98 0]20900
Cc: Brad Struss; Jerry Drmn. Tammy Steele
Subject: Shel extensibdity and ISVs
Date: 08 August 1995 10:54PM
Pnonty: 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 an 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 a 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 reason 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 in 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, lever-age, the works! What’s strange about all of
this is that it looks like th s 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 dam sure that NT is kept in mind when
they do things. The only real way for that to happen is to combine the
BSD effort and 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 communicated to DRG - this is
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.
================================================================================
================================================================================
From: jonm Tue Aug 29 17:03:22 1989
To: markwa
Subject: DefineHandleTable
Date: Tue Aug 29 17:00:30 1989
..
The question is: do you think it is feasable to document
"DefineHandleTable" for the ISV programmers to use?
"DefineHandleTable" is an undocumented Windows call which is used by the
Apps Division. It allows great speedups when using movable memory
because it permits the program to find the current address of a movable
segment (or detect if it's paged out in EMM) without having to make a
Windows call.
..
I am not sure about this since Microsoft's public position has been that
Apps Division programmers do not have special hooks into Windows, when,
in fact, they do. Therefore, it might be embarrising to document
"DefineHandleTable" at this late stage, as part of a system for ISV's to
use. Could you give me some feedback on whether this is an option?
Thanks,
Jonathan
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/0000/PX00141.pdf
================================================================================
================================================================================
Microsoft finds a few overlooked interoperability protocols
,----[ Quote ]
| Microsoft Corp is still finding communications protocols that it
| should be licensing to rivals almost five years after it was
| ordered to do so following the US antitrust decision.
|
| The details are revealed in the latest joint status report,
| which outlines the US Department of Justice's concerns that
| the company is still finding protocols that should have been
| included in the Microsoft Communications Protocol Program
| but were "inadvertently overlooked".
`----
http://www.cbronline.com/article_news.asp?guid=41E367D5-2E83-4928-A677-83A156A0FE61
================================================================================
================================================================================
,----[ Quote ]
| A number of Microsoft ex-employees and certified developers have
| referred to much of Microsoft's formal documentation as "undocumentation"
`----
http://www.sonic.net/~undoc/comes_v_microsoft/Supp_Rpt_Andrew_Schulman.pdf
================================================================================
================================================================================
Microsoft's Allegedly Undocumented APIs - Comes v. Microsoft
,----[ Quote ]
| One of the allegations is that in this expert's opinion, Andrew
| Schulman, "Microsoft Office uses (and copies) undocumented DirectUI APIs"
| and "Microsoft Office and other Microsoft applications use undocumented
| Windows Line Services APIs".
`----
http://www.groklaw.net/article.php?story=2007020819534335
================================================================================
================================================================================
Expert Testimony of Ronald Alepin in Comes v. Microsoft - Embrace, Extend,
Extinguish
,----[ Quote ]
| You'll hear some emails read aloud, one of Bill Gates's, an email from
| 1996 about Java, where he says he was losing sleep over how great
| Java was, and you'll see a strategy he suggested -- "fully
| supporting Java and extending it in a Windows/Microsoft way".
|
| [...]
|
| Well, when applets are cross-platform, it expands the number of
| applications that are available to you so you can go to a website.
| And if you have a Linux computer or a Macintosh computer or a Windows 3.1
| computer, you can get an application and it will run.
|
| You don't have to either select a specific application or hope that the
| independent software vendor or the website created the application for your
| platform. So it would increase the number of applications available to you.
`----
http://www.groklaw.net/article.php?story=20070108020408557
================================================================================
================================================================================
Comes v. Microsoft Resumes Today
,----[ Quote ]
| "Ronald Alepin, an independent consultant and former CTO for Fujitsu,
| disputed the idea that Microsoft had been an innovator in the field.
| He said that interoperability protocols were developed by companies
| other than Microsoft, and that Microsoft has simply extended the
| protocols and then refused to disclose the extensions. In so doing,
| he told the court, Microsoft "has hijacked standard
| interoperability protocols agreed by the entire industry."
`----
http://www.groklaw.net/article.php?story=20070104031852847
================================================================================
================================================================================
------
PLAINTIFF'S EXIBIT 1413 Comes v. Microsoft
>From bradsi Thu Aug 27 08:40:39 1992
To: cameronm jonl mikeemap paula
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 a good practice. though it's not as straightforward 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
forwarder 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 apps 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 been grown accustomed to it. the fact that other companies
have been able to product world-class windows products (eg. Borland
Quattro Pro, Paradox, Lotus Ami Pro 3.0, Freelance, etc) is proof of
that.
s to (a) doc the api's we know apps group is using, and (b) give the
apps group the same access to sources we give to other isvs. [ie, in
certain limited circumstances.] if we don't do (b), the issue will
never die
EXIHIBIT 53 9/6/01 Mykrvold
MS 5040157
CONFIDENTIAL
------
http://www.iowaconsumercase.org/011607/1000/PX01413.pdf
------
PLAINTIFF'S EXIBIT 1614 Comes v. Microsoft
Erik Stevenson
From: Dessis 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: Monday, 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 documnet
Date: Wednesday, April 07, 1993 7:51PM
Short and sweet (or sour). I've red thru most of the materials you
sent along, and they are awfull. You never addressed 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 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 queus 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 documenting 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 denail continues
ad nausem. Why not just document the APIs, preface the document with
some HONEST history [ yes, we did use undoc'd API's, 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 the code, then give me a plausable explaination
for why they did. truthful would be nice.
The people who read this document are no 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.
EXH 32 DATE 2/13/02
Witness Silverberg
MAry W Miller
MS 7092083
CONFIDENTIAL
-------
http://www.iowaconsumercase.org/011607/1000/PX01614.pdf
http://www.groklaw.net/article.php?story=20070127202224445
|
|
