regular dll vs extension dll

Question

I have a DLL (A.dll) that uses ATL stuff, and can't have MFC in it. There is some stuff it needs that is MFC though, so I made a MFC regular DLL, called B.dll and it gets automatically loaded at runtime by A.dll (via an import library).

The part of B.dll that A needs is a class (foo) defined in B.dll, and the class has some stuff in it that uses MFC. Am i allowed to create a foo object in A.dll? Does B need to be an extension DLL instead?

The Regular DLL page says:

All memory allocations within a regular DLL should stay within the DLL; the DLL should not pass to or receive from the calling executable any of the following:

• Pointers to MFC objects

• Pointers to memory allocated by MFC

but the extension DLL page says

The client executable must be an MFC application compiled with _AFXDLL defined., and A.dll can't be an MFC app.

Is it a problem to use a regular DLL in this case?

Thanks,

Bryan

Answer 1

Maybe I'm misunderstanding, but if A can't use MFC, and B provides a class that does, how can you instantiate an object in A? Are you looking to have B have a factory function that creates the object and passes it to A through a pointer? In that case you need to ensure that B calls delete() on it, not A, because they'll have two different heaps.

Is this a COM object or what do you mean by 'import library'? Are we talking the 'regular' dll way with the stubs in the .lib, or an 'import library' .tlb? (Not that it matters for the question I think, I'm just trying to picture the situation).

Answer 2

It would seem that a regular DLL is the right choice.

The main concern with regular DLL is that if it were loaded into an MFC app, there would be two independent copies of MFC and all metadata. The advice you found is written to make sure that metadata lookups don't go to the wrong copy. Not a problem in your scenario.