Can VC 6 and VC 7 libraries be used in same program?
Ed
were built with VC6 and I don't have souce code. So I was able to recompile
only my own code. When running in the debugger, I see both msvcrtd.dll and
msvcr70d.dll/mfc70d.dll get loaded. The program crashes when deleting an
object which is an instance of a class in one of the libraries built with
VC6. I found that the object was created by operator new in mfc70d.dll but
deleted by operator delete in msvcrtd.dll. Is this the cause of the crash
and how to work around it?
Thanks for any ideas.
Call stack:
NTDLL.DLL!77fa018c()
NTDLL.DLL!77fb6454()
NTDLL.DLL!77f9260c()
KERNEL32.DLL!77e91495()
MSVCRTD.DLL!_CrtIsValidHeapPointer(const void * pUserData=0x01fd8178)
Line 1697 C
MSVCRTD.DLL!_free_dbg_lk(void * pUserData=0x01fd8178, int nBlockUse=1)
Line 1044 + 0x9 C
MSVCRTD.DLL!_free_dbg(void * pUserData=0x01fd8178, int nBlockUse=1) Line
1001 + 0xd C
MSVCRTD.DLL!operator delete(void * pUserData=0x01fd8178) Line 49 + 0x10
C++
...
> mfc70d.dll!operator new(unsigned int nSize=12) Line 331 C++
David Lowndes
>object which is an instance of a class in one of the libraries built with
>VC6. I found that the object was created by operator new in mfc70d.dll but
>deleted by operator delete in msvcrtd.dll. Is this the cause of the crash
Most likely.
>and how to work around it?
If you can't rebuild the library with VC7, then I think your only
option is to stick with VC6 throughout.
Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
My address is altered to discourage junk mail.
Please post responses to the newsgroup thread,
there's no need for follow-up email copies.
edmund
So there is no compiler or linker flag that forces the calls to new and
delete to be in the same library, say mfc70.dll? Will it help if I define my
own new and delete operator?
"David Lowndes" <dav...@mvps.org> wrote in message
news:053aauslmko8j3frg...@4ax.com...
David Lowndes
>delete to be in the same library, say mfc70.dll? Will it help if I define my
>own new and delete operator?
If you can't rebuild your library, then I can't see how you can do
anything to remedy the situation, other than to stick with VC6
Anson Tsao
executables cannot use MFC6 extension DLLs or vice versa.
--
Anson Tsao
Visual C++ libraries team
Of course, this posting wouldn't be complete without a nice, juicy
disclaimer from our lawyers: This posting is provided "AS IS" with no
warranties, and confers no rights. You assume all risk for your use. © 2002
Microsoft Corporation. All rights reserved.
"Ed" <e...@na.com> wrote in message news:OpYyLd21BHA.2272@tkmsftngp02...
edmund
rebuilt it with VC7. And I can get rid of my MFC code if I have to.
The libraris (I use but have no source code) don't use MFC at all. So I
guess the final question comes to:
Is msvcr70.dll binary compatible with old msvcrt.dll?
Thanks.
"Anson Tsao" <ans...@online.microsoft.com> wrote in message
news:eB#dVjV2BHA.2516@tkmsftngp04...
Phil Lucido [MSFT]
the future, but does for VC7.0.
The same cannot be said for msvcp70.dll -vs- msvcp60.dll. If you're using
the C++ Standard Library classes (e.g. std::basic_string,
std::basic_iostream, all the other classes from namespace std exported by
the DLL version), then you definitely cannot count on binary compatibility.
Much has changed between these two.
Note that binary compatibility for msvcr70.dll and msvcrt.dll doesn't mean
you can mix-and-match indiscriminately. You can't allocate something with
the heap in msvcr70.dll and expect to release it with a call to free or
delete in msvcrt.dll, or vice versa. Same applies to FILE pointers or low
i/o file descriptors, or any other sort of CRT-allocated resource.
...Phil
"edmund" <e...@na.com> wrote in message news:OA#fL0Z2BHA.2280@tkmsftngp02...
David Lowndes
>you can mix-and-match indiscriminately.
Phil,
Can you explain precisely what it does mean then?
Phil Lucido [MSFT]
> >Note that binary compatibility for msvcr70.dll and msvcrt.dll doesn't
mean
> >you can mix-and-match indiscriminately.
>
> Phil,
>
> Can you explain precisely what it does mean then?
If you've got a .lib or .obj that needs to link to msvcrt.lib, then you
shouldn't have to recompile it to work with the new msvcrt.lib in VC7. The
lib/obj may rely on the sizes/field offsets/member func names of various CRT
classes or variables, and those should all still exist in a compatible way.
Of course, once you relink against msvcrt.lib, your final exe/dll image will
now have a dependency on msvcr70.dll instead of msvcrt.dll.
That is all within the context of a single dll or exe. If you have more
than one dll/exe, then you have the possibility of more than one CRT. The
problem with cross-CRT resource allocation/deallocation isn't so much a
problem of VC7 -vs- older versions. Instead, it's something that's always
been a factor when using the CRT - e.g. statically linking the CRT into
multiple DLLs has the same problem. People who run into this problem with
static CRTs have always been instructed to compile /MD to use the CRT DLL.
That's still true. But now that the CRT DLL has been renamed to
msvcr70.dll, you have to worry about an app with some older components
linked to msvcrt.dll, some to msvcr70.dll. Usually that's not a problem.
But if those dlls pass CRT resources across the msvcrt/msvcr70 boundary,
you'll get the same kind of problems you always do with mismatched CRTs.
Contrast that to the situation with linking to msvcprt.lib when using the
DLL version of the C++ Standard Library. You will not be able to link an
old .lib/.obj against the new msvcprt.lib. You'll almost certainly get
linker errors, and if you don't, you'll still run into problems because
class field items have different offsets. You must recompile, which means
if you've got a 3rd party library that used msvcprt.lib, you'll have to get
a new version recompiled with VC7.
BTW, this meaning of binary compatibility is what restricts us so strongly
when it comes to updating the C++ Standard Library portion of the CRT in
service packs. Dinkumware has had an upgrade version of the C++ Standard
Library available for VC6 for years, but the changes in there did not appear
in VC6 service packs. That's because there was no way to pick up those
changes and still produce an msvcp60.dll which exported all the entrypoints
that were present in the original version, and also kept all class sizes and
offsets identical. Failure to do that would mean that dropping a new
msvcp60.dll in on an app compiled against the original release of VC6 would
result in a broken app.
...Phil (CRT dev lead, at least for a couple more months)
David Lowndes
>...Phil (CRT dev lead, at least for a couple more months)
Off to a new project? Anything new and exciting?