Objects: The "Magic Glue" of Windows

Objects: The “Magic Glue” of Windows®

© by Mike Robinson

I admit that I “had my doubts” when Microsoft was first struggling to perfect the technology that they first called OLE™ ... an acronym that stood for “Object Linking and Embedding.” It was very buggy when it first came out, and it took several iterations to really get it right, but once OLE began to emerge as a truly-stable technology, it was clear to everyone that Microsoft was really on to something very different and very good.

Since that time, OLE has evolved in different ways and it has taken on many different “three-letter acronyms (TLA's).” COM™, DCOM&trade, ActiveX™, and even “dot-NET™” are direct offshoots of the same basic technology and of the same basic idea. The concept has since been ported in compatible ways to other environments, but Microsoft started this ball rolling and they've virtually built their company around it.

In this article, I'd like to present you with a sweeping, high-level overview of this technology and of what it pragmatically means to you ... as the user of such a system; a business executive; or just someone who's trying to develop a better way to get a laborious manual task done much faster. I'm going to simplify things. I'm going to generalize and conceptualize. Those of you who are “really into” these things are going to recognize where the broad-brush has been applied. But I strongly believe that a large forest must first be studied from an airplane: you'll just get lost in there if you try to walk it.

Everything is “an Object” :

Absolutely the place to start is with the recognition that, in this world of computing, everything is an object. An application (like Microsoft Excel®) is an object, but so is an Excel spreadsheet, a workbook page, even a cell or a formula. Every object can be accessed and manipulated separately.

(Keep reading ... I think that the answer to the inevitable question, “what's an object?” will momentarily become quite clear by-context.)

“Objects contain objects contain objects,” just like a set of Chinese Boxes.

There is no explicit need to refer to “an application,” e.g. Excel, as a prerequisite for getting to any object that Excel exposes. (“Excel, itself, is ‘an object’ too,” but you don't have to open it explicitly.) You can simply open a spreadsheet-object and manipulate it, without having to know or to be directly concerned with exactly what application implements it. Windows knows.

Most application environments support these objects in ways that you can see as an end-user. For instance, when you paste a chart into a spreadsheet or into a document, that chart is an object. So is the spreadsheet, and so is the document. (Hence the original term, “object linking and embedding.”) But Windows doesn't rub-your-nose in that; doesn't obligate you to understand all the whys and wherefores of how it's actually happening.

But if you want to, Windows also provides an interface to objects that is designed for use by programming languages: Visual Basic®, of course, but also any other language that is native-to or that has been ported-to the Windows environment. Through a “Swiss Army® Knife” data-type called variant, you can address any object freely. (Microsoft has also made “programming languages” very easy to get to, since every copy of Windows ships with a form of Visual Basic pre-installed, and every component of Microsoft Office® exposes it and uses it.)

So That's What “The Registry” Is For:

Yep, that's what “the Registry” is for. Every Windows system has a rather-enormous built-in database of sorts, called the Registry, which is consulted by Windows itself for nearly every purpose. Among many other things, the Registry is where Windows finds out about object-definitions that exist on, or that are available to, a particular system. (Through the magic of DCOM, or Distributed COM, you can “reach” certain objects that are not hosted directly, or only, “your” machine. And for the most part “it's all the same to you.”)

Not to get too technical here, but in every database system you have a pretty-constant need for “a unique identifier” for everything. Microsoft has a way of producing these guaranteed-unique identifiers, which they call GUIDs. So if you stumble-upon a rather impressively long sequence of letters and digits, especially if you're poking-around in the Registry, those are GUIDs. (You don't have to use GUIDs directly, but you'll sure know one if and when you see one, and “now you know: that's what they are.”)

(It should go without saying, but ... if you do decide to poke-around in the Registry, remember the china-shop rule: look, but don't touch anything.)

After the Registry has been used to locate an object, Windows turns to the object itself to ask it to provide a self-description of what it is and what it can do. An object provides three basic things:

Properties:
Properties are things that you can “look at,” and possibly also change. For example, the “value” of a spreadsheet cell can be examined, and it might also be something that can be modified.
When you change certain properties of an object, this might cause so-called “side effects,” which in this case is a Good Thing. For example, when you change the value of a spreadsheet cell by typing a new value into it, you know that a spreadsheet may respond by recalculating itself. Exactly the same thing will happen when the value property of a spreadsheet-cell object is changed. (As far as the spreadsheet is concerned, either way of “changing the value of a particular cell” is equivalent.)
Methods:
Methods are buttons that can be pushed; commands that can be given. For example, a spreadsheet can be told to recalculate itself. Methods generally correspond to the sort of things you can do when you make a choice from a drop-down menu.
Events:
Events are a mechanism for dealing with “something interesting has just happened.” For example, someone somewhere in the system might want to be informed when a spreadsheet has (for whatever reason) recalculated itself. (It might need to do this, say, to automatically update its own display with the most up-to-date information from that spreadsheet.) The “event” mechanism makes that sort of thing possible.
For instance, when a spreadsheet recalculates itself, it might “broadcast a recalculate event” to anyone who might be listening. Applications (or other objects) who are interested in knowing when that event has happened simply “sign-up to listen.” If no one's listening for the event, it's dropped. Otherwise, the listeners are informed that the event has occurred, so that they can respond to it however they like.
Events are really only of explicit interest to programmers, but many of the “automatic” things that you see happening throughout your system work by means of this mechanism.

An object is self-describing. Through so-called “introspection,” any object can inquire as to exactly what an object is, who made it, what version it is, and what it can do. Beyond that, the precise behavior of each object is more-or-less up to the whims of the vendor that created it, although Microsoft has published many explicit guidelines and will not attach its “seal of approval” to anything that doesn't conform to them.

That “seal of approval” is what's needed to produce a signed, or trusted, object. This signature allows the provenance and integrity of the object to be known to the system, because Windows can determine that a signature exists and that the object to which the signature has been attached has not been tampered-with in any way. Software vendors are of-course very interested in being able to guarantee that their objects have not been tampered-with by some “hacker,” and this is a reliable way for them to do that. (Windows can be programmed not to allow un-signed objects to be installed or used, and many installations choose to enforce that.)

This self-describing characteristic extends, not only to a generic description of a given type of object, but a detailed description of any particular instance, as well. For example, you can programmatically determine every value, formula, cell-range or other useful characteristic of (say...) a particular spreadsheet document or template.

Okay, Enough Tech-Talk ... What Can I Do With This Neat-Stuff?

In a word, this is what allows you to leverage one system component against another. Since “everything is an object,” and since scripting and macro capabilities are available everywhere (yep... Visual Basic® is an object, too), you can cause the system to automatically accomplish what would otherwise be a laborious manual process.

(You don't have to “buy anything extra.” This capacity is built-in.)

Pretty much every application-vendor out there, not just Microsoft, provides an object-interface to its applications. They provide it for external use, and they use it themselves. So, you can pretty much count on that for any application of recent vintage. (If the application you're using dates from the “Windows 9x” days, you might need to upgrade it... or at least, it will be to your very-great advantage to do so.)

For example, let's consider Excel spreadsheets. Many folks use spreadsheets as a data-entry device, since a spreadsheet is a sort of “smart document” that can accept and validate many kinds of input and then calculate other useful bits of information from those inputs. All's well and good... but what happens next?

“What?!?! You're transcribing that data manually?!?!”

Ahem.

Since a spreadsheet is “an object, in an object world,” the information can be extracted from that spreadsheet by a script or program, manipulated in any sort of fashion either by the script itself or by other objects or both, and then fed into the target application automatically. Poof! No more manual process. The same thing is now done at computer speed, with computer accuracy.

These techniques are a classic expression of synergy, where “the whole is much greater than the sum of its parts.” The office computer stops being an overglorified typewriter, and starts becoming a power tool which can do what nothing else can.

It is necessary to put some thought and planning into exactly how you go about doing this, since computers really don't understand ambiguity like humans do. But this is something that can be done fairly easily and quickly, even on a case-by-case “do it quick and get it done” basis. Once you've set it up, it's enormously useful in terms of saving human time-and-effort. The costs are quite moderate, and the return-on-investment is almost instantaneous.