DDJ: Richard, welcome back to TechNetCast.

RHS: Thank you. That's a hell of a line-up you've got there --

DDJ: Yes, we were lucky to get all these first-rate guests…

RHS: I think I'll just skip my classes and watch your stuff instead.

DDJ: Actually, you can get the best of both worlds. Or programs are archived on the website.

Richard is the chair of the ActiveX-COM track here at Software Development '98. You can find out more about his numerous activities on his own Web site, www.richardhaleshaw.com.

We had a program a few weeks back with the Microsoft Visual C++ group. Microsoft. What are your own thoughts on the product?

RHS: Let's see. I'm trying to think if my NDA allows me to talk about an unreleased product, but VC6 looks good. There are definitely some nice things in there for COM developers that I think will make life a lot easier. I think it's been a tough road for both developers like Mike [Blaczszack] and Walter [Sullivan] and those guys at Microsoft for a variety of reasons -- changes [at Microsoft], feedback from the marketplace and --

DDJ: They've had to change their target a bit?

RHS: Well, no… It's been tough for them, being inside Microsoft and how they do things, getting a picture of how software developers actually use their product to create COM objects and COM components. The information they've been looking for, feedback from people in the marketplace, is getting to them and it's paying off and you can start to see that in the product.

RHS: That's probably right. And I am not a language feature guru. I would definitely defer to someone like Dan Saks for that kind of expertise.

Now, of course, we do have a C++ standard. It took a long time. [These] changes [won't be incorporated] overnight. Many compilers probably don't have all the latest features in them. [Also], as we've seen, implementing some of those features ends up breaking a lot of code that people had written based on what was in the working draft. For the majority of Microsoft's developer marketplace my guessis that easier to use, more powerful COM features are a higher priority than [having access to] the most obscure features of the C++ language. This is my personal bias.

DDJ: One interesting aspect of ATL, the Active Template Library, is that it it is built on C++ templates. It seems Microsoft is pushing ATL rather than MFC to build COM components. Would you agree with that?

RHS: Well, no, I wouldn't agree with it. Whenever [Microsoft] has something new, they like to make it visible. ATL is still relatively new. ATL is definitely a really good solution for solving certain types of COM problems, but it is not the only way to do it and it's a mistake to think that people are going to suddenly abandon years of MFC programming expertise in order to rewrite everything in ATL. It is more likely that they will start viewing new projects with ATL in mind, and see if they can solve problems with it.

DDJ: But there is a real overlap between MFC and ATL.

RHS: Well, the two work very well together. You can use them together. Or, when appropriate, you can use one or the other. You really have to sit down and carefully evaluate the needs of the component you're building [and determine] which one you're going to use. You could easily start out with one and switch to the other for a variety of reasons. Try writing a full-scale ActiveX control in ATL. It's a considerable amount of work that may not be worth it if you've got a close deadline.

On the other hand, if you need a control that's really, really small and can be instantiated very, very fast and transmitted through the wire very quickly because it's small, ATL is a better solution. Both MFC and ATL have strengths and weaknesses. [Microsoft] may be just pushing ATL more right now because it still has new stuff. They may not have mentioned it, but the footprint for MFC components has gone down considerably in this release, so the two are growing closer --

DDJ: They're trying to make MFC more granular.

RHS: Absolutely.

DDJ: There's also an overlap between MFC and the Standard Template Library, STL, when it comes to containers. For example, the STL includes map classes. MFC offers similar functionality. An argument can be made to move the MFC classes into legacy, deprecated modules.

RHS: It's a tough call. The one good thing about the collection classes in MFC is that they really are fairly well designed for Windows programming needs. Until developers really understand some of the concepts behind STL better, a lot of the STL classes seem terribly difficult to use. As developers understand certain aspects of the C++ language that they may never have been educated in, STL becomes a lot easier to grasp. So over time we might see a greater use of STL components in. But using the built-in MFC collection classes makes more sense, at least in the short run.

DDJ: Microsoft is not a language-centric company. They're not pushing a particular language. You can build COM components in C++ or Java or Visual Basic, and they'll make that easy for you to do that.

RHS: I should add that, in fact, this is not just limited to Microsoft languages. Delphi, Borland, C++ and PowerBuilder all address COM. That's part of the beauty of COM. It is language- and vendor- neutral.

DDJ: I notice that your own classes this week are oriented towards C++. What

RHS: That's a good question. I think the criteria still end up being the same ones that we use in developing any application or component: how much control and flexibility do we need? Can we give up that control and flexibility in order to have ease of use? That's kind of the continuum we work on. I think there are two reasons why developers have been attracted to using C++ for COM development. One, [C++] was the original COM development language, and two, [users] still want a lot of that flexibility and control. On the other hand, there are some people doing some wonderful work with Visual Basic and COM, and I actually am teaching a Java COM class here as well, because I think that's a marvelous intermediate step. You don't have as much flexibility and control as C++, but it's more high level, like Visual Basic, and of course it has Web characteristics you just couldn't get with either of the other two languages.

DDJ: Are there times when Java or VB are not appropriate because of performance overhead?

RHS: There are many different reasons to consider. Users may chose C++ over [VB or Java] two for performance purposes, but it also depends on how the components can be used and where they will be used. A component will not get a lot of processing or throughput, a front end, for example, doesn't have to necessarily be fast. That's where Java and VB are will definitely have an upper hand over C++.

I think you have to evaluate what kind of component you're building. What is nice is that you can sit down and break an application up into lots of distinct modules, use languages that best solves those problems, and use COM to wire it together. And that's where it's really sweet.

DDJ: And design decisions can also affect performance. There are ways, for example, to instantiate server-based COM object and leave them loaded so that the performance hit associated with this instantiation is not repeated every time. These design decisions may in some cases have a greater impact on performance than the choice of the language.

RHS: That's true. There are a lot of very creative things you can do in terms of load balancing and stressing the server. Microsoft Transaction Server (MTS) is a product that addresses a lot of those things for COM developers. It's a misnamed application. The word "transaction" makes everybody think it's strictly a transaction processor, and that's just kind of a tiny piece of what it does. It's a whole new COM development environment. It addresses issues like scalability and performance issues, in addition to its transactions abilities. When using Com as the connecting glue, developers or architects have a lot of options in how they can put together and design components.

DDJ: Let's talk a bit about COM on non-Windows platforms. COM is a protocol, so conceivably it could be implemented on any platform. The problem, of course, is that the plumbing to make this happen, the implementation, is fairly complex.

Where are we with cross-platform COM right now?

RHS: The last time I checked there was COM support for Solaris from both Software AG and MainSoft. I think Christian [Gross] can tell you about his experiences with the Main Soft product, because I think he's had hands-on experience with it. Also, Hewlett-Packard has a version already available for HP Unix. I was on the Compact Digital Web site the other day, and the Digital VMS version of DCOM is in some kind of beta. They did not have a release date on the site, but I have heard that it'll probably be out this year. There's more coming. And the Macintosh support for COM has been there for some time. That's from Microsoft.

DDJ: What type of compatibility are we talking about? Is there a defined, minimum set of functionality that must be implemented on every platform?

RHS: Yeah. There are core services. The COM spec specifies exactly what has to be available on each platform. These core services are all there in each case. There are some cases where certain tools are not available, for a variety of reasons. I've heard that ATL is available on the Solaris implementation. That's pretty easy because it's all straight C++ templates. MFC is not necessarily available because you need something like the Windows API to implement MFC.

But the core services are all there, in any case, and that's the main point. To some degree it would not be very difficult to port any COM application to another platform or to build COM components on those platforms to communicate with, say, COM components running on NT or 95 or 98, et cetera.

DDJ: You work with COM programmers every day. What are the most complex features of COM that programmers have a harder time handling? What do they complain about most?

RHS: Well, really, it's not so much what they complain about although if you're going to list complaints you could go down and say the tools could still get easier --and that includes even the newer tools from Microsoft, there's still room for them to improve the process. And I think that will happen. What developers have to really grasp about COM is the whole essence of de-coupling interface from implementation. That is what COM is really all about that and it has far-reaching implications for architects and designers.

DDJ: COM is a protocol.

RHS: It's a whole way of thinking about designing components that we really haven't had the option of doing before. With object-oriented programming we always thought about types and objects, and object inheritance, but this is a way of saying that the implementation of the type is entirely separate from its interface. A tremendous number of options open up when you begin to understand what you can do with that. Developers need to really grasp that better, and tools vendors need to grasp that. Tools vendors, and I'm not talking just about Microsoft, -- really could go back and ask the COM team, "What is COM about," because I don't think they always understand exactly how developers build COM components.

DDJ: Will these themes be a part of your session tomorrow, "The Philosophy and Zen of COM"?

RHS: Absolutely. That material is a subset of a five-day training seminar that I'm doing with Software Development called Boot Camp. You can read about it on my Web site or on Software Development's Web site. The whole idea behind the philosophy or zen of COM is understanding these essential concepts, how to decouple interface from implementation, and using thin layers of abstraction in a variety of ways in building components.

DDJ: Approaching COM from a conceptual standpoint.

RHS: And taking the look at some of the underpinnings that make those things work so that they don't seem so mysterious. These things have been pretty well tested and implemented and users can rely on them and start deploying components with them today.

DDJ: Okay, Richard, thank you very much for talking to us today. Can you tell us a bit about your upcoming activities? What are you up to?

RHS: I'll be on this tour with Software Development Boot Camp this fall. You can read about in on the SD Web site or my Web site. I'll also be at the Visual C++ conference in November.

DDJ: Richard, thank you very much. Richard's Web site is at www.richardhaleshaw.com.