VS 2010 and VS 2008
in [MFC]
|
From: Joseph M. Newcomer on 28 May 2010 19:57 It should work, as long as you don't try to delete the XML tree by using any means other than calling a delete/free function in the XML library. The classic problem with the multiple heaps is the DLL allocates objects but specifies the caller should call 'free', and when you call 'free' you're calling the wrong runtime and end up getting assertion failures everywhere. OTOH, if the library provides a "free objects" mechanism of its own, it calls 'free' for its own heap, and there is no conflict. The multiple-heaps problem only arises when the .exe and the .dll actually have an implicit dependence on having a single heap. By providing a DLL which has its own methods to free objects, it calls the free function on its own heap. MFC has the same problems with new and delete of objects; and in addition, the MFC handle maps are local to each instance of the MFC DLL, which results in incredible confusion if there are HWND mappings and other mappings of handles that are interpreted differently by the DLL and the .EXE (again, if all operations are confined to the library, but in MFC that's harder to guarantee) joe On Mon, 24 May 2010 15:29:42 +0100, "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote: > > > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:ufkiv5tlp2878uhl1a1jqbbn66hrvqfj0g(a)4ax.com... > >>>What about other non-MFC DLLs with a pure C interface? >* >> Depends. Do they use the C Runtime (CRT)? If so, do they statically link >> it or used the >> shared C runtime DLL? >> >> If they use the shared C runtime DLL, you might have problems. If they >> statically link, >> you have the problems of having multiple heaps being managed by multiple >> runtimes. This >> hazard has not change because of VS2010. > >Doh!!!!!! Yes I am linking with the Xerces XML library, and it is a >version which good old dependency walker tells me uses MSVCR90.DLL, whereas >my newly compiled program and DLLs now use MSVCR100.DLL. > >Whilst it isn't immediately obvious to me that this shouldn't work (and it >seems to), as IIRC the C run-time doesn't do such nasty things as the MFC >DLL, it does seem rather inelegant to say the least, and leaves me with all >sorts of insidious nagging doubts. I'll see if the Xerces people have an >update or, failing that, recompile it myself. > >Thanks for the warning - it woke me up!!!!! > >Dave Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 29 May 2010 10:54 No LoadLibrary does *not* require a DllMain. If you specify /NOENTRY to the linker when you build the DLL, it has no entry point, and no code. This is common for resource-only DLLs. IF a DllMain is present (actually, a specified entry point, since the entry point is *not* DllMain, ever; like main, it is something called from the runtime support), THEN it will be called when the DLL is loaded, whether implicitly or explicitly. If there is no entry point, nothing will be called. joe On Tue, 25 May 2010 00:38:36 -0700, "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote: > >> In fact I appear to be loading them with good old LoadLibrary but their >> projects have no .cpp files at all, just an .rc file and a few .h files. >> No DllMain. > >Then something is weird. That should not work. >Plain LoadLibrary requires a DllMain. >Can be almost empy, but should be there. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Mihai N. on 30 May 2010 05:45 > No LoadLibrary does *not* require a DllMain. If you specify /NOENTRY to > the linker when > you build the DLL, it has no entry point, and no code. This is common > for resource-only DLLs. I know it is true these days. But I am pretty sure that at some point (Win 9x?) LoadLibrary failed if you did not have a DllMain. For resource only dlls the option was to have a dummy DllMain returning TRUE or to use LoadLibraryEx(DONT_RESOLVE_DLL_REFERENCES) But since LoadLibraryEx was introduced in Windows 2000, the only way to use resource only dlls on Win 9x was to use have a DllMain. -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: Joseph M. Newcomer on 30 May 2010 21:41 See below... On Sun, 30 May 2010 02:45:46 -0700, "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote: >> No LoadLibrary does *not* require a DllMain. If you specify /NOENTRY to >> the linker when >> you build the DLL, it has no entry point, and no code. This is common >> for resource-only DLLs. > >I know it is true these days. >But I am pretty sure that at some point (Win 9x?) LoadLibrary failed >if you did not have a DllMain. *** It is entirely possible the brain-dead MS-DOS implementation failed. I was using resource-only DLLs in Windows NT 3.1, 3.51, and 4.0. I never cared a whole lot about what imitation Windows systems did. joe **** > >For resource only dlls the option was to have a dummy DllMain returning >TRUE or to use LoadLibraryEx(DONT_RESOLVE_DLL_REFERENCES) > >But since LoadLibraryEx was introduced in Windows 2000, the only way >to use resource only dlls on Win 9x was to use have a DllMain. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: David Webber on 31 May 2010 20:07
"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:3rl0061imk5m1lgp39g4jjdegu2qbrvjks(a)4ax.com... > It should work, as long as you don't try to delete the XML tree... It's ok I have adopted a version of Xerces compiled with VS 2010. I feel happier now :-) Dave -- David Webber Mozart Music Software http://www.mozart.co.uk For discussion and support see http://www.mozart.co.uk/mozartists/mailinglist.htm |