Development

From Techrights

(Difference between revisions)
Jump to: navigation, search
Line 136: Line 136:
others in and then charging them money for the 'open' protocols.  
others in and then charging them money for the 'open' protocols.  
--  
--  
 +
court documents in the case of Comes v. Microsoft.
 +
 +
 +
 +
== we want OpenDOC to fail .. ==
 +
From: Jim Allchin
 +
To: Bob Muglia; Collins Hemmingway; Lowell Tuttman
 +
 +
The problem is more complicated than you suggest. Interoperability is a very
 +
complicated and confusing topic. The last thing we want to do is deal with
 +
testing or certifying anything for someone else. The thing I want to certify is
 +
that an APP is compatible with OLE. I hope OpenDoc does not achieve interop or
 +
does a terrible job. We *want* them to fail.
 +
 +
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02026.pdf
 +
--
 +
court documents in the case of Comes v. Microsoft.
court documents in the case of Comes v. Microsoft.

Revision as of 19:23, 22 January 2009

style guide biased towards MS apps ..

To: Don Casey cc: Alex Morror, Frank King, AI-ESC, AI-PSC, AI-TSC, Richard Wolf From: Richard Wolf Date 09/11/91 07:03:09 Pm Subject:


This memo lists and briefly describes items in the draft Microsoft Style Guide for Windows that are biased towards Microsoft applications. Individually, none of the items are major changes. They are a collection of small arbitrary decisions without clear user benefit that taken together give Microsoft an advantage because most of their applications already conform ..

..


Second, the style guide provides little or no indication of future object oriented user interface directions that Microsoft is developing, including property sheets, direct manipulation, pop-up menus, and notebook techniques. Essentially, current and somewhat arbitrary GUI practices of Microsoft applications are being set up as detailed standards while Microsoft works on new approaches that obsolete these standards. Microsoft has privately disclosed to Lotus some elements of their intended direction.

http://edge-op.org/iowa/www.iowaconsumercase.org/011607/0000/PX00956.pdf

-- court documents in the case of Comes v. Microsoft.


on the dangers of open Interfaces ..

Erik Stevenson

From: Brad Silverberg To: paulma Subject: FW: DMTF and what to do with it Date: Friday, January 28, 1994 5:36 PM

what a fucking mess

From: John Ludwig To: Brad Silverberg Subject: FW: DMTF and what to do with it Date: Thursday, January 27, 1994 3:55 PM

I thought you should see this. All I can say is "simply amazing" . Below Dan is answering my questions to him on this mess.

If you have thoughts, I could use your help.

thanks, jim

From: Dan Shelly To: Jim Allchin; Jonathan Roberts; Richard Tong Cc: Bob Muglia; David Thompson (NT) Subject: RE: DMTF and what to do with it Date: Monday, Jaauary 24, 1994 5:52 PM

Answers embedded below. I was supposed to meet with IBM this Friday to discuss our distribution of source code to the DMTF. I backed out based on the fact our lawyers are still looking this over and it could take a *LONG* time for them to approve.

What a fucking mess.

>> A clear analysis of the situation

0. Is ther anything in writing?

>> The DMTF bylaws upon which this is based are not clear. The original intent of the DMTF was to deliver object level implimentation. Nowhere have we committed in *writing* to deliver source code, however, if we don't Intel has already stated that they will. Evidentally the verbal agreement for the last 1.5 years has been that all work done by DMTF will be shared.

1. What protocol is being used to gather up the Novell stuff?

>> The idea of the spec is that it is protocol independent, runs on top of whatever you use. In Novell's case that could be either IPX/SPX or TCP/IP.

Having the DMI client interfaces might even be good on OS/2, etc >> OS/2 clients with DMI interfaces would be easily managable from Netware.

2. Are *we* getting any source code from anyone? I don't see people lining up to give us code. And you can guess how I feel about giving them source code.

>> We would get the OS/2 service layer code without encumbrance (per Ken edwards, IBM). Hardly a stellar trade for providing access to our install base of clients. SunNet will also provide a UNIX implimentation only after DMI is adopted as a COSE standard (supposedly very soon).

The implimentation of the DMI layer will pick up information from random places and it could change with new versions of the system so I'm not interested in getting into some support problems with Novell and IBM shipping some DMI code that doesn't work on the next release. This is a rat hole.

>> It gets worse. It's obvious that what IBM and Novell want to do is "add functionality" hence their request for unencumbered source code. Based on what I was hearing and past performance of these 2, their implimentation would work with our OS's but then add extra functionality for OS/2, AIX, Dr-DOS, etc. My analysis is that we would shortly be positioned as "less manageable" and IBM/Novell could legally charge a license fee for their implimentation.

..

4. What pisses me off the most is that they didn't define the protocol - the most key thing in my opinion .. given the path we're on, it's Novell's protocol that will become tha standard.

>> Should IBM and Novell settle on a single supported implimentation for which we then have no further source code rights .. What this does is raise the prioroty for us to figure out what the pan for this protocol really should be ..

>> Suggestions for how to proceed

..

2. The "cooperation option. We provide a license for our implimentation to all 8 members of DMTF with the source *BUT* Microsoft retains rights to all future development based on this code, and royalty rights for any secondary license agreements ..

..

Of these optins I would suggest that we opt for #2. It will forestall IBM/Novell the longest to allow us time to adopt and evengleize a consistent protocol-based solution across all our clients ..

http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02003.pdf

With no sense of irony or insight, he's just ascribed to IBM/Novell Microsofts' own strategy. Co-opt a standard, refuse access to the source, accuse the other fella of being "less manageable" and then charge him a license fee for their own interfaces. There's also a sense of reality denial where he see a paranoid projection of his own fears and intentions. The spec is protocol independent. The protocol is only important if you are planning on locking the others in and then charging them money for the 'open' protocols. -- court documents in the case of Comes v. Microsoft.


we want OpenDOC to fail ..

From: Jim Allchin To: Bob Muglia; Collins Hemmingway; Lowell Tuttman

The problem is more complicated than you suggest. Interoperability is a very complicated and confusing topic. The last thing we want to do is deal with testing or certifying anything for someone else. The thing I want to certify is that an APP is compatible with OLE. I hope OpenDoc does not achieve interop or does a terrible job. We *want* them to fail.

http://edge-op.org/iowa/www.iowaconsumercase.org/011607/2000/PX02026.pdf --

court documents in the case of Comes v. Microsoft.

Personal tools
Search entire domain
Stories