ATL COM and DLL comparision........... [modified]

[vijay victory]

Hi Experts, I m bit confused about ATL COM applications..and DLL As I have already developed and using DLL(MFC/NON MFC) created in VC 6.0. So Is there any advantages if I covert this into ATL COM. what are they?? And if I m capable of doing so..i.e. Converting DLL(MFC/NON MFC) into ATL COM application then Whats type of care must have to be taken??? Like ........... 1> Global and local variable .or 2> Public/protected members of CLASS .or 3> Exported functions of DLL plz guide me..and clear my confusion.... Thanx in advance.. Victory

modified on Wednesday, January 14, 2009 2:16 PM

[Stuart Dootson]

Using COM makes it easier to use your DLL with languages other than C++, for example VBA or VB.

vijay.victory wrote:

As I have already developed and using DLL(MFC/NON MFC) created in VC 6.0. So Is there any advantages if I covert this into ATL COM

If it ain't broke, don't fix it.

vijay.victory wrote:

And if I m capable of doing so..i.e. Converting DLL(MFC/NON MFC) into ATL COM application then Whats type of care must have to be taken Like ........... 1> Global and local variable .or 2> Public/protected members of CLASS .or 3> Exported functions of DLL

Sounds like you need to learn about COM first... COM defines a mechanism by which you can define and use objects in a (relatively) language independent manner. You expose objects through interfaces (a.k.a. pure abstract classes). Globals and locals aren't so much of an issue, as functionality is exposed in an OO way. Public/protected class members aren't an issue, as you only expose methods that implement (public!) interface methods. Exported functions aren't an issue - the COM specification tells you what functions to export (DllGetClassObject and DllRegisterServer)