|
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.
|
|
|
|
|
Navin wrote:
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.
An associated .config file to the app can rule this, but only if the developer knows how to handle it properly. Most of the time, and that's the default behavior as well, end-users are required to have the same .NET run-time build than the one used by the developer to compile his code against. Which means x can be either very old, or very new compared to the one currently installed on the end-user machine. Potentially sucks.
|
|
|
|
|
I don't do .NET...
And if you're not working with the end-user in mind, what's the freakin point?
------- 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:
I don't do .NET...
You make it sound like Heroin. 
|
|
|
|
|
I'm defintely on the side of throwing the DLLs to the four winds. More files to install means more problems for the user and the support department, as well as those setting up test environments! I like the idea of a reasonable (ok, smallish) sized application shipping in as few files as possible, preferably one.
* Help, something's gone wrong!
* What version do they have?
Do you want a single answer to the above or any number of combinations of different executables and DLL versions.
*climbs off soapbox*
|
|
|
|
|
John Simmons / outlaw programmer wrote:
if the DLL was loaded by another app and that app is still running.
Not exactly. If interface of function or class in that DLL has been changed, new application will run a new DLL, and won't use the old one with old interface
Philip Patrick
Web-site: www.stpworks.com
"Two beer or not two beer?" Shakesbeer
|
|
|
|
|
Exactly - when I use MFC (which is less and less these days), I always statically link. Unfortunatley, some legacy code around here links dynamically, and can be difficult to change. Especially when some other team owns the code. 
Even a broken clock is right twice a day.
|
|
|
|
|
It is also entirely possible that dtSearch just redirected the shell command for DSW files? I could see someone using DSW to mean 'Dt Search Workfile' or something like that, so of course, trying to double-click on a DSW file results in no activity, or something wierd with dtSearch occuring.
One of these dyas, lazy programmers will get of their collective asses and realize Windows has been supporting file extensions longer than 3 characters since Windows 95 
C++/MFC/InstallShield since 1993
|
|
|
|
|
I know that, you know that, pretty mucvh everyone here knows that... But does Microsoft realise it? How many current microsoft products still use 3-character extensions and how many strangely call all their internal files by 8.3 names? Do they know somethign we don't perhaps...?
Rog
|
|
|
|
|
No, VC 6 runs (but I did check the registry just to be sure). VC 6 runs, then blows up. 
--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
|
|
|
|
|
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.
This sounds more like the mapping of file extension to application got broken, not a DLL problem. Maybe dtSearch assigned the DSW extension to something else.
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
|
|
|
|
|
No, VC 6 runs (but I did check the registry just to be sure). VC 6 runs, then blows up. 
--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
|
|
|
|
|
|
CHRIIIS??? Could we please add an "VB weenie" option to all future surveys? This makes them happy, those cute little critters...
like "[ ] But VB is better than COBOL!"
just kiddin'
Those who not hear the music think the dancers are mad. [sighist] [Agile]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
