VC6 and VC7 applications and DLLs coexistence

  • Thread starter Thread starter Devender Khari
  • Start date Start date
D

Devender Khari

Hi Friends,

I'm facing a situation as follows, need help on identifying possible issues.

There is an MFC application developed in VC6.0, say ABCVC6.exe and another
developed in VC.NET, say DEFVCNET.exe. There are a few DLLs that are to be
used
by these applications. All these DLLs are originally developed in VC6.0 but
some of them are now migrated to VC.NET. So, let's say we have PQRVC6.dll
and XYZVCNET.dll.

Can ABCVC6.exe and DEFVCNET.exe can work simultaneously and use the DLLs
too?
What could be the possible issues regarding system DLLs like mfc/ole dlls
etc?

Thanks in advance for your ideas/thoughts/comments.

Regards,
Devender...
 
To the best of my knowledge, it should all be fine. As for VC6.exe and
VCNET.exe using the same DLL(s) simultaneously - all I know is that DLLs are
meant to be instance based - that's why you can use LoadLibrary();. Every
instance of a DLL has its own memory space etc. Plus an instance is created
at run time if your application imports functions from it. If you need to
communicate between instances use data segments like so:

// include files

#pragma data_seg(sharedsectionxyz)
// variables go here.
CLinkedList<CInstanceInfo_Base> g_llInstances;
#pragma data_seg()
#pragma comment(linker, "/SECTION:sharedsectionxyz,RWS")
/* it's been a while since I've done this, I think the only thing
that might go wrong is the linker thing, but it looks alright
on a second glance */
// DllMain etc.

Hope that helps, if you need anything more, just email kawahee AT gmail DOT
com.

-- Todd
 
Thanks Todd for a very prompt reply.

I have an MFC DLL built in .Net and want to use it in an exe built in VC 6.
That's giving me some problems.
Any ideas on that?

Thanks & Regards,
Devender...
 
Hallo Devender!
I'm facing a situation as follows, need help on identifying possible issues.

There is an MFC application developed in VC6.0, say ABCVC6.exe and another
developed in VC.NET, say DEFVCNET.exe. There are a few DLLs that are to be
used
by these applications. All these DLLs are originally developed in VC6.0 but
some of them are now migrated to VC.NET. So, let's say we have PQRVC6.dll
and XYZVCNET.dll.

Can ABCVC6.exe and DEFVCNET.exe can work simultaneously and use the DLLs
too?
What could be the possible issues regarding system DLLs like mfc/ole dlls
etc?
Click to expand...

Usually they can cooexists, but it depends on the way you use and
compiled the DLL's.
MFC-Extension DLL's must be compiled and bound to the same shared MFC
DLL like your application.
If you rae just building regular DLL's or using the staticly linked
version of the MFC it is also no problem.

Problems will occure if you use different versions of the CRT to
allocate and free the memory. I.e. new/malloc called in one DLL, and
delete/free form another DLL both linked to different CRT versions.

Also be aware that the memory that is needed for you program might raise
more than you might thought, because CRT and MFC DLL's are loaded more
than once.

Check the situation with DEPENDS.EXE
 
Hi Martin,

Thanks for your valuable response.

I have an exe built in vc++ .net and it's using a dll that is also built in
vc++ .net. This dll in turn is using another dll that is built in vc 6. This
is where I'm running into the problem. These DLLs are MFC Regular DLLs with
some GUI (dialog boxes, etc.)

The application crashes in MFC71.dll and the stack shows AfxWinMain
somewhere in the sequence. The MFC library is dynamically linked in the DLLs
and also MFC is used as shared library in the project settings.

Is this scenario workable at all? If yes, can you please suggest how?

Thanks,
Devender...
 
Devender said:
Hi Friends,

I'm facing a situation as follows, need help on identifying possible
issues.

There is an MFC application developed in VC6.0, say ABCVC6.exe and
another developed in VC.NET, say DEFVCNET.exe. There are a few DLLs
that are to be used
by these applications. All these DLLs are originally developed in
VC6.0 but some of them are now migrated to VC.NET. So, let's say we
have PQRVC6.dll and XYZVCNET.dll.

Can ABCVC6.exe and DEFVCNET.exe can work simultaneously and use the
DLLs too?
Click to expand...

Most likely NO, but under certain circumstances yes.

If the DLLs expose any stadard library (STL), MFC or ATL classes in their
API (e.g. a function that accepts CString, or returns std::string), it won't
work. The VC6 and VC7 libraries are not compatible at a binary level.

If the DLLs expose an API composed entirey of built-in types, or types that
you defined that don't depend on STL or MFC AND the DLLs properly
encapsulate memory (and other resource) management so that what's allocated
in the DLL is freed in the DLL, then you can mix VC6 and VC7 EXEs/DLLs. If
any of the above is not true, then it wont work.

In practice it'll work only if the DLLs were designed specifically with this
kind of compatibility in mind.

Note that COM DLLs adhere to all of these rules, so COM DLLs will always
work cross-version (since it's really no different from cross-language).
What could be the possible issues regarding system DLLs like mfc/ole
dlls etc?
Click to expand...

System DLLs won't be a problem since they're versioned in their names (e.g.
MFC42.DLL, MFC7.DLL). The lower-level OS DLLs are language neutral anyway.
Note that you may end up with multiple CRT versions loaded - as long as the
DLLs manage their own resources correctly, this isn't a problem, but it does
contribute to having a larger memory footprint.

-cd
 
That's correct. In practice I had to work around this problem by
"flattening" my classes and exposing them as a C interface.
 
Nemanja said:
That's correct. In practice I had to work around this problem by
"flattening" my classes and exposing them as a C interface.
Click to expand...

That'll work. In the past I've also put things into COM interfaces (local,
no marshaling support) to accomplish the same.

-cd
 
Hallo Devender!
I have an exe built in vc++ .net and it's using a dll that is also built in
vc++ .net. This dll in turn is using another dll that is built in vc 6. This
is where I'm running into the problem. These DLLs are MFC Regular DLLs with
some GUI (dialog boxes, etc.)
Click to expand...

Usually this should work as I sayed.
The application crashes in MFC71.dll and the stack shows AfxWinMain
somewhere in the sequence. The MFC library is dynamically linked in the DLLs
and also MFC is used as shared library in the project settings.
Click to expand...

Shouldn't be the problem.
Is this scenario workable at all? If yes, can you please suggest how?
Click to expand...

Carl just wrote more about the main problem of freeing memory with one
CRT that was allocated in another CRT.

If you can isolate all functions to work on an interface or with "C"
style functions it should work.
 
I don't use MFC sorry - I've just wrapped the Win32 API up into my own custom
classes. The only advice I can offer is to check if the VC6 and VC7 MFC DLLs
are compatable - and I'm guessing they sure as hell aren't.

Best of luck,

-- Todd Aspeotis
http://www.kyvestudios.deadlyfear.com/ (WIP)
 
Hi Carl,

Thanks a lot for your inputs. I made it work by changing MFC arguments in
the exported functions of DLLs into the Windows built in types. I'm facing
an issue though, it is as follows:

I have a Wizard application ABC.exe that is calling a DLL (FIRST.dll) which
has a class exported. This class has all the pure virtual functions. Another
class in the DLL is derived from CDialog and this exported class using
multiple inheritance. This new CDialog based class implements those virtual
functions. ABC.exe and FIRST.dll are compiled in VC7. There is another DLL
(SECOND.dll) that exports a few APIs using Windows built in types as
arguments. The SECOND.dll is compiled in VC6. From the OnPaint handler in
FIRST.dll we call an onPaint exported function of SECOND.dll. Earlier we
were passing a CPaintDC pointer typecast to CDC pointer but now we have
changed it HDC. And in SECOND.dll we are calling FromHandle(hDC) to get a
CDC object. This resulted in crash. Then we changed it as follows:
CDC* pCDC = new CDC();
pCDC->Attach(hDC);

// handling code

if(pCDC)
{
pCDC->Detach();
delete pCDC;
}

This also result in crash but with a totally different stack.

CPaintDC object that is passed from FIRST.dll to SECOND.dll is created using
'new'.

Could you please suggest what's going wrong?

Thanks,
Devender...
 
Devender said:
Hi Carl,

Thanks a lot for your inputs. I made it work by changing MFC
arguments in the exported functions of DLLs into the Windows built in
types. I'm facing an issue though, it is as follows:

I have a Wizard application ABC.exe that is calling a DLL (FIRST.dll)
which has a class exported. This class has all the pure virtual
functions. Another class in the DLL is derived from CDialog and this
exported class using multiple inheritance. This new CDialog based
class implements those virtual functions. ABC.exe and FIRST.dll are
compiled in VC7. There is another DLL (SECOND.dll) that exports a few
APIs using Windows built in types as arguments. The SECOND.dll is
compiled in VC6. From the OnPaint handler in FIRST.dll we call an
onPaint exported function of SECOND.dll. Earlier we were passing a
CPaintDC pointer typecast to CDC pointer but now we have changed it
HDC. And in SECOND.dll we are calling FromHandle(hDC) to get a CDC
object. This resulted in crash. Then we changed it as follows:
CDC* pCDC = new CDC();
pCDC->Attach(hDC);

// handling code

if(pCDC)
{
pCDC->Detach();
delete pCDC;
}

This also result in crash but with a totally different stack.

CPaintDC object that is passed from FIRST.dll to SECOND.dll is
created using 'new'.

Could you please suggest what's going wrong?
Click to expand...

I can't, but maybe someone else can. I don't use MFC (in fact, as a general
rule I don't write GUI code at all), but you might try asking on
microsoft.public.vc.mfc if you don't get an answer here.

-cd
 
Back
Top