Getting started with ATL

I am currently working on some projects where I have to program a DCOM server. There are several reasons why it has to be DCOM and C++, instead of e.g. .NET remoting and C#.

The biggest pain (imo) about DCOM is that the technology stems from an era when the internet was no ubiquitous, and there were no huge forums filled with experts, or blogs by programming gurus and sites like There were newsgroups, but those were generally only used for specific problems.

There is a vast amount of concise information about everything you can do with the .NET framework. For DCOM there is … a big dark void.

Granted, there are several resources out there. But if you look on sites like codeproject, you will find that most of the articles about DCOM and ATL are written before 2003. Most of the information out there will not cover the improvements that have been made to ATL (or DCOM) since the last 5 years.

And when looking into the more obscure corners of DCOM, there are some things that noone really likes to talk about because the documented semantics are so vague, and if you look into things like custom IMoniker implementation… well… that is a story for another day.

Understanding DCOM

The most important thing with DCOM is that you understand the basics really well. I guess this is true for most things, but unlike other things like .NET, DCOM does not cut you any slack, and does not provide you with tons of helpful diagnostic information.

When I started with DCOM a couple of years ago, I first read ‘Essential COM’ by Don Box. This is really the most excellent book on COM ever.

Of course, this information becomes vitally important in the real world when you have to debug a problem, because no tool is going to tell you anything useful with DCOM related crashes.

Understanding ATL

In the real world (unless maintaining legacy code) you use ATL to write COM clients or servers. Personally, I don’t like books that just tell me how to use technology XYZ. I like to understand the ‘why’ and ‘how’ too.

This is where I have to give big thanks to ‘ATL Internals, Second Edition’. It is one of the very few books on ATL that were written for VS2005, and it is still valid for VS2008. It is also an extremely well written book.

If you are starting with ATL (or if you want to know how it works) buy this book. This book is very, very good, and will teach you a lot.

What happens next?

Over the next weeks / months I will probably write a couple of articles describing how to do specific things with ATL. One article that is nearly finished is about implementing and using IEnumString using ATL.

Not rocket science by any measure, but ATL is severely lacking in the area of easy-to-find, up-to-date and to-the-point examples. So I figured that there is still value in writing about the ancient art of circles and lollipops, even if many developers probably think COM and ATL are no longer worth bothering with.

Oh and I released some win32 DCOM demo projects some time ago. They were interesting for me because making them taught me a lot about the raw DCOM stuff that you normally don’t see with ATL. But I’ve always found that it is always useful to know what makes the motor hum.

So while they are not terribly useful for practical purposes, they are well documented and they might be useful if you are working your way through ‘Essential COM’

3 thoughts on “Getting started with ATL”

  1. >>> There are several reasons why it has to be DCOM and C++, instead of e.g. .NET remoting and C#.

    I’d be interested in knowing these reasons.

  2. Sure thing.

    I work in a pharmaceutical environment where I manage the process control servers. I also write apps to automate things to make my life easier.

    Most of the servers have the process control software installed. The vendor of that software has very strict ‘rules’ about what we can and can not install on those computers.

    Of course they are our computers, but the vendor only provides support if the systems are all accepted configurations.

    With the current software version, that means all servers are Windows 2003 RTM (no SP) and .NET 1.1

    .NET 1.1 is less than ideal for interacting with Active Directory. And I cannot install .NET 2.0 because that will make those computers unsupported.
    So .NET is out. And if .NET is out, only native options remain, which is C++

    I also need to allow automation engineers to do things for which I cannot give them privileges.
    So I need to work with a client server technology that allows me to have code invoked by only certain people, which then runs at a higher privilege level. DCOM is ideal for this.

    .NET can probably do this too, but It would involve custom configuration on those servers, and I cannot do that because of the support issues.

    If I use static linking with C++, I have no need of runtimes, and if I just delete the exe from the server, it is gone and the server is back to its original state.

    And the apps I write now are tiny apps that perform a specific task on demand. Startup times need to be as short as possible, just to limit the annoyance factor. The client apps are small dialog boxes which start the COM server. And MFC dialog applications are virtually instant on, while ,NET GUI apps take noticeably longer to load.

    That’s about it in a nutshell.

  3. Thank you for the detailed explanation. That does make sense.

    I’m looking forward to read the other articles in this series.

Leave a Reply

Your email address will not be published. Required fields are marked *