|
You don't have to worry about a poorly written installer overwritting the dll with an older version of MFC that your program can't use.
It also simplifies the installation of your program.
Gary Kirkham
A working Program is one that has only unobserved bugs
I thought I wanted a career, turns out I just wanted paychecks
|
|
|
|
|
And especially when the linker granualar links the objects you reference in the application. I found this out from a VCJ converence when Mike Blasczack (VC++ teamlead many moons agog) was there.
|
|
|
|
|
word to your momma.
-c
I'm not the droid you're looking for.
|
|
|
|
|
So 'nearies' statically link?
Software Zen: delete this;
|
|
|
|
|
and real men don't use external code at all - they write the whole damn thing from scratch.
(sp. thnx)
I'm not the droid you're looking for.
|
|
|
|
|
Chris Losinger wrote:
they write the whole damn thing from scratch
and in assembly language!
That's the word, home boy.
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Alvaro Mendez wrote:
and in assembly language!
and then they boast loudly on their web page about how great they are for doing so.
--Mike--
I'm bored... Episode I bored.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I'm actually a C++ developer, but I also write installs for VB developers at my company. I can't even begin to count the amount of support issues that different versions of MDAC have caused. We even have a application whose developer quit and it doesn't work with the new versions of MDAC.
|
|
|
|
|
Maybe you should consider dumping MDAC in favor of something that works (and is a little more stable)?
To my knowledge, the only "technology" that has stood the test of time is ODBC.
|
|
|
|
|
Hmmm...well we have used MDAC with no problems for years (through at least 6 different versions) and ODBC should be relegated to the dinosaur bonepile where it really belongs.
|
|
|
|
|
I can't agree more than that!!
M$ MDAC sucks! Especially, VB CODER(s) does not know anything about programming......
You should get rid of VB and terminate all VB coders who around you.
VB and VBer doe ssuck!!!!
|
|
|
|
|
There should be another option: Install MFC dlls in application directory.
Application will use this version of MFC dll for sure.
I see this all the time, and some vendors also install msvcrt.dll to application directory too.
Hans
|
|
|
|
|
Unless, like John Simmons / outlaw programmer said in a previous thread, some other program alraedy has other versions of those DLLs in memory. Then you are screwed.
It is possible, though, that this works fine in XP.
Even a broken clock is right twice a day.
|
|
|
|
|
That is not a fix. All it will guarantee is that you'll have several megabytes of disk space taken up by files with the same name.
If an app that uses a dll of the same name loads and is still in memory, Windows will see it and go "Hey, I don't need to load this DLL again cuz the code's already in memory. Ain't I a smart 'un?", and your app will likely crash and burn because of it.
------- signature starts
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
Please review the Legal Disclaimer in my bio.
------- signature ends
|
|
|
|
|
John Simmons / outlaw programmer wrote:
If an app that uses a dll of the same name loads and is still in memory, Windows will see it and go "Hey, I don't need to load this DLL again cuz the code's already in memory.
Are you sure it does'nt check the library's complete path name?
I can't believe it. That sounds unbelievable dumb. Even for MS.
Oliver
|
|
|
|
|
It indeed checks the full path name. In the "golden times" of 16-bit Windows there was a module name of the DLl and if a DLL with same name was loaded in memory already it was used instead.
But also rules have exceptions: In Win32 (perhaps only NT-based versions) there is a concept of known-system DLLs which will always loaded from the windows path and not from app path. I think msvcrt.dll is such a case but not the mfc dlls.
Hans
|
|
|
|
|
If the other dll is in other folder then no prob. for installing mfc directory but in app. fol. with same name no windows will not allow so give path in load library
Husnan Abbas Naqvi
ISLAMABAD(PAkistan)
|
|
|
|
|
GO ahead. This works fine. In fact, even the .NET way of installing apps is pushing this "xcopy" way of doing things.
|
|
|
|
|
That may work on XP and higher, but if you want your app to work for the rest of the world, you're hosed.
Even a broken clock is right twice a day.
|
|
|
|
|
With our commerical app, the mfc42.dll, msvcrt.dll, and mfco42d.dll (for debug builds) that the exe was built against are dropped in the same directory as the exe. We have never had a lick of problem on any platforms.
|
|
|
|
|
You are lucky.
Even a broken clock is right twice a day.
|
|
|
|
|
I know that this runs correctly on workstations that have a different version of the MFC libraries installed and a running application using those different versions. Our app always get it's MFC libraries. If you remove those libraries it will crash.
I thought that the search order for a dll was the application directory, system directory, then path. Since it finds one in the application directory, it will use it. There is not chance for it to say 'there is already a copy of that DLL running' because that 'copy' lives in the system directory.
Ofcourse, it nullifies any benefits of dynamically linking.
|
|
|
|
|
Although it depends on whether the DLL is registered or not, I think. I don't know if the MFC42.dll 'self-registers' or not.
But yeah, if it nullifies the benefits, then why do it?
Even a broken clock is right twice a day.
|
|
|
|
|
The app makes use of an extension DLL (that unfortunately can't be converted to a static library) and MFC requires dynamic linking in that case.
|
|
|
|
|
Extension DLLs are even more evil than regular DLLs! Not only are they evil, they are a non-standard form of evil.
Even a broken clock is right twice a day.
|
|
|
|