Many fellow Windows programmers will have gathered that COM will not be coming with us into the C-Sharped world of .NET. Of course, COM will have a longish half-life of decay. COM objects will be supported in .NET — just as 16-bit programs are supported under 32-bit Windows. Technically permissible, but one is not encouraged to mix very much in public.
Before COM is scuppered and allowed to sink below the waves, and we hurl our considerable library of books — each volume about two inches thick, each with a price tag of considerable heft — into the seething waters after it, it seemed meet and proper that we spend a few moments contemplating the about-to-depart, and savor its hard-learned idiosyncrasies one last time.
The following is mostly written from the point of view of Visual C++, for this was the tool of choice when creating a COM object. But it was a cross-language technology, so the Visual Basic, Delphi and scripting language perspectives are covered too.
CoInitialize. The call that had to precede all other COM calls:
HRESULT CoInitialize( LPVOID pvReserved //Reserved; must be NULL );
Alas. I suppose we will never learn now what pvReserved was reserved for. Weep a tiny tear. (Anybody who is tempted to mutter "Tiers, IDL tiers" at this point, please don't. You'll get such a smack.)
CoInitialize(), you will recall, had to be called "once and only once". They were very particular about this. Calling it exactly zero times was rewarded with that most annoying of errors "You have not called CoInitialize" — annoying because, having made so complete a diagnosis, one might have thought the underlying library could have put matters right by itself. (Yes, I am aware of CoInitializeEx(), but feel that multi-threaders could reasonably have been prevailed upon to make their own initialization arrangements.)
What do you want to call me today?TM A quick quiz. Given that "OLE documents" were renamed "Active Documents," and "OLE Controls" renamed "ActiveX Controls," explain why "OLE Automation" was not renamed "Active[X] Automation." Show your working.
About Automation. I for one still feel a thrill of excitement and surprise when Word does what I asked it to, often followed by a second thrill, of a different kind, when it abruptly stops doing so. For a long time the big problem with Automation, in my opinion, was the lack of robust and realistic examples showing what it could do — especially where Outlook was concerned. Happily this shortcoming has in recent times been addressed, and addressed in spades. Of all the script viruses, "I Love You" is still my preferred source of useful snippets for manipulating the Outlook address book, even if its author does insist on spelling mail "male." By the way, ILY also contains some good stuff demonstrating the VB file system object — I would lobby for its inclusion in MSDN, but I suppose it is too late now.
Strung up. Once upon a time there were three special COM string types: BSTR, _bstr_t and CComBSTR. BSTR was the most straightforward: It was a typedef for a pointer to a wchar_t, and wchar_t was a typedef of a 16-bit Unicode character. Therefore BSTR was the Unicode equivalent of LPSTR.
Ha! Got you going there. BSTR was no simple zero-terminated string; rather it had a secret length count and extra null terminator, and was allocated and freed with special functions. One was not supposed to know the format of its contents, and it was not obvious how you were supposed to make conversions to proper strings. I think you were expected to use the spooky old ANSI C function wcstombs(), or the misleadingly named WideCharToMultiByte(), but this seemed to break the "make no assumptions about content" rule.
But why manipulate BSTRs as pointers? Surely this was a job for a class? (Ok, so COM interfaces always needed pure BSTRs, but bear with me.) The answer was "Yes, of course it was a natural for a class," which was why two were supplied. "A _bstr_t object," said MSDN on its _bstr_t page, "encapsulates the BSTR data type," whereas the entry for CComBSTR began "the CComBSTR class is a wrapper for BSTRs." Nothing in either entry to indicate which class should be preferred.
And this ignores Bruce McKinney's MSDN-bundled (and therefore officially sanctioned) 1996 article "Strings the OLE Way," where he proposed a BSTR wrapping class of his own called, ermm, String. That's clear then…
Variants, or "What do you mean you weren't expecting a three dimensional array of Nulls, Mother?" Variants were Visual Basic creatures, really; they went hand-in-surgical-glove with the convenient ability to call a variable into existence without previously bothering to declare it. The housekeeping required to manipulate them in a language that didn't "understand" them, by which I mean C++, was frightful. Although at least you were aware of the reams of domestic code you were generating when you needed to create and initialize, say, an array of BSTR, and would thus be careful to avoid gratuitously including it in tight loops.
However, whether you used them from C++, or from a variant-sympathetic environment such as VB or Delphi or a script, you could be confident of one thing: sooner or later you'd get a runtime type error biting your ankles.
Inheritance, "interface" and "functional." Do you remember being told that not having functional inheritance, which was so frightfully dangerous, was an advantage of COM? Me too.
Strength through joy. "The Active Template Library Makes Building Compact COM Objects a Joy" — the actual title of an MSJ article. You can still read this piece on MSDN if you want to check up on me. If the author was being facetious when he chose this title, I can only say that he conceals it very well. The article begins: "I love COM. COM is good. Like a fine pilsner or ale, COM never disappoints. In fact, the more I look at COM, the more I like it." Right-ho.
IDL. As an eschewer of Java, I had accepted that I must type in the first line of my functions twice. With IDL I got to do it a third time. I could have used the Visual C++ wizard, of course — if I had been confident of completing the fields in its modal dialog letter-perfect without access to the rest of my code.
Everything else. To include: The header file of an ATL class, with its abundant macros and multiple template inheritance — what a mess! Passing exceptions across the COM boundary, the inability to do so. Rebodged (sic) interfaces with names ending in "2." The registry, the installation procedure, the flock of standard DLLs and EXEs and small thunderstorm apparently necessary to breathe life into a COM object when first installed on a punter's system. GUIDs. The palaver that had to be endured to set up a callback from a COM object. Ditto to enumerate a collection. Reference-counted objects that, if one wasn't careful, lived forever like the kids from Fame — notwithstanding the desirability of their mortality. DCOM security, or "I can sometimes make it work if I log on everywhere as Admin and start a copy of the EXE on the remote."
Dear COM, boy am I going to miss you.
