PREFACE

Someone once said that authors write books not to be understood but so that they themselves understand. Certainly, writing the first edition of this book, Inside OLE 2, and now the second edition, Inside OLE, has been such an experience for me. It is my sincere hope, of course, that most of my understanding will also make its way into your mind and that you will find innovative ways to exploit the various OLE technologies while having loads of fun in the process.

I started working with OLE 2 in the middle of 1992. From the perspective of my job in Microsoft's Developer Relations Group, I understood the technology as merely a way to create applications that support compound documents. After all, I'd spent the previous year in the same job trying to spread the gospel about OLE version 1, which had no other purpose than the creation and management of compound documents. Because of the legacy of OLE 1, nearly everyone inside and outside Microsoft accepted OLE 2 as a refinement of OLE 1; in fact, the OLE 2 design specifications were organized around compound documents. But for some reason, the specification weighed in at more than 300 pages. There had to be something more.

For months, I plodded through prerelease information about OLE 2 in order to create some sample applications for demonstrating compound documents. With the help of various members of the OLE development team, I gave a number of classes to help others use OLE 2 to create compound document applications. In the back of my mind, however, something still told me that OLE 2 had much more than I had originally perceived. But it was hard to stop equating OLE 2 with compound documents because every available piece of documentation used the two terms synonymously.

During the first weeks of 1993, I started to see that in the process of solving the most important problems in OLE 1, the OLE 2 architects had actually created a much larger system for object-based programming. They had created an extensible technology that also solved the fundamental problems of releasing different versions of software. They had made some key innovations to the fundamental notions of objects. The problem was that the architects didn't tell anyone about these things directly—or maybe I never asked. It's taken me two editions of this book to feel that I really understand what they knew all along.

In any case, I began to see that OLE involves technologies that are quite separate from the areas specific to compound documents. In fact, I started to see exactly how one might use those other technologies without coming into contact with compound documents at all. While I'd been under the impression that OLE 2 was a set of performance improvements to OLE 1, I wasn't aware that OLE 2 was designed from the beginning to be an extensible service architecture—and a very elegant architecture at that. I was slowly beginning to discover OLE's full design, helped by my position at Microsoft, which allowed me to explore OLE in depth and even to browse the sources—letting me truly get "inside OLE."

One Sunday afternoon in mid-January 1993, while doing something totally unrelated to work, I achieved stage one of what Eric Maffei (editor of Microsoft Systems Journal) describes as "OLE nirvana." Everything fell into place. I saw clearly, after six months of mental fog (clouded further by the poor documentation that was available at the time), how you could exploit small pieces of OLE in incremental steps. I understood that OLE was a collection of technologies that built on one another and that the best way for me to communicate the entire vision of OLE was to write a book. I quickly fired up my notebook computer and spent the next three hours pounding out the outline. The result was the first edition of this book, published in November 1993.

The worst part about writing a book is that as soon as you get a printed copy in your hands you start finding words and phrases that you want to change. As time goes on, you begin to wish that you had written this or that section differently. With the understanding you've obtained through writing the book, you begin to have new ideas about the subject matter and about new areas you'd like to explore. In my case, I knew I needed eventually to include material about OLE Automation as well as the newest kid on the block, OLE Controls. I wanted to strengthen the earlier chapters by thoroughly discussing object-oriented principles and the important innovations to those principles that are unique to OLE. I also realized that despite my original intentions, the first edition was still mostly oriented toward compound documents. Certain topics, such as monikers, were buried in compound document chapters but deserved chapters of their own. Also, the first edition's sample code was chiefly related to 16-bit operating systems, and I needed to modify it all for 32-bit systems. A second edition was called for.

What clinched my motivation to complete this second edition was stage two of my OLE nirvana enlightenment—"groking" what OLE is really all about and how it is all organized. I understood its purpose and its future. OLE's life purpose is—well, I won't spoil it for you. I'll let you read Chapter 1 (and Chapter 25) to find the answer, but I'll drop the hint that all of OLE has to do with empowering end users to use their computers in more productive and creative ways. It also has to do with the fact that our programming and computing paradigms are evolving in such a way that objects can truly benefit all end users. In particular, the core of OLE is what is called component software. Chapter 1 defines the term as I use it throughout the book. Chapter 25 describes the future of component software as I see it. Everything in between explores the technologies, the mechanisms, and the code that begin to realize it.

While writing this book of my own, I found time to read a good number of others (many of which I've quoted from at the beginning of chapters). In an intriguing case of synchronicity, one of the books I read was an extraordinary one titled The Chalice and the Blade, by Riane Eisler.1 The thesis of Eisler's book is that our culture is approaching a point in history at which we will choose between a dominator model (a few individuals and organizations ruling and commanding the masses) and a partnership model (everyone working together on an equal basis). The former promises a breakdown of cultural evolution; the latter, a breakthrough. In Eisler's words, "Human evolution is now at a crossroads. Stripped to its essentials, the central human task is how to organize society to promote the survival of our species and the development of our unique potentials…. Humans [as evolutionary theorist Erwin Laszlo points out] 'have the ability to act consciously, and collectively,' exercising foresight to 'choose their own evolutionary path.' "2

I see a similar crossroads in the state of the software industry today. Perhaps the choices we have in the software business are merely metaphorical aspects of humanity's overall cultural evolution. (Perhaps this is stage three of OLE nirvana.) Today we have a dominator model—millions of computer users are limited by a few applications created by a few large companies. Component software, however, is a computing environment in which diverse objects created by varied groups and individuals work together, in partnership, to empower all users to solve problems themselves and to create their own software solutions. The software industry can choose either to perpetuate its excessively competitive ways or to build a market in which winning does not have to come at the expense of everything else. Our current ways seek a homogeneous end—one company's products dominating the market. Instead, we can seek an end for which diversity is the most important factor.

In a component software environment, one's potential is enriched by the diversity of available components and the diversity of available tools. The greater the diversity, the greater our potential. This holds true whether we are discussing software or society.

OLE provides new programming paradigms and new techniques for dealing with object-oriented principles, and it is still struggling to be recognized for the evolutionary technology that it is. Many see OLE as tantamount to heresy, mostly because new ideas threaten change, and change can be terrifying. Many forces rise up to squelch change or to redirect it toward selfish ends. The question we face is whether change is more terrifying than the perpetuation of current conditions. As you will glean from the pages in this book, I personally believe that component software will be essential in the future and that it will eventually be recognized as one of the key innovations in computing history. OLE is the right technology to begin our journey to that undiscovered country.