Preface Preface .NET has hit the Windows programmer community like a tornado, tipping over the trailer homes of the ways that we used to do things. It''s pretty much swept up the needs of most web applications and service applications, as well of most of the line-of-business applications for which we previously used Visual Basic and MFC. However, a few stubborn hold-outs in their root cellars will give up their native code only at the end of a gun. These are the folks with years of investment in C++ code who don''t trust some new-fangled compiler switches to make their native code "managed." Those folks won''t ever move their code, whether there are benefits to be gained or not. This book is partially for them, if they can be talked into moving their ATL 3/Visual C++ 6 projects forward to ATL 8 and Visual Studio 2005. Another class of developers that inhabit downtown Windows city aren''t touched by tornados and barely notice them when they happen.

These are the ones shipping applications that have to run fast and well on Windows 95 on up, that don''t have the CPU or the memory to run a .NET application or the bandwidth to download the .NET Framework even if they wanted to. These are the ones who also have to squeeze the maximum out of server machines, to take advantage of every resource that''s available. These are the ones who don''t have the luxury of the CPU, memory or storage resources provided by the clear weather of modern machines needed for garbage collection, just-in-time compilation, or a giant class library filled with things they don''t need. These developers value load time, execution speed, and direct access to the platform in rain, sleet, or dark of night. For them, any framework they use must have a strict policy when it comes to zero-overhead for features they don''t use, maximum flexibility for customization, and hard-core performance. For these developers, there''s ATL 8, the last, best native framework for the Windows platform.

For clients, ATL provides windowing, COM client smart types, extensive COM control and control hosting, MFC integration (including several MFC classes that no longer require the rest of MFC), and web service proxy generation. For servers, ATL provides full COM server and object services, and extensive support for high-throughput, high-concurrency web applications and services. For both clients and services, ATL makes aggressive use of macros and templates to give you maximum flexibility and low overhead, making sure you pay for only the features you use and giving you full transparency via the source code into how those classes map their functions to the platform. For productivity, ATL provides a full set of wizards for starting and building client and server projects. Attributes Pushing the productivity idea, in ATL 7 and Visual Studio 2003, the ATL team introduced attributed ATL, allowing ATL programmers to annotate their code using the same techniques that you would use to add metadata to IDL interfaces and coclasses (such as the uuid attribute). In fact, the wizards were so happy to show you this style of code that, in VS03, the Attributed option was on by default. However, all is not sunshine and bluebirds with attributes. In .

NET and IDL, attributes are a real part of the programming model; support for them exists all the way down. In ATL, attributes are more of a compiler trick, like super-macros, generating base classes, macro maps, Registry scripts, and IDL files. Unlike macros, however, ATL attributes are not transparent--you can''t see what is going on very well. A compiler switch is included to show a representation of generated code, such as what base classes were added, but it has regressed in VS05. This has led to problems in understanding and debugging issues, which was not helped by bugs in the attribute-generated code. That''s not to say that the rest of ATL is bug free (or that any software is bug free), but when it comes to problems in base classes or macros, ATL has always enabled you to replace problem functionality in several ways. In fact, code to work around problems was a big part of the first edition of this book because you could so easily sidestep problems. Cues in VS05 indicate that attributes are no longer a major part of the ATL team''s focus.

For example, the compiler switch shows less information, not more, about what attributes generate. Most telling, however, is that the Attributed option in the VS05 wizards is no longer checked by default. 1 For that reason, although we cover the principles of ATL attributes in Appendix D, "Attributed ATL," you won''t find them sprinkled throughout the book. We believe that half-hearted attributes won''t make ATL 8 programmers the happiest with their native framework of choice. Audience This book is for the C++/COM programmer moving to ATL 8, as provided with Visual Studio 2005. ATL was built with a set of assumptions, so to be an effective ATL programmer, you need to understand not only how ATL is built, but also why. Of course, to understand the why of ATL, you must understand the environment in which ATL was developed: COM. Instead of attempting to compress all required COM knowledge into one or two chapters, this book assumes that you already know COM and spends all its time showing you the design, use, and internals of ATL.

Don Box''s Essential COM (Addison-Wesley Professional, 1997) is a good source of COM knowledge, if you''d like to brush up before diving into ATL. Outline With the exception of the first chapter, this book is arranged from the lowest levels of ATL to the highest; each chapter builds on knowledge in previous chapters. The first chapter is a brief overview of some of the more common uses for ATL and the wizards that aid in those uses. Whenever things get too detailed in the first chapter, however, we refer you to a subsequent chapter that provides more in depth coverage. Chapters 2 through 5 present the core of ATL. Chapter 2, "Strings and Text," covers the messy world of string handling in C++, COM, and ATL. Chapter 3, "ATL Smart Types," discusses ATL smart types, such as CComPtr, CComQIPtr, CComBSTR, and CComVariant. Chapter 4, "Objects in ATL," discusses how objects are implemented in ATL and concentrates on the great range of choices you have when implementing IUnknown.

Chapter 5, "COM Servers," discusses the glue code required to expose COM objects from COM servers. Chapter 6, "Interface Maps," delves into the implementation of IUnknown again, this time concentrating on how to implement QueryInterface; this chapter shows techniques such as tear-off interfaces and aggregation. Chapters 7, "Persistence in ATL"; 8, "Collections and Enumerators"; and 9, "Connection Points," discuss canned interface implementations that ATL provides to support object persistence, COM collections and enumerators, and connection points, respectively. These services can be used by components that might or might not provide a user interface. Chapters 10, "Windowing"; 11, "ActiveX Controls"; and 12, "Control Containment," concentrate on building both standalone applications and user interface components. These chapters cover the ATL window classes, controls, and control containment, respectively. Finally, Chapters 13, "Hello, ATL Server," and 14, "ATL Server Internals," cover ATL Server, which lets you build web applications on IIS. Chapter 13 introduces ISAPI and ATL Server, and Chapter 14 looks under the hood of ATL Server.

Much of what makes the ATL source difficult to read is its advanced use of templates. Appendix A, "C++ Templates by Example," provides a set of examples that illustrate how templates are used and built. If you''ve seen ATL source code and wondered why you pass the name of a deriving class to a base class template, you will find this appendix useful. Appendix B, "ATL Header Files," provides a list of the ATL header files, along with descriptions to help you track down your favorite parts of the ATL implementation. If you''re already an ATL 3 programmer and you want to hit the ground running on what''s new in ATL 8, Appendix C, "Moving to ATL 8," is for you. Finally, if you''d like an introduction to attributes (and a bit more information about why we''ve relegated attribute coverage to a lowly appendix), you''ll want to read Appendix D, "Attributed ATL." Conventions When writing these chapters, it became necessary to show you not only diagrams and sample code, but also internal ATL implementation code. This book often becomes your personal tour guide through the ATL source code.

To help you distinguish author-generated code from Microsoft-employee-generated code, we''ve adopted the following convention: // This code is author-generated and is an example of what you''d type.// Bold-faced code requires your particular attention. CComBSTR bstr = OLESTR("Hello, World."); // Code with a gray background is part of ATL or Windows. CComBSTR(LPCOLESTR pSrc) { m_str = ::SysAllocString(pSrc); } Because the ATL team didn''t write its code to be published in book form, we often had to reformat it or even abbreviate it. Every effort has been made to retain the essence of the original code, but, as always, the ATL source code is the final arbiter. Sample Code and Further Information More information about this book, including the sample source code, is available at http://www.sellsbrothers.

com/writing/atlbook. On that site, you''ll also find contact information so that you can report errors or give feedback. Footnotes 1 Except for when generating an ATL Server Web Service project, when the Attributed Code option is checked and disabled so that you can''t uncheck it.