I've been asked frequently why I don't use MFC in this book, not only for the basic application framework (for which I use CLASSLIB) but also for the OLE features. In other words, why is this book (including all the samples) focused on working with OLE through the raw API and the raw interfaces? There are a number of reasons. First of all, no OLE-related tool I know, even MFC (the Microsoft Foundation Classes), has direct and explicit support for absolutely every OLE feature that we'll be covering. At the time of writing, MFC is focused on OLE Automation, OLE Documents, and OLE Controls, although as time goes by it will gain additional features. Working in MFC would not allow us to easily explore type information by itself, nor connection points, nor persistent objects, nor monikers, and so on. To study these technologies, we do have to study the raw OLE API and interfaces outside the context of any development tool. In addition, I intend this book to be of use not only to applications programmers but also to those who are interested in creating better OLE tools for the rest of us, and they need the raw information in order to make such tools.
The most important reason, however, is that even when you have a great development framework such as MFC, I strongly believe that you will benefit from at least knowing how OLE works on a mechanism level, as well as how things work on a code level (which is, again, reflected in the chapter organization as described earlier). If you use something like MFC to do OLE development, it helps to understand why you're using this or that part of OLE. This is especially important when something doesn't work, or when the framework doesn't support what you want to do—then you really need to know what's going on not only inside the framework but inside OLE as well. If this book were about MFC-OLE, you'd learn MFC but not much about OLE. You need to learn about OLE to work with it using any tool.
My favorite analogy for this argument is to compare OLE to mathematics and tools such as MFC to a calculator. A calculator makes the acts of calculating mathematical equations a helluva lot easier; it sure beats taking square roots by hand or looking up logarithms and trigonometry functions in tables. But even when you have a calculator, you really have to know why you are using those functions and what those functions do for you so that you know when it is appropriate to apply the calculator to your problem. The relationship between OLE and MFC's OLE support is the same way: know what you're trying to accomplish and what MFC can do for you so that you'll know when to apply MFC intelligently and when you might have occasion to do a little math by hand. Having knowledge of the mathematical principles will greatly increase your ability to exploit your tools.
That said, I will mention that there are an ever-growing number of tools that can help you incorporate OLE technologies into software projects. Microsoft itself offers Visual C++ with MFC, as well as Visual Basic, both of which can help write applications that use components as well as components themselves. Something like MFC, for example, makes technologies such as OLE Documents much easier because OLE Documents technology involves more than just implementing interfaces, and MFC can provide default implementations of almost all of it. Visual C++'s debugger, as another example, offers OLE debugging, by which you can step into an interface function call across a process boundary and easily debug two applications at the same time.
Microsoft is not the only provider of OLE-related tools. Borland has ObjectComponents Framework, or OCF, which simplifies many of the same technologies that MFC simplifies, with better support in some areas, less support in others. Blue Sky Software has an OLE debugging tool. I'm sure there are more, and I encourage you to scout around a little and see what might be of use. If you have an idea of what you'd like to see, let the tool vendors know. I'm sure one of them will see a great opportunity to take advantage of the growing popularity of OLE.