Re: VC++ 5 Q. - Shared DLL vs. statically linked lib?

From:

"Tom Serface" <tom.nospam@camaswood.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Wed, 7 Mar 2007 07:11:17 -0800

Message-ID:

<04D4E4E6-464D-40C1-B4DD-499C6ABE6D4D@microsoft.com>

You could easily statically link it in this case if you don't want to use
DLLs. Every once in a while a discussion starts up here about the
benefits/detriments of static vs. dynamic linking. Unless you are running
multiple applications that would use the DLL I don't think it would make
much difference and you might want your application to be more standalone
anyway just in case the world changes and your program continues to use the
old paradigm.

Is there some reason you can't update your program to the later version of
VC++. I think you'd find there are lots of improvements.

Tom

"Simon" <sorde@gotadsl.co.uk> wrote in message
news:RuSdnUDM-PeeG3PYRVnyigA@pipex.net...

When I say VC++ 5 - I mean it. I don't mean Visual Studio 2005. This is
Visual Studio 97 or something. So cast your mind back.

I use the MFC. When given the choice of having a statically linked lib or
using a shared DLL, for the MFC library, I have always up to now used a
shared DLL for my standalone app - based mainly on a vague feeling that it
might load faster (or already be loaded), and use less memory. But I have
finally had one user who has a problem that I believe is based on his
having
an updated MFC DLL (i.e. a "DLL Hell" problem).

I presume there are 3 options available to me (for the future):

(a) Continue as now - use a shared DLL, properly installed, and don't
worry
about it
(b) Use a static lib
(c) Use the shared DLL for the MFC but put the MFC dll in my app's
directory, with a file that has the same name as my app, but with a .local
suffix - e.g. "MyApp.exe.local" (i.e. use "DLL/COM" Redirection).

Anyone got any suggestions about the relative merits of these options?
Thanks in advance.

Simon

P.S. I'm hoping to upgrade to VC++ 6 any year now. S.