Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

[News] [Rival] Microsoft's Latest API 'Undocumentation' Criticised

  • Subject: [News] [Rival] Microsoft's Latest API 'Undocumentation' Criticised
  • From: Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx>
  • Date: Tue, 11 Mar 2008 02:55:49 +0000
  • Newsgroups: comp.os.linux.advocacy
  • Organization: Freelance
  • User-agent: KNode/0.10.4
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

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index