Preface

[Previous] [Next]

One of the most interesting aspects of the industry we work in is the pace at which it evolves. Having software and computer technology progress so rapidly is both a blessing and a curse. It s a blessing for some obvious reasons: constantly improving tools can help us write faster and more powerful software, the rapid change can lead to better career opportunities if you choose to keep up with the technology, and the need to learn new things quickly can bring personal growth. In addition, the quick evolution of software and computer technology means there s always a lot of room for new and innovative ideas. But it s a curse because the pace of change often makes it seem so difficult to stay current. Every time we turn around, we re faced with something new to absorb. When do we have the time and opportunity to really master what we ve just learned? Given that our chosen profession isn t going to change anytime soon, how can we as developers deal with this dual nature of our work? The answer, we think, is to find the best tools available to help you optimize the latest technology and minimize your learning curve.

Over the course of our careers, we ve noticed a certain pattern in software development—perhaps you ve observed it as well. When a new software technology emerges, it seems weird and bizarre, often a black art only a chosen few can master. Then folks develop higher-level abstractions that make the technology easier to work with.

In the beginning, there was assembly language—and it was good. Assembly language made implementing programs substantially easier than having to use machine language. Then computer languages, interpreters, and compilers replaced assembly language, and many more people were able to write programs.

When Microsoft Windows came along, it popularized the event-driven programming model. The event-driven programming model forced developers to completely overhaul their knowledge of programming. Writing Windows programs in the late 1980s and the early 1990s meant wrestling with the Windows SDK and the Microsoft C compiler—a lethal combination at the time, one that drove many developers to distraction. And then the Microsoft Foundation Class (MFC) library was created, making it unnecessary to write the same window procedure (that big switch statement) over and over again.

The Component Object Model (COM) saw the light of day in 1993 and it was good too. From the early 1990s (at the first OLE Professional Developers Conference) until 1996, however, the only real way to write COM-based software was using C++. More than anything, COM is a programming discipline known as interface-based programming. In interface-based programming, as many details as possible are hidden from the client code, making it easier to distribute software and integrate it at run time.

Programming raw COM with C++ involves myriad details. For example, implementing a COM class means creating a reference-counting mechanism and an interface-discovery mechanism for every object you implement. In addition, C++-based COM classes need another accompanying class object (sometimes called a class factory). Finally, writing a COM-based DLL in C++ means implementing the hooks that COM expects to see in a server (for exposing class objects) and often means managing a reference-counting mechanism for the server. Writing a COM-based EXE means exposing the class objects via an API function and implementing a lifetime control mechanism as well. Nearly the same code is duplicated from one project to another. That s why there s ATL.

The Microsoft Active Template Library (ATL) gets you to COM more quickly than using raw C++. By taking the boilerplate code necessary to get COM working and packaging it behind templates, classes, and utility functions, ATL saves you a lot of typing.

Knowing ATL doesn t replace your need to understand how COM works, though. In fact, the only way to really comprehend ATL is to get a firm grasp on COM. You ll find that ATL uses C++ templates extensively and, at first glance, you might think esoterically. Once you get the hang of ATL, however, you ll see that its design is quite elegant.

This book is intended to be a guide to using ATL. We cover topics such as COM by itself, C++ templates, ATL-based COM classes and servers, COM identity and class composition, ATL and ActiveX controls, the ATL wizards, ATL and persistence, ATL and connection points, ATL windowing support, and using ATL to write applications.

The target platform for this book is generally Microsoft Windows NT 4.0. Although the release of Microsoft Windows 2000 is just around the corner and some shops will adopt it right away, many shops will probably continue to use Windows NT 4.0 for some time. Windows 2000 brings some significant refinements to the COM programming model the most important of which is the integration of Microsoft Transaction Server (MTS) into the programming mode and the use of contexts and interception to help heterogeneous objects live in harmony. For example, in Windows NT 4.0, apartments are the main mechanism for protecting objects from concurrent access via multiple threads. In Windows 2000, the context is the main tool for protecting objects from concurrent access. (We cover this topic in Chapter 17.)

For now, the future is COM, and developing COM-based software in ATL is the fastest way to get there. Let s find out how.

 if(YouWantAHistoryOfATL()) { ReadChapter1(); } if(YouDontKnowCOM()) { ReadChapter2(); } if(YouDontKnowTemplates()) { ReadChapter3(); } ReadTheRestOfTheBook();