We are trying to port an application from VC++ to VC++.net. The application is client server based. Should the third party VC++ compatible DLLs also be migrated to third party VC++.net DLLs?
> We are trying to port an application from VC++ to VC++.net. The application is client server based. Should the third party VC++ compatible DLLs also be migrated to third party VC++.net DLLs?
>
[quoted text clipped - 5 lines]
>
> <Id>EcctqPPdkUq6HxavslI0HA==</Id>
Generally the answer is yes. It is no if the DLL has been carefuly
designed to support thios scenario. Among other things that means it
cannot allocate memory in objects in the dll and have the caller
de-allocate them or the other way arond, it can't pass CRT objects (like
file handles), it should pass ++ objects that it doesn't control (like
MFC or ATL classes). One reliable way to do this is to just have COM as
the interface layer since the COM rules already obey the restrictions of
what is safe to do in the interface layer.
Ronald Laeremans
Visual C++ team