ActiveX is a Windows based component technology created by Microsoft. It is based on COM which in turn evolved from OLE, a protocol for sharing information between desktop apps. With the advent of Java Microsoft rapidly repositioned ActiveX as a technology for the creation of Applets embeddable in Web pages. Recent events combined with minimal uptake have led many to declare ActiveX as dead as Microsoft Bob.

This led to a /msg from Wertperch, saying "All very well and good, old chap, but would you kindly mind explaining what in the hell it is?"

Or words to that effect.

A fair enough request. As a former developer of C++ class libraries and components for Visual C++, I think I'm at least minimally qualified to give it a try. Back to my reference library I went to refresh the old memory.

In which I found a ton of material on COM, but nothing of any significance on ActiveX.

Nothing in the way of a satisfying answer was to be found online, either, at least from a cursory search.

Slowly the memory began to come back. You see, ActiveX is one of those infuriatingly vague terms coined by Microsoft's marketing drones, to cover a concept, product, or technology. Someone defines it, later it's re-defined, then the marketing drones use it indiscriminately without any fastidious care about what it's supposed to mean. After awhile you can get NO explicit definition. Meanwhile, people bandy it about, everybody thinking they know what it means, and quite possibly no two people have the same thing in mind. So emblamatic of Microsoft.

Currently, of course, Microsoft is pushing their .Net technology with all their might. ActiveX is, therefore, no longer the flavor of the month. It is, as they so charmingly say, "deprecated."

So to explain what ActiveX is, I'll have to fall back on my own working definition. I make no warranty as to whether or not any Microsoft authority would agree.

All right. So I'll define ActiveX as:

....a COM component that implements certain User Interface functionality that a designer wants to distribute as a package. (Think of a button, a textbox, or any other little piece of UI functionality up to and including a FLASH viewer.) In addition, this COM component must support certain well-known binary interfaces that will allow it to:

- Integrate itself into the Visual Studio and/or Visual Basic design environment. It must play nicely with object browsers, which give the developer a capsule definition of the methods, properties, and events supported by the given ActiveX component.

- Expose properties, methods, and events in a way that will allow the component to be scripted, most typically by VBScript.

- Be dropped into a web page and referred to by a long identifying number called a guid, which stands for Globally Unique IDentifier. This is the key to an ActiveX component's dynamic download/install behaviour over the web.

The component's developer, when compiling the component, will use a Microsoft supplied utility program to generate the guid, which is supposed to be drawn from a large enough domain as to be statistically guaranteed to be unique. According to Microsoft's own literature, you should be able to generate 1000 guid's a second for thousands of years before having any appreciable probability of generating a duplicate. In practice, guid's typically include specific data from things like your Ethernet card's MAC address.

(A fascinating aside...several years ago a fairly sizeable firestorm arose when it came to light that Microsoft Word automatically generated and embedded guid's in saved documents. Since these can include numbers from your Ethernet MAC address, in principle you could work out which specific machine was used to create the document! Privacy advocates, and paranoids, quite naturally went apeshit.)

..Anyway, the guid will identify that version of the component, and will be embedded into the source of a web page, along with a URL where the binary executable piece of the compiled component may be downloaded. When the end-user surfs to that page, his Internet Explorer browser will detect the embedded ActiveX component guid, and use it to do a registry database lookup to see if that component has already been downloaded.

If so, it can skip the download phase and launch the component from where it is already installed on his or her system.

Okay. If you're still with me you've noticed that I've begged a major question when I said that an ActiveX component was a COM component. So I need to define what that is, now.

COM, aka the Component Object Model, is a huge topic which has inspired entire shelves of books. I have a half-dozen of them on my own shelf. So it's easily worth at least its own writeup, which I intend to do later. But it needs at least a capsule description here:

COM is a software architecture under which software may be developed, distributed, and used as binary components. Under this architecture, the implementation of a function, in the form of the binary instructions the CPU actually executes, will be separated from the interface, which is the binary description of that function that the function's caller will bind to and call.

So basically the interface, a description of the functions and properties of a software component (supported by a descripiton of the data types of all function parameters, return values, and so forth), will be coded with it's own definition language, IDL. Then it will be compiled and given in binary form to the developers of the client program that will use the component. The actual implementation will be developed separately.

It's therefore a black box type of situation...implementation details are hidden from the user of the component. This is a difference from the classic C++ idiom of inheritance...because the user of a class, deriving from a base class, is not prevented from designing in some obscure dependency on some implementation detail. If that implementation ever changes, the whole system breaks. Under COM, that sort of bug is prevented. It's also a very nice way for Microsoft to turn a defect, aka Visual Basic 6.0's lack of support for inheritance, into a feature that can be advertised!

Under COM, interfaces must be immutable. Implemenation can change, as long as it supports the same interface. This gives you SOME chance of fixing a bug or doing an update without breaking your existing, installed clients.

The rest of COM consists of the various supporting system dll's used by Windows to link up the client program with the Com component. Dll's must be loaded. References and pointers must be resolved. Then, at runtime, when a client program (think a VB program or an ASP page) actually makes a method call on the COM component, the parameters must be marshalled, or transmitted, to the component. The method implementation must be executed. The return parameters must be transmitted back.

The slick part of COM, in my opinion, is that this mechanism can be set up so that the com component runs in the client process, runs out of the client process but on the same machine, or on a completely different machine elsewhere on the network (this is where COM becomes DCOM), and this is completely transparent to the client program's developer!

...Which is often a good thing, if that developer is a junior VB developer...

-----------------------------------------

Okay, now some references.

Inside Com, by Dale Rogerson. Microsoft Press, 1997. isbn 1-57231-349-8

Essential Com by Don Box. Addison Wesley, 1998. isbn 0-201-63446-5