Why Lotus was told the shell would not be OLE enabled
Date: 1995
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 thal 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
Synopsis
Snippet
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 SupportSara 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 thal 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