VS 2010 and VS 2008
in [MFC]
|
From: David Webber on 24 May 2010 10:19 "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message news:Xns9D8179D745AB2MihaiN(a)207.46.248.16... >> Is there any reason why a resource only DLL compiled with VS2008 should >> not >> work properly with a program compiled with VS2010 ? > > No idea why. Except maybe something crazy with manifests? > It might also depend if it is really resource only, or if there is an > entry point. > (if you don't use LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE, > LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE, LOAD_LIBRARY_AS_IMAGE_RESOURCE, > or DONT_RESOLVE_DLL_REFERENCES, then you would need a DllMain) 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. Anyway it seems to be working now, but Joe has alerted me to a potential problem with another DLL - a 3rd party library which is not resource only! Thanks. Dave -- David Webber Mozart Music Software http://www.mozart.co.uk For discussion and support see http://www.mozart.co.uk/mozartists/mailinglist.htm
From: David Webber on 24 May 2010 10:29 "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 -- David Webber Mozart Music Software http://www.mozart.co.uk For discussion and support see http://www.mozart.co.uk/mozartists/mailinglist.htm
From: Mihai N. on 25 May 2010 03:38 > 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. -- Mihai Nita [Microsoft MVP, Visual C++] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: David Webber on 25 May 2010 09:57 "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message news:Xns9D8368C8531DMihaiN(a)207.46.248.16... >> 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. I went through this a year or two ago trying LoadLibraryEx with the appropriate flags, and eventually settled on the way I'm doing it. I *think* there was something in the project settings but I can't for the life on me remember what it was. These are language resource modules, and whenever I've created a new one, I've just copied an old project and changed the name, and so it was quite a long time ago when I was worrying about it. Looking again, the only thing which jumps out at me is that the project properties include the linker flag /NOENTRY It looks like that is sufficient to allow LoadLibrary to load it as a resource only DLL. Maybe it effectively introduces an implicit DllMain? [I certainly don't have one of my own, or any C++ files, and the IDE's properties dialogue is smart enough not even to offer me a C/C++ section!] Dave -- David Webber Mozart Music Software http://www.mozart.co.uk For discussion and support see http://www.mozart.co.uk/mozartists/mailinglist.htm
From: Tom Serface on 25 May 2010 19:07
I've been doing more and more on 2010 and one thing that bugs me is that any statically linked MFC program gets an extra 1.5MB of stuff in the EXE for the Feature Pack controls whether or not they are used. At least with 2008 you could not install them if you didn't want to use them. I know this was also true in the beta, but I thought they were going to make it link sensitive, but apparently it has something to do with the ribbon editor being part of the resource editor so the code get sucked in regardless (even if you do a console app). I have one program I'll have to leave on 2008 since it needs to be as small as possible. In VC6 it was around 300K, in 2008 it was around 500K and with 2010 it is 2568K. Same code just compile three ways and nothing but basic controls used (no feature pack stuff). I still like VS 2010 and for most of my programs an extra 1.5MB wouldn't make a difference, but it seems rude to include functions from a library that aren't actually used. I really like the new IDE improvements and new "lack of" manifest support :o) Tom "David Webber" <dave(a)musical-dot-demon-dot-co.uk> wrote in message news:u9hT65m#KHA.5464(a)TK2MSFTNGP05.phx.gbl... > Just spent a happy Sunday morning installing VS 2010. > > Plus point: it found one syntax error in my several thousand .cpp files > which VS 2008 missed. > > Problems: one or two minor ones not yet resolved. > > Is there any reason why a resource only DLL compiled with VS2008 should > not work properly with a program compiled with VS2010 ? > > What about other non-MFC DLLs with a pure C interface? > > Dave > -- > David Webber > Mozart Music Software > http://www.mozart.co.uk > For discussion and support see > http://www.mozart.co.uk/mozartists/mailinglist.htm |