Removing ATL from Your Code

Removing ATL from Your Code
COM is all over the place if you are doing win32 programming especially in higher level components like the shell. Should we be using COM as a Windows extension model in general is debatable, but we can leave that discussion for a later time. We want to talk about ATL.

The point of ATL is that it is supposed to help you write COM code more quickly by taking care of the tedious parts of COM programming like implementing IUnknown, managing ref counts, and freeing up memory; however, without going into too much gory detail, using ATL adds many high level dependencies not introduced by simple COM programming. If you are writing a higher level COM object that is already depending on things that use ATL or other high level dependencies, then maybe it doesn’t really matter if you are using ATL. Then it is really just a matter of preference. If you want to limit your high level dependencies and lower the level of you COM object, then you should avoid taking a dependency on ATL. Generally this is what you want to do if you want to write a low level system component that others will depend on and write extensions. I fall into this latter category for a component I want to clean up.

Unfortunately you may have some legacy COM code that took a dependency on ATL. If someone wanted depend on your component for use for something low level, then ATL could be a deal breaker. That is if COM already isn’t, but there are ways to make COM lean and mean without even using OLE. Take UMDF for example. This scenario is precisely the situation I am in. After coming back from vacation, I will be spending the next while removing ATL from some COM components. I will write on the things you need to do as I go through and figure out the processes.