|
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]
|
|
|
|
|
You'd have to add an option like this:
[ ] What's a "library"?
------- 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:
[ ] What's a "library"?
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
and Whats Programming? 
|
|
|
|
|
Yeah, with some of the new clientele, that's a viable question.
------- 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
|
|
|
|
|
|
Good one. Perhaps we need "John Simmons / outlaw programmer" as an option in every survey from now on. 
Even a broken clock is right twice a day.
|
|
|
|
|
peterchen wrote:
like "[ ] But VB is better than COBOL!"
just kiddin'
Yeah, COBOL is far better 
Holy Sh*t! I'm speechless. (hey, that's a first) Marc Clifton, The Lounge
|
|
|
|
|
Like any of us C++ guys are worried about that...
------- 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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
