By Martin Heller

YOU'VE SEEN INFORMATION overload in others: the unfocused gaze, the slack jaw, the tense fidgeting. I saw a lot of it at Microsoft's recent Internet Professional Developers Conference in San Francisco-and, for that matter, probably expressed it myself more than I would have liked. But I also saw plenty of people who were getting the message, despite all the sales pitch and the hype.

The story is that Windows and the Internet are converging. Of course, that's a self-serving opinion when it comes from Microsoft. My cynical side is convinced that Microsoft is attempting to co-opt the Internet. But my sympathetic side believes Microsoft is trying to embrace the Net. No matter how you view it, it makes sense-Windows and Microsoft need to grow and adapt in order to survive.

The details are a bit harder to follow because they're steeped in hype and described with new, unnecessary terminology. We hear about the Active Wave and ActiveX. What in the World Wide Web are they?

You know that symbol that represents the artist formerly known as Prince? Think of ActiveX Controls as the technology formerly known as OLE Controls (and, before that, as OCX Controls). Think of ActiveX Scripting as the formerly unfulfilled promise of a universal macro language that includes VBScript, JavaScript and any other scripting language you care to include. Think of ActiveX Documents as the technology formerly known as OLE Document Objects.

As I listened to the Microsoft techies try to explain all this, the first thing that struck me was how many little pieces they cobbled together and trimmed to fit the ActiveX puzzle. But as they continued their explanation, I realized I was hearing about a kind of symmetry, about pieces you can use anywhere in the puzzle and connect to any other piece of the puzzle. In fact, ActiveX is more like Tinkertoys or Lincoln Logs than a jigsaw puzzle.

ActiveX Controls are the objects and ActiveX Scripting is the glue, but scripts can cross-dress as objects and objects can invoke scripts. These scripts can run on the client or the server, and they can generate formatted pages that can run other scripts. It's a weird, confusing scene for the uninitiated, yet it's also a powerful scenario for those developers who get the picture.

Implementing an OLE Automation object is easy in Visual C++ if you use MFC (Microsoft Foundation Class) and the Class Wizard. Easy, yes, but there's a catch. OLE Controls and OLE Automation objects have been around awhile for applications and documents that reside on the user's machine or LAN. What has changed in the transition to ActiveX Controls is the environment: The user may need to download the control from the Internet, using whatever bandwidth the browsing connection and the Web server's Internet tap can provide. If the user has a 14.4Kb-per-second PPP connection or the server is heavily loaded, the control had better be small or the user will give up in disgust.

The catch is that MFC-based controls can't be small. For starters, they rely on dynamically linking to an MFC runtime DLL to keep their private size down. Right now, MFC40.DLL masses almost 1MB. Nobody in his or her right mind would download 1MB at 14.4Kbps unless they really, really need to.

Okay, you say, let's rely on the MFC DLL to ship with the operating system. Great. Microsoft already does that with Windows 95, so what's the problem? MFC changes every three months, so you can't assume the version resident on the user's system is current. You can do some version checking, but anytime you run into an older version you'll have two problems: downloading the new version and replacing the old version, which is likely to be in use by something already running on the user's system. Ouch.

Microsoft acknowledges the MFC-based control size problem and has a mandate to fix it, but this will take some time. Meanwhile, I direct you to the Samples\BaseCtl branch of the Internet SDK directory tree. Controls based on this sample, which uses non-MFC C++ classes, can be fully functional with only 30KB of footprint. The good news about the base control is it exists and it's an example you can use. The bad news: You'll have to learn quite a bit about COM and OLE to use it. That's okay, I guess-not everybody needs to write controls.

If you do need to write controls, learn about dual interfaces. As I mentioned earlier, an OLE Automation object can expose an IDispatch interface, which is a general form of late (runtime) binding. OLE Automation objects can also expose a VTBL interface, which is a more efficient early (compile-time) binding mechanism. Dual interface OLE Automation objects expose both IDispatch and VTBL interfaces. The general dual interface implementation scheme for us lazy programmers is to delegate as much as possible. If you're writing an MFC automation object with dual interfaces, you can have the dual interfaces call the MFC implementation of IDispatch. If you're not using MFC, you can implement most of the IDispatch side by invoking the methods through the VTBL.

Because both MsHtml and the IExplorer Browser are COM objects, you can use either in your applications. IExplorer Browser exposes two dual interfaces-IShellExplorer and IInternetExplorer. Both interfaces contain methods such as Open, Close, GoBack, GoForward, GoSearch, Navigate and Refresh-the high-level commands in a browser-as well as lower-level commands that reference a document and its contents. IExplorer Browser can host any OLE Document Object, not just MsHtml. It also supports hyperlinking to any document type, not just those HTML supports.

MsHtml, on the other hand, exposes only the lower level: the document, the window, forms within a document, HTML controls within a form, anchors and links within a document, and so on. MsHtml isn't a container, and only supports HTML hyperlinking. Yet some applications don't need those capabilities and could benefit from a reduced-memory footprint.

You can also drop down to more basic objects if all you really want to do is download things from the Internet. As I mentioned in my May column, the Win32 Internet API, or WinInet (also known as Sweeper), makes reading http, ftp and gopher files on the Internet about as easy as reading files locally. If you like COM, though, you can use URL (Universal Resource Locator) monikers, which bind COM monikers to Internet URLs and retrieve them asynchronously, to accomplish much the same thing with less code and less system dependence.

If you're still not convinced they're worth the trouble, an even more compelling reason to use COM interfaces is on the horizon: distributed COM (DCOM), the technology formerly known as Networked OLE. That's right, Microsoft will finally deliver the magic plumbing that will enable all COM interfaces to work across all networking protocols, and transform the underlying "lightweight" RPCs (remote procedure calls) of today's COM and OLE to true RPCs.

What does DCOM mean to you? It means all your existing 32-bit applications that use COM no longer have to run on the same computer as their COM services. The remote COM server may be elsewhere on your LAN, or anywhere in the world connected to the Internet. You're practically guaranteed your application will work with DCOM if it was built with VB 4.0 or MFC with OLE support.

Both ActiveX Documents and ActiveX Controls can be DCOM clients. An ActiveX Document can contain a reference to a remote COM object that users can access over the Net, and an ActiveX Control can bind to a URL moniker that retrieves a reference to the remote COM object. Either way, the COM object resides on a remote server machine.

The client/server world just got a whole lot more power-and a whole lot more complexity. I, for one, am getting just a bit overloaded.