Evidence that this is a recurring strategy is presented below. Highlighted using bold face are bits of particular interest.
Watch how Microsoft used OLE in the past.
Behold the “black project”.
From: John Shewchuk
Sent: Thursday, October 05, 1995 2:46 PM
To: bens; bradsi; chrisjo; craigm; donbrad; jallard; jimall; johnlu;
mikecon; paulma; rict; thomasre
To: thomasre
Cc: patler
Subject: RE: Webmaster/Server ISV event – day one
When I got Gosling and Naughton started on the Java OLE control for Blackbird, it was a sensitive issue at Sun – Gosling was getting it done as a “black project”. So please don’t raisepublic awareness of the project without checking with Naughtion.
Regarding Java vs OLE controls
Both Gosling and Naughton will admit that java is a programming language and that without APIs to call, Java is kind of stupid. There is a growing consensus among developers that tried HotJava that it has major limitations.
The lack of APIs is the reason StarWave is doing the Java OLE control – so they can get access to OLE automation especially automation of Blackbird objects. Gosling admits that once someone does this it is no longer cross platform and it is hard to be safe.
Finally: OLE and Java go together nicely. You don’t need to position them as competitive. Java goes up against VB. We need to get the VB team to respond to Java. Maybe VB should be cross-platform and safe. See the Blackbird rude Q&A.
Regarding overall messages
I think the whole cross-platform issue is going to die down once we start getting cool OLE controls (or Netscape add-ons) that take advantage of DirectX and other Windows 95 APIs. Cross platform is an important customer message but in the long run it a bad technical goal because it means lowest common denominator. So talk the talk, but show customers and publishers what they are missing. Leverage our strength in great Windows 95 capabilities.
Netscape add-ins ONLY RUN IN A NETSCAPE BROWSER. You can’t use them in IE, Word, PowerPoint, VB, Delphi, VC++, Blackbird or anything else. You can’t even use them inside each other. OLE is OPEN, Netscape add-ins lock you into a Netscape only strategy. This is lame. Java is probably not much better.
Finally, both Java and Netscape add-ins fail to address design-time operation. This is a huge leverage point for Microsoft. Senior people that are fillly in the Netscape camp think twice when they see the Macromedia Director editor come up inside the Blackbird design environment. They think about what it will take to get this done in Netscape and it is a pain.
Why does this matter? Because it represents a radically different model of content creation than Java or Netscape add-ins suggest. CPs don’t want to write code!!! They want to focus on creating cool content. They
want simple, simple, simple. Programming is hard. OLE controls are PACKAGED bundles of capability. OLE makes it easy for hot software developers to package up a lot of code that the creatives can use. LibD from CRG can attest to the fact that Bud and they could provide their cool runtime to lots of non-programmers. (it turns out that many Macromedia users hate the fact that they have to learn Lingo to do anything cool.)
So let’s make sure we explain that OLE controls are more than JUST an add-in strategy. OLE Controls are the start of a COMPLETE strategy. Add an open message, VB Blackbird, IE with OLE control support, open
scripting, and so on, and then you have your story. Lets fight on our own turf – in other words, focus on content providers and ISVs (they are the enablers for the content providers) and give them what they want. And let the great applications win over the viewers.
FROM: Brad Silverberg
Infamous Microsoft documentation (if any is made available at all).
To: Douglas Wilson @ Lotus, Scott Kliger @ Lotus, Phil Stanhope @ Lotus,
Alex Morrow @ Lotus, Joe Gulhridge @ Lotus, Jack Ozzie @ IRIS, Barry
Brfggs @ Lotus, Aswan Dev, Ailen Olsen @ Lotus, Aswan Clients, Jeffrey R
Beir @ Lotus, Michael Welles @ Lotus, Steve Manousos @ Lotus, Mike
Vassilopoulos @ Lotus
cc: John Landrt @ Lotus, Ilene Lang @ Lotus
From: Noah Mendelsohn
Date: 02/03/95 03:54:31 PM
Subject: Meeting with Sara Williams Regarding OCX Status and Support
Sara Williams, an OLE/OCX/Cairo evangelist in Microsoft DRG visited with a group of Lotus developers at Rogers Steel on Tuesday afternoon, January 31. Here are minutes of our meeting. The purpose of the meeting was to review Lotus’ concerns regarding Microsoft’s fairness in supporting OCX development, and to answer other questions regarding OCX and OLE.
Unless otherwise indicated, all questions are from Lotus personnel and all answers are from Sara. Sara has promised to respond by email on all the unresolved points listed below. I’ve rearranged the order of discussion to put the most useful new information near the top.
Lotus Attendees: Noah Mendebohn, Scott Kliger, Phil Stanhope, Edward Ogu~ofor, Jeff Buxton
Primary topic:
Lack of appropriate support and documentation for OCX. Microsoft applications and tools seem to have an unfair advantage using OCX-how did Microsoft release container apps when nobody is supposed to have sample code yet?
The most important issue we discussed, and the one we spent the most time on, is Lotus’ concern that OCX support for ISV’s is inadequate, that sample code for containers is not available, that the only server samples are part of MFC and carry restrictive licenses, and that Microsoft has somehow managed to ship products using OCX in spite of these limitations. Speaking only for herself, Sara indicated that she shares many of these concerns. She also said that Microsoft as a whole does recognize that there is a problem regarding support for ISV’s using OCX.
We emphasized the degree to which we view this as a serious threat to our ability to compete. While there were also problems when OLE 2.0 itself was released, the OCX situation is far worse. For OLE 2.0, Microsoft provided comprehensive published documentation, an extensive support infrastructure, and sample implementations which were of moderately good quality and no more restrictively licensed than the Windows operating system itself.
The current situation with OCX is inappropriate. Sara reiterated that she understood our concerns, but said she had not realized the seriousness with which we viewed these problem. She asked what could be cone to resolve the problems. Among the possibilities that we suggested were:
(1) provide freely licensed production quality sample implementations of container and server immediately … if other samples cannot be provided, remove the licensing restrictions on the relevant parts of the MFC controls implementation and the CDK.
(2) publicly acknowledge that OCX is an operating system API, to be supported with at least the same degree of open process as is applied to the windows API and OLE 2.0.
(3) Provide open support and immediately redress any advantages which may currently be given to Microsoft applications or tools products in using OCX
(4) Lotus believes that support could be improved and integration with OLE technology streamlined if Microsoft were to transfer OCX development responsibility to their systems organization, but that is ultimately an internal concern of Microsoft.
Sara acknowledged that the problems we highlighted are real, and that many of them do trace to the fact that OCX development is done in the tools group. She promised to promptly review our concerns with Doug Heinrich and other senior managers at Microsoft.
OTHER
Q. What OCX containers are available tor testing. For which ones is source available?
A. CPatron (source available, but not a production quality sample), Access (no source), VB.4.0 (Beta-no source), Visual FoxPro (no source). Doesn’t know whether Eforms has OCX container. Cairo shell will.
Q. What about Mike Blaszczack’s sample container?
A. Right, that’s coming when the MSJ article is published, but it’s based on MFC OLE support, so you probably have licensing problems with it. Also Kraig Brockschmidt is writing some new white papers on creating
an OLE controls container.
Q. We’ve heard that Microsoft is contemplating support for 32 bit VBX’s after all.
A. I’ve heard nothing about it and I can’t imagine why we would do that.
Lotus: Because VBX vendors are telling you that OCXs are too hard to build and that they have too much overhead.
A. I haven’t heard that and I think I would know about any change in strategy. It’s still: VBX is 16 bit only, OCX is preferred, and on 32 bit, it’s the only option.
Q. Is OCX on the Mac? Will it be? What about other Wise platforms?
A. Don’t know…will check. At best, Wise platforms would lag significantly.
Q. Will the OLE documents extensions previewed last week apply to OLE
Controls.
A. I would think so. (BTW, I’m not sure she’s right about that. Some of the OLE documents extensions are implemented in the OLE default handler, which is not normally used by OLE controls.)
Q. Tell us about OCX futures.
A. There is an improved CDK in the new Visual C-+, just out. Beyond that, can’t say much. A strange situation has arisen within Microsoft according to Sara. Although the Developer Relations Group (DRG) of which she is a part is organizationally affiliated with the Tools Group (i.e. languages, data bases, etc.), DRG actually has a much closer working relationship with the sysems organization See discussion above.
Q. Can we get the VB 4.0 beta? It’s the only useful example of a production quality OCX container wilh scripling.
A. Will check.
The lack of clear OCX documentation is aggravating a problem we’ve had with OLE 2.0 since the beginning: everybody’s doing it differently.
A. Microsoft is working on a validation suite for OLE 2.0 to test interoperability. First wave may see this in the next couple of months. Not clear whether this applies to OCX – I suspect not (NRM).
Lotus: Great, something like this is needed, but please make sure that ISV’s get to comment before the validation suite is frozen. Compatibility checking is important, but let’s make sure you’re not preventing our apps from doing what they need to do.
Q. Do you have more information on apartment model threading in OLE?
A. Apartment model threading will be supported in Win95 and NT 3.5.1. Should be in current win95 builds on ISDN. Fundamentally, each COM object does its work on a single thread. Sara is currently writing a white paper, with sample code. It will (probably) be available within the next 2 weeks or so on the ISDN server.
Q. When will a common .EXE be usable with the OLE .DLLs on NT and Win95
A. Don’t know. Will check.
What are the details of OLE support in the Chicago shell? Why was Lotus told that the shell would not be OLE enabled when In fact it is? Why was Lotus not given earlier warning if there was a change of plan? We’re still lacking useful documentation on OLE in the shell-is there any?
A. Sara didn’t seem to be familiar with the history of this problem, or with any of the details of OLE enabling in the shell.
Q. .DLLs have advantages over .EXE’s in terms of performance and flexibility, but doesn’t the OCX architecture take us back to where we were with Win16 in terms of programs (in this case components) impacting each others’ integrity? Also: isn’t this an incredibly powerful opportunity for those writing Trojan horses, viruses, etc?
All: This question generated quite a length discussion, but Sara didn’t seem to know whether anyone at Microsoft had given this serious consideration, whether there is an official corporate position on the problem, or whether there are any specific efforts planned to minimize the impact. The Lotus attendees expressed a strong concern that these were serious problems. It’s ironic that we’ve waited for robust, secure, 32 bit operating systems as the appropriate environment for OLE, and now we’re tooking at running multiple components within the same process space. (Noah’s observation, not expressed at the meeting: this is why the research community is looking at special purpose operating systems and special purpose hardware to support component based architectures, it’s difficult to get good pertormance with good isolation using convention processors and OS’s.) Noah
More information will be posted if any more is found.
