|
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.
|
|
|
|
|
You're absolutely right about the search order of DLLs. First the app dir then the system and then all directories in the PATH environment variable. Fine.
This works 364 days a year. On the 1 remaining day a once take the following I couldn't explain.
Here the weired story in short:
Two MFC42.DLL
First One: in System (new one) used by Visual Studio 6
Second One: in Application Directory (a old MFC42.DLL version)
This one Day Visual Studio 6 failed loading saying it cannot find a export from MFC42.DLL.
Nailing the problem down was on this damn day, it took the one from the Application Directory of an App that wasn't related to Visual Studio 6 at all (besides using a MFC42.DLL). The app dir wasn't even in the path !!!
Still Windows thought it has to take the MFC42.DLL from this App Dir, not the System not one of the Path !!!
I started Studio a dozend times always the same 
Well the fix was quite easy i deleted the one from the App Dir. After that everything worked again (that one was luck).
Such strange behaviour never ever occured again.
Welcome in DLL Hell... 
|
|
|
|
|
With Windows ME, 2K and XP the loader can be instructed to load the local copy for the app.
This is called side by side installation and is supported by MSI or can be done by manualy
(or via installation script) adding a redirection file in the local app directory.
Details can be read in MSDN, so its an official supported limited way to overcome DLL - Hell.
Sometimes I believe life is also only
a real time 3D graphics simulation.
But the rules engine is really fkd up.
|
|
|
|
|
This is an ugly solution to an ageold problem, If you link MFC statically you will not have this worry, also there are other dependicies such as COMCTRL32.dll that have version differences as well. You get hosed in this aspect if you link dynamically as well, plus not to mention all of those developers who just push the version of COMCTRL / any other dependicies on the users system incorrectly. Using Static linking will alleviate suffering from all aspects. On a related not, I prefer to use dlls to store different sections of code I.E - Resources, Server componets, Client Componets, and provide static libs as well as dlls.
|
|
|
|
|
The only good use for DLL's that I've found so far are dynamic plug-in components. They fail miserably for the purpose of sharing code between different executables.
Being able to dynamically link to MFC42.DLL and MSVCRT.DLL in Visual C++ programs was a mistake.
Even a broken clock is right twice a day.
|
|
|
|
|
What was a bigger mistake in the case of MFC, was Microsoft not changing the file name of the DLL with each revision of MFC. If the file names ahd changed each time, you would not have this trouble. But now you have multiple, incompatible versions of the DLL all with the same damn file names 
C++/MFC/InstallShield since 1993
|
|
|
|
|
Yes, and that seems to happen with a lot of DLLs, not just MFC42.DLL.
Even a broken clock is right twice a day.
|
|
|
|
|
Navin wrote:
The only good use for DLL's that I've found so far are dynamic plug-in components.
DLLs went bad only because we have used them badly.
- What are DLLs ? a simple bunch of functions ready for use.
- How to diminish the amount of conflicts ? Use indirection. For instance, that's what COM is about.
- Should I favor statically linked DLLs over dynamically linked DLLs ? That's only driven by the kind of app you are dealing with : client; server; ... In addition, advanced uses of DLLs include delay load, optimization of the exposed vtable, etc. All this is instrumental part of the development life cycle.
|
|
|
|
|
Statically linked code will almost always be faster than dynamically linked code. And you won't have to worry about the versioning conflicts.
COM is evil too, btw. 
Even a broken clock is right twice a day.
|
|
|
|
|
>>Statically linked code will almost always be faster than dynamically linked code.
but not very much
>>And you won't have to worry about the versioning conflicts.
That's not true.
If the DLL has the same name, but a different interface, you will have a conflict.
|
|
|
|
|
Um, you misunderstood, I am not talking about statically linking to a DLL - that can be even worse. I am saying, statically link ALL the code, no DLL at all! Then the only vesioning issue you have to deal with is in the operating system itself.
Even a broken clock is right twice a day.
|
|
|
|
|
COM is a good and simple design in the beginning, but
COM becomes complex when more and more sepcial cases are
encountered. I don't know why MS added so ugly functions
to the COM mechanism.
So, I only use COM when I would like to add a class from
a DLL file. And so that I will not register the COM object.
I just use COM to realize "Interface-Style Programming".
|
|
|
|
|
The only good use for DLL's that I've found so far are dynamic plug-in components.
I agree.
One of the reasons DLL's are evil is because some idiots at Microsoft decided to give you the option to create a LIB for the DLL "to make life easier". That completely broke the "component" capability of the DLL, because now all its entry points were associated to the damn lib. If you changed the DLL, you had to recompile all your code that depended on the LIB. Stupid, stupid, stupid.
The next reason is that people are stupid. (Oh, I said that already). They would change the interface or the functionality of an entry point instead of providing a new public name. This resulted in lots of code breaking when a DLL was updated.
And there are other reasons...
Marc
Help! I'm an AI running around in someone's f*cked up universe simulator.
Sensitivity and ethnic diversity means celebrating difference, not hiding from it. - Christian Graus
Every line of code is a liability - Taka Muraoka
|
|
|
|
|
Preach it, brother!
One area where I've gotten myself in trouble in the past was when I tried to link to a .LIB for a system DLL. This is *usually* OK.. until I tried to use a 2000-specific function. You can't just do a check, if NT then don't call this.. the program won't even load if it doesn't find that function's entry point. So that required using LoadLibrary to get the 2000-specific function, so I could call it only in 2000 and have NT still fail gracefully.
Ah well.
Even a broken clock is right twice a day.
|
|
|
|
|
We dynamically link our applications to MFC. Our application runs in a controlled environment (it's an industrial PC doing process control). I know, that's the easy case. I would think that the opposite case of having to handle every Tom, Dick, or Fred version of Windows, along with the corresponding versions of the MFC DLL's, would have even greater problems than just 'DLL hell'.
Software Zen: delete this;
|
|
|
|
|
I thought the whole purpose of the ATL was that it consists of C++ templates in header files. You have to direct your compiler's include path to the ATL headers so that the "#include" statements work, but there is no library to link against.
Am I wrong?
--
Paul
"I drank... WHAT?"
|
|
|
|
|
Depending on how you build your ATL project, it may depend upon ATL.DLL (or ATL70.DLL, if you're using VS.NET). ATL(70).DLL contains some 'static' code for handling object registration.
Software Zen: delete this;
|
|
|
|
|
Chris Maunder posited:
Conflicts between different versions of the MFC and ATL libraries can cause headaches.
And thus the answer is "statically link to everything". With MFC this adds a couple hundred K, but results in zero install problems or DLL Hell issues.
Case in point: I installed dtSearch recently and doing so broke VC 6. Now I can no longer double-click a DSW file to open the workspace. Since this happened immediately after the install, dtSearch put down some DLL that f'ed up VC. This is exactly the sort of thing you avoid entirely by linking statically.
[edit]It's not a file extension that got reassociated, VC 6 still runs, it just crashes immediately.[/edit]
--Mike--
When 900 years old you reach, look as good you will not. Hmm.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
|
Uwe Keim wrote:
But your link times raises then.
So what?  That is not something that affects the running of the app, nor something the end-user knows about, so it's not a valid thing to base a decision on.
Uwe Keim wrote:
And simply putting the MFC DLLs locally into your application folder solves all problems, too.
Except that introduces a new problem, your distribution size grows by 1.77 MB (for the most common DLLs: mfc42, msvcrt, msvcirt, msvcp60) instead of 100K. So you would need to have 17 modules all using MFC to make that a valid argument.
--Mike--
When 900 years old you reach, look as good you will not. Hmm.
1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Do you honestly think longer link times are a viable trade-off for overall reliability for the end-user?
Furthermore, putting the DLL's in your own folder don't solve squat if the DLL was loaded by another app and that app is still running.
------- 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
|
|
|
|
|
|
It's not just the end user, it's also the developer support time. Nothing sucks worse than trying to debug system DLL versioning poblems. Not all systems have the right MFC versions... and if you try to install your own, you open up a new can of worms...
I do wonder if .NET will be better or worse. I suppose if any newer version of .NET is 100% backwards compatible, and there is some mechanism for ensuring that code won't run unless at least version x of the .NET framework exists, then it will be much better.
Even a broken clock is right twice a day.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
