|
|
|
| Authored by: foulis on Friday, June 01 2012 @ 01:42 PM EDT |
<p
align=right><b>PLAINTIFF'S<br>EXHIBIT<br><u>2446</
u></b><br>Comes v. Microsoft</p>
To: Alex Morrow/CAM/Lotus<br>
cc: John Manopoli/CAM/Lotus<br>
From: Noah Mendelsohn/CAM/Lotus<br>
Date: 01-04-96 05:19:59 PM<br>
Subject: Microsoft Support for OCX Development</p>
Earlier this afternoon you asked me for an update on our experiences with
support and documentation by Microsoft for their OCX technology. A list of our
concerns from earlier this year is contained in the attached note, dated 2/9/95.
As you know, most of my personal focus in the period since then has been on
other matters, but I have this afternoon reviewed the situation with several of
the developers here at Lotus who are working with OCX. They and I agree on the
following summary of our experiences in the period since February,
1995.</p>
<ul>
<li>The lack of freely licenced code and reference materials for native
(as opposed to MFC-based) OCX server and container implementation was and is a
significant impediment to both the planning and the implementation of our OCX
based products. One of our developers estimated that he would have finished his
year's work at least two months earlier, had the level of documentation for OCX
been equivalent to that provided for OLE 2.0. Lack of detailed information has
discouraged us from implementing more comprehensive OCX support in products that
were developed during 1995; this is especially true of OCX container functions.
As you know, licencing restrictions prevent many of our developers from
referring to the MFC sources for information on OLE or OCX
development.</li></p>
<li>Microsoft has released some useful new materials relating to OCX
development, and they have been helpful in making those materials available to
us. These materials include a draft of a new book on Ole Controls by Adam
Denning, and conformance guidelines for OCX implementation. While helpful, none
of these directly address our need for freely licenced reference implementations
of container and server functions. The book, in particular, relies heavily on
MFC, and specifically suggests that the reader consult the MFC source code in
certain areas; as noted above, the MFC licence severely limits our ability to
work with the source. Within the past month, Microsoft did release a simple
non-MFC based class framework for OCX server development; the framework was
provided to attendees of the Microsoft Internet Design Preview in early
December. I have not yet had the opportunity to review that code, and cannot
comment on its significance. In any case, it comes too late to affect the
products that we have spent the past year designing and
building.</li></p>
<li>Mark Colan, one of our OCX developers, says that Mike McKeown of
Microsoft Developer Relations informally promised that we would receive source
for an OLE control container to be provided as part of a Microsoft validation
suite. Mark says that we have not received that code from Microsoft, and I
suspect that it is not yet available. Such a validation container would indeed
be very useful, but it would probably not be a complete substitute for a
production quality reference container application. We're still hoping to
receive it at some time in the future.</li></p></ul>
My dealings with representatives from Microsoft remain cordial. They have been
generally helpful with arranging for our attendence at design previews for
various Microsoft system products, and also with getting us access to OCX
support when available. Microsoft has recently shifted much of their corporate
focus to the Internet, and they seem to be doing a better job of providing early
access to code and documentation in that area. We have had representatives at
recent Microsoft Internet Architecture Design Previews. The Internet code that
we've received, while still shaky, appears to be reasonably up-to-date. I hope
this is indicative of improvements in the level of support that we'll be
receiving in the future. Unfortunately, the lack of appropriate OCX
documentation was and is a significant problem.</p>
I apologize for not being able to pull together a more detailed or authoritative
analysis on short notice. I have tried to give a fair and balanced picture of
events through 1995, but it is possible that I missed</p>
<p align=right><u>[initials]</u><br><b>EXHIBIT
NO.<u> 8</u></b></p>
<p align=right>CONFIDENTIAL IBM 0410075024</p>
<hr>
<br>
something of significance. Please let me know if you need any further
information.</p>
Noah</p>
<br>
<center>SECTION WITHHELD ON THE<br>BASIS OF ATTORNEY
CLIENT<br>OR WORK PRODUCT PRIVILEGE</center>
<br>
<br>
<br>
<b>To:</b> John Landry, Ilene Lang, Tom Lemberg<br>
<b>cc:</b> Alex Morrow, Ron Sandstrom, Allen Olsen<br>
<b>From:</b> Noah Mendelsohn<br>
<b>Date:</b> 02/09/95 03:48:34 PM<br>
<b>Subject:</b> Microsoft OCX Support: is the Playing Field
Level?</p>
This note summarizes my concerns regarding Microsoft's support for ISV's
implementing the new OLE Controls (OCX) technology.</p>
OLE Controls, which are implemented as enhancements to OLE 2.0, are emerging as
the key component architecture for the Windows operating system platform.
Microsoft has also disclosed that OLE controls will be used as the basis for the
desktop user interface in Cairo, the successor to Windows NT.</p>
Microsoft has publicly committed, on numerous occasions, to ensuring a fair
separation between the application and system groups at Microsoft. Specifically,
they have promised to provide equivalent operating system API support and
documentation to application developers working inside and outside Microsoft. I
am concerned that these commitments are not being met in the case of OCX, and
that Lotus and other ISVs are being out at an unfair competitve disadvantage. As
you know, I have been responsible over the past two years for our technical
contacts with Microsoft regarding OLE 2.0 and related technologies. Though some
concerns regarding OLE 2.0 documentation and development process remain
unresolved, the support we received on OLE 2.0 was generally professional,
detailed, and in most cases responsive. Extensive documentation and sample code
was provided for most OLE 2.0 features, without onerous licencing restrictions.
I and a number of members of my group developed productive working relationships
with our counterparts at Microsoft, and most of the information we were given
has proven over time to be correct. Those relationship are based on the
assumption, which I believe to be correct, that Microsoft and Lotus have a
shared interest in seeing the features of Microsoft's operating system exploited
correctly and consistently in Lotus products.</p>
Recently, a number of concerns have risen regarding Microsoft's willingness and
ability to extend such support to the new OLE Controls technology. For the
reasons listed below, I believe that Microsoft</p>
<p align=right>CONFIDENTIAL IBM 0410075025</p>
<hr>
<br>
application developers have been given earlier and more detailed access to OCX
specifications then we have had here at Lotus. These are serious concerns, and I
hope that we can address them with Microsoft promptly:</p>
<ul>
<li><b>Licensed Microsoft Tools Code is the Only Available Sample
for OCX Server Implementation</b></p>
When OLE 2.0 was released, it was accompanied by an extensive reference manual
in two volumes, an additional guidebook by Kraig Brockschmidt, and a number of
reasonably detailed sample programs for both container and server functions.
Even with that level of information, developers inside and outside Microsoft
struggled to build robust implementations of OLE 2.0. Microsoft also released a
version of their Foundation Classes (MFCs), which simplified implementation of
OLE 2.0. The source code provided with MFC also served as a useful sample OLE
implementation for some developers outside of Lotus, but licensing restrictions
on the MFC source prevented its use for that purpose within Lotus. The other
samples provided by the Microsoft operating system group proved adequate for
most purposes, and we recieved reasonably good direct support from Microsoft
when additional information was needed.</p>
With OLE controls, the level of support and documentation from Microsoft has
changed dramatically for the worse. MFC version 3.0 is now the
<i>only</i> production quality example of an OCX server
implementation available outside of Microsoft. Furthermore, the MFC's continue
to be governed by licensing restrictions which prevent their use for many
purposes within Lotus. Microsoft has effectively chosen to use a restrictively
licensed product of their tools division as the only documentation for critical
new operating system feature.</li></p>
<li><b>Inadequate documentation of OCX Container
API</b></p>
The only OCX container sample code that's available is, by Microsofft's own
description, incomplete and inadequate as a guide to building quality products.
Nonetheless, Microsoft is shipping container implementations as part of their
Visual C++ and Access products, and we can assume that other Microsoft
containers will follow soon. Development of container support for Visual Basic
4.0 is presumed to be nearly complete. The transfer of the OLE Forms development
group to the Microsoft Office group (see below) clearly suggests that Microsoft
application developers have direct access to the OCX container specifications
that are unavailable to Lotus.</li></p>
<li><b>The OLE Forms Feature of the Cairo OS is being developed by
the Microsoft Office Applications Group</b></p>
OLE Forms are a counterpart to OLE controls and a cornerstone of the Cairo user
interface architecture. We were recently informed by a Microsoft employee that
responsibility for development of this operating system feature has been
transferred to the Microsoft Office <i>applications</i> group. The
implications of this are particularly disturbing:</p>
<ul><li>Developers of Microsoft office products have early access to
information on this key operating system technology.</li>
<li>Office developers have the opportunity to optimize OLE Forms to meet
their own needs, at the expense of supporting competitve
applications.</li>
<li>An inappropriate and potentially permanent tie between Microsoft's
application and operating system products is
created.</li></ul></p>
<li><b>Microsoft's "Access" application developed in
direct consultation with OCX developers</b></p>
<p align=right>CONFIDENTIAL IBM 0410075026</p>
<hr>
<br>
Microsoft's "Access" database product recently shipped with OCX
container support. Public information on writing such a container is extremely
sketchy even now, and was essentially unavailable at the time Access shipped. We
were told by an OCX developer that Access developers consulted frequently and
directly with the OCX development group to get the information needed to build a
container. Microsoft has also told us that there is no such support structure in
place for other ISVs even now that Microsoft's own products are available to
customers. Although they are willing to discuss creation of such a support
structure, and to provide support on a best-effort basis in the meantime, Access
has already been given a significant advantage relative to competitive products
like Lotus Approach. Furthermore, no commitments to any specific level of
support have been made at this time.</li></p>
<li><b>Developers of key OS features transferring to and from job
assignments in Microsoft applications groups</b></p>
Key developers of technologies relating to OLE 2.0 and OCX have transferred back
and forth between microsoft application and operating system groups over the
past several years. Clearly, such employees are in a position to bring specific
technical information and product planning perspectives with them as they
transfer. Competitors have no comparable access to the development
process.</li></ul></p>
Given our earlier positive experiences with OLE 2.0, the situation described
above is particularly disappointing and disturbing. Whether by design or
inadvertently, Microsoft has inappropriately tied implementation and support of
a key operating system component directly to their tools and application groups.
Those groups therefore have a dirct advantage when competing with Lotus, and a
conflict of interest in giving us support.</p>
I believe that we must ask Microsoft to:</p>
<ul><li>Ensure that responsibility for support and implementation of
operating system feature like OCX rests with the Operating Systems group at
Microsoft. Specifically, conflicts of interest between Microsoft's applications
(and tools) groups and their competitors must be avoided.</li></p>
<li>Ensure that neither documentation nor sample code required to exploit
operating system features carries a license more restrictive than that of the
operating system APIs themselves. Microsoft should not try to avoid such
responsibilities by claiming that particular Microsoft tools are required for
access to OS services.</li></p>
<li>Recommit to providing equivalent information and support for operating
system features to application and tool developers inside and outside of
Microsoft.</li></p>
<li>Avoid inappropriate transfers of personnel between groups if such
transfers would give an unfair competitive advantage to Microsoft
products.</li></p>
<li>Work specifically to redress any inequities which may have arisen in
the particular case of OCX and related
technologies.</li></ul></p>
We were visited recently by Mike Blaszczak, one of the lead OCX developers. Mike
was helpful and attentive to our concerns, and his visit represented a small but
significant positive step in providing access to OCX expertise for Lotus
developers. Nonetheless, the concerns listed above remain unresolved at this
time. Our earlier experiences with OLE suggest that Microsoft and Lotus can have
a productive and mutually beneficial relationship leading to the effective use
of their operating system technologies in our</p>
<p align=right>CONFIDENTIAL IBM 0410075027</p>
<hr>
<br>
products. I hope that we can work with Microsoft to provide us with access to
the information required to exploit OLE controls, OLE Forms, and other Microsoft
operating system technologies in our products.</p>
Noah</p>
<p align=right>CONFIDENTIAL IBM 0410075028</p>
[ Reply to This | Parent | # ]
|
| |
| Authored by: hrethgir on Friday, June 01 2012 @ 03:15 PM EDT |
<html>
<body>
MS 5037471<br>
CONFIDENTIAL<br>
<br>
HIGHLY CONFIDENTIAL<P>
From dwaynew Tue Sep 22 11:02:53 1992 <br>
X-MSMail-Message-ID: 9481640C <br>
X-MSMail-Parent-message-ID: 5326C3DE <br>
X-MSMail-Conversation-ID: 5326C3DE <br>
X-MSMail-WiseRemark: Microsoft Mail -- 3.0.729 <br>
From: Dwayne Walker <dwaynew@microsoft.com> <br>
To: davidt richb richta <br>
Date: Tue, 22 Sep 92 07:10:57 PDT <br>
Subject: RE: CREDIT LYONNAIS (fwd) <br>
Cc: dwaynew jonl pascalm paulma richt <br>
Status: RO <P>
David and Rich/Rich,<P>
Paul has a very valid point. This type of situation arises in many
accounts. We can not rollover and die on situations like this. David, I want
you and Richta to arrange an attack visit back into this account. We should be
able to take the NT beta, along with various development tools, etc. and keep
this account on Windows ("in this case NT"). <P>
We need to be VERY AGGRESSIVE in getting corporate accounts onto NT
starting with beta 1. With Win 3,1, W4W, NTBeta 1 and the NT/Win32-SDK, we
should be able to kick to ass. We need to make it clear to accounts and the
field that W4W and the NT-Beta are more bullets against OS/2 in accounts (make
sure they're firing the guns).<P>
David/Rich - I would like a status report on this within a week or so.
Lets stay on top on this please.<P>
Dwayne<P>
<br>
----------<br>
From: Paul Maritz<br>
To: Jonathan Lazarus<br>
Cc: Dwayne Walker; Pascal Martin; Richard Tong<br>
Subject: RE: CREDIT LYONNAIS (fwd)<br>
Date: Monday, September 21, 1992 8:33 AM<P>
This is crazy - we are just rolling over and agreeing with them that NT
will not be an option for 12-18months after release. Contrast this to CBA we
are there in tooth and nail, and have reasonable chance of getting them to move
directly to NT. This is more cost effective fo the customer and
us!!!!<P>
The NT beta will be coming out in mid-Oct, we haven't we gone to CL and
offered to come in and prove to them that NT is a solution for them. We should
line up the ISVs as well (cameroom probably already has Ingres). The key is to
show the customer that NT is real, and can save them the cost of deploying
another operating system which they are going to have to migrate off at some
time. NT has real advantages - particularly systems management - if we go in
there and pitch those effectively, then the account will get excited about NT
instead of having no faith in it.<P>
I want us to go back into CL with Hansw and NT product management and
CATM resources.<P>
--------------<br>
From: Jonathan Lazarus<br>
Date: Sunday, September 20, 1992 11:36PM<br>
<br>
Forwarded message:<br>
>From isagar Wed Sep 16 10:01:03 1992<br>
X-MSMail-Message-ID: 0CB43374<br>
X-MSMail-Conversation-ID: 0CB43374<br>
X-MSMail-WiseRemark: Microsoft Mail Internal -- Final
Release<br>
From: Isabelle Garnier <isagar@microsoft.com><br>
To: jonl<br>
Date: Wed, 16 Sep 92 17:48:00 PDT<br>
Subject: CREDIT LYONNAIS<br>
Cc: isagar jeanphc<P>
Hi Jon,<P>
How was your French holiday? Great, I hope!<br>
I was happy to meet you on the occasion of your visit to France. Thank
you very much for the metting we had with Credit Lyonnais ; it was not an easy
one for us, but they raised the important issues for them!<P>
You remember the main question was the availability of a version of LAN
Man for OS/2 V2 as a server. Paul Maritz might come to see you on that purpose
as the question was raised to him by Bernardv, after his meeting with Credit
Lyonnais (CL).<P>
Here is some more information regarding the need of CL for OS/2
V2:<P>
- the new version of the ELAN application for the branches is rewritten
by the developing partner of CL, 3S company, from character mode to PM mode on
the current version of OS/2 which is V2.<P>
- new tools developed by suppliers on CL's request are provided on OS/2
V2 : for instance, INGRES version of Windows 4GL has been released in September
for V2.<P>
- CL needs a new OS now ; OS/2 V2 is already available, whereas windows
NT is not; CL thinks NT will not be fully operational before 12 to 18 months
after its first release, considering the complexity of such a product.<P>
What kind of answer are we in a position to give to Credit Lyonnais in
the coming weeks ; they appreciated the fact you told them we would be looking a
tthe potential feasibility of porting LAN Man to OS/2 2server. Can you give us
some information regarding the possibility of getting a LAN Man version for this
platform?<P>
Thank you very much for your help.<P>
Isabelle
</body>
</html>[ Reply to This | Parent | # ]
|
|
|
|
|
