Master's thesis related to Visual Basic -- comments solicited
Polberger@discussions.microsoft.com David Polberger
I am writing my master's thesis on software components, and I include a short
section on Visual Basic. (A software components is, per the definition I use
and in the context of non-.NET versions of Visual Basic, a VBX/OCX/ActiveX
library.) I'd appreciate if members of this newsgroup would be kind enough to
review my Visual Basic material, and let me know if any errors have crept in.
(Please let me know if there is a more appropriate forum, newsgroup or
mailing list for my request.)
The short section on Visual Basic is available at this address:
http://www.polberger.se/components/read/visual-basic.html
My thesis is primarily a paper document, and a PDF version (in which the
Visual Basic material may be found on page 76) is available at this address:
http://www.polberger.se/components/thesis.pdf
The main site is at this address:
http://www.polberger.se/components/
You are welcome not to restrict your comments to the Visual Basic section. I
also discuss software components in general, develop an object model in C,
sketch a COM-like component model and discuss enterprise services. In
addition to Visual Basic, I also cover COM, Delphi, CORBA, OSGi and Java as
well as .NET. The final revision of my thesis will be licensed under a
Creative Commons license (enabling people to share my thesis freely, as long
as no modifications are made, and it's done on a non-commercial basis).
Thanks for your time,
--
David Polberger
Master's student at Lund University, Department of Computer Science
Ralph
> I am writing my master's thesis on software components, and I include
> a short section on Visual Basic. (A software components is, per the
> definition I use and in the context of non-.NET versions of Visual
> Basic, a VBX/OCX/ActiveX library.) I'd appreciate if members of this
> newsgroup would be kind enough to review my Visual Basic material,
> and let me know if any errors have crept in. (Please let me know if
> there is a more appropriate forum, newsgroup or mailing list for my
> request.)
>
It is not so much a case of "errors" as more a general misrepresentation of
the role Visual Basic played in the development and evolution of Windows
Object technologies. Partly based on the fact that you, and most of the
authors cited, tend to confuse the evolution of Windows' inter-process
communication technologies with object technologies. This is easily done and
is a common mistake as both are tightly intertwined.
It is also confusing because these technologies evolved from what
essentially were hacks, coding tricks, or even what some would call
"abuses", to achieve a particular goal, that later were incorporated into
more formal implementations and protocols.
Visual Basic was less the creator of new technologies and more an early
adaptor, and in that it became the supreme showcase for the possible.
Minor nit-picks: <g>
"The first versions of Visual Basic used a comparatively slow interpreter."
Compared to what? Instant C? A natively compiled C/SDK application?
"A VBX file was a 16-bit Windows shared library (a Dynamic-Link Library, or
DLL) which used a Visual Basic-specific application programming interface to
communicate with its host, and was expected to export a well-defined set of
symbols specific to Visual Basic."
A VBX was far less "Visual Basic-specific" than generally supposed. The same
technology could be used with any Windows product (and was). But the VBX did
address two major problems with early object-sharing - adoption of a common
transport (in this case DDE), and of common datatypes (in this case VB
datatypes). Other transport mechanisms and datatype definitions were viable,
but it made sense if one was going to go to the bother of creating an
'external' object why not create one that could be used in Visual Basic as
well.
"Despite the lack of a formal specification for Visual Basic components,
several vendors created competing products that could act as their hosts (by
essentially reverse-engineering Microsoft's product)"
"Reverse-engineering" is misleading as the technology involved, principally
"Dynamic Data Exchange" and early "Object Linking and Embedding", were
published and well-known. Again Visual Basic wasn't necessary unique, it
merely provided a de facto "standard".
Your second to the last paragraph simply needs to be scrapped.
1) There were 32-bit VBXs. VBX depended on DDE as transport.
2) What characterized OCXs was the shift from DDE/OLE1 to OLE2 as the
transport mechanism. Again the transport mechanism is not the Object
technology itself.
3) "COM" is a protocol. "ActiveX" is a marketing term to define any
component that provides a COM interface. It is not a variation.
4) "OLE" is MS's implementation of COM.
5) "OLE Datatypes" were formalized. (Which bared a suspicious resemblance to
VB datatypes - after all you have to pick something and VB was shipping
while other competing technologies were still on the shelf.)
In other words, your getting your terminology all confused.
Any discussion concerning the evolution of a Microsoft Component Model would
be remiss if it neglected to mention the importance of Visual Basic, as
Visual Basic through it many 'upgrades' provides insight into MS's evolution
of an "Component Object Model", but it was not "VB" technology that was
driving the advancement, it was the technology that was driving the VB
upgrades.
-ralph
David Polberger
Thanks for your comments.
"Ralph" wrote:
> It is not so much a case of "errors" as more a general misrepresentation of
> the role Visual Basic played in the development and evolution of Windows
> Object technologies. Partly based on the fact that you, and most of the
> authors cited, tend to confuse the evolution of Windows' inter-process
> communication technologies with object technologies. This is easily done and
> is a common mistake as both are tightly intertwined.
If there are other passages that you find misrepresent Visual Basic's role,
other than the ones you have enumerated below, please list them as well.
> "The first versions of Visual Basic used a comparatively slow interpreter."
> Compared to what? Instant C? A natively compiled C/SDK application?
Compared to native code produced by a traditional optimizing compiler. I'll
clarify the text.
> "Reverse-engineering" is misleading as the technology involved, principally
> "Dynamic Data Exchange" and early "Object Linking and Embedding", were
> published and well-known. Again Visual Basic wasn't necessary unique, it
> merely provided a de facto "standard".
While I don't dispute that published standards were involved, one of the
sources I cite does indicate that hosting VBX controls was quite involved
(refer to my Udell 1994 reference): "In the realm of Windows 3.x, VBXes are
further restricted to Visual Basic and a small number of other development
tools, including Microsoft's and Borland's C++ compilers, Powersoft's
PowerBuilder, and Gupta's SQLWindows. These tools jump through hoops to
emulate the Visual Basic run-time environment--with varying degrees of
success. 'Hosting VBXes was not the most pleasant engineering task we've
undertaken," says Bill Rabkin, senior technical evangelist with Powersoft
(Burlington, MA), "and we got no cooperation from Microsoft.'" Standards are
problematic, even if well-specified, as products are usually written to (and
tested with) a concrete implementation, in this case Visual Basic.
> Your second to the last paragraph simply needs to be scrapped.
I assume you mean my last paragraph.
> 1) There were 32-bit VBXs. VBX depended on DDE as transport.
Did Visual Basic 4.0 support VBX components for 32-bit targets? If that's
the case, I'll revise the text accordingly.
> 2) What characterized OCXs was the shift from DDE/OLE1 to OLE2 as the
> transport mechanism. Again the transport mechanism is not the Object
> technology itself.
Right. I don't think that my text contradicts that (indeed, my COM section
expands on the OLE heritage).
> 3) "COM" is a protocol. "ActiveX" is a marketing term to define any
> component that provides a COM interface. It is not a variation.
I did not state that ActiveX was a variation of COM, I stated that ActiveX
controls were a variation of OLE controls. My understanding is that ActiveX
controls are required to implement far fewer interfaces than OLE controls
(see page 352 of my Szyperski 2003 reference).
> 4) "OLE" is MS's implementation of COM.
Tony Williams, who is billed as one of the co-inventors of COM, talks at
some length about this subject in a 2006 interview:
http://channel9.msdn.com/shows/Behind+The+Code/Tony-Williams-Co-inventor-of-COM/
He seems to indicate that COM was envisioned as the domain-neutral plumbing
later, whereas OLE (2.0) was a domain-specific layer on top of COM,
consisting of a large number of interfaces.
/David
mayayana
>
> Tony Williams, who is billed as one of the co-inventors of COM, talks at
> some length about this subject in a 2006 interview:
>
>
http://channel9.msdn.com/shows/Behind+The+Code/Tony-Williams-Co-inventor-of-
COM/
>
> He seems to indicate that COM was envisioned as the domain-neutral
plumbing
> later, whereas OLE (2.0) was a domain-specific layer on top of COM,
> consisting of a large number of interfaces.
>
According to David S. Platt in The Essence
of COM, "OLE is a collection of higher-level functionality,
primarily related to the user interface, that uses COM for
communicating bewtween components."
He then goes on with a self-consciously cranky
rant (p. 2) detailing how COM and OLE have been
used in various ways over time, confusing everybody.
Then he attacks "ActiveX", explaining that it "has no
technical meaning whatsoever".
I suppose that's all to be expected with a company
that makes no clear distinction between marketing
pep talks and technical data.