I'm glad to see, that MS still did not get rid of ATL and continued to support us, that's those guys, who think that .NET is really awful, but not the holy grail :)

If you want to see it yourselfs, get a copy of windiff.exe or just run it, and compare your directories. It's a very handy tool, to compare source codes! 

So, I compared some features on ATL. Quickly I found some differences in atlcomcli.h (I did not check everything however) and the improvements are OK!

Another part of the ATL source code, seems related to HTML and internet (ISAPI). Lots of checks and code has been added to make sure your precious HTML / encoding etc is kept in tact. 

Well, which improvements? As you might know that ATL is all, mainly about writing non-UI unmanaged code, such as COM components or using powerfull small sized wrappers around kernel-items like security, string management, etc.

At first, finally, I found that MS recognized that SafeArrayGetVartype is flawed, since it does not really fetch the VARTYPE of the array in all situations. So they wrote AtlSafeArrayGetActualVartype.

Another things is CComVariant::Clear() which was a dangerous function to use! Why and when? Because the function it wraps, is VariantClear and variantClear does only set vt to VT_EMPTY, but it does not 'zero' the rest of the VARIANT struct. Some programs, do expect in/out variables, and in the case that it is not always testing for the vt (variant type) and reallocates the CComVariant instance, it might erronously reallocate 'freed' or 'zombie'-pointers.

So my advise is to never use CComVariant::Clear() but use CComVariant::ClearToZero() now to avoid a case of reallocating zombie data!

Another handy improvements is a new overloaded method on the WriteToStream member function.
It is CComVariant::WriteToStream(IStream *pstr, VARTYPE vt);

So, if you write the current variant to a certain stream, you can convert it to a BSTR (for instance) using this extra new parameter..

Then we got some important bugfixes in atldb.h and atldbcli.h some annotation and datatype and even template fixes.

Lets see atlutil.h. Lots of new helper functions have been added. AtlStrToNum and functions that help to convert and to support the conversion to and from __int64 (LONGLONG) datatype. Normally, I always had to lookup for such functions into the VC function library and to add some wrappers around them.

Once I checked this all, and I recompiled one of my CPP, ATL projects, the size became just slightly bigger. But who cares? If this is all about more robust and safe code, I'm not disappointed by the Sp1 for VC on Visual Studio 2005.

 

(I was disappointed, when MS deprecated a lot of syntax without any announcements since of Visual Studio 2003)