(we include in on CDs and DVDs to restore files). I decided to try
program size. I was able to create the whole (albeit reasonably generic)
program in less than 400K file size. I'm not sure how much shared memory is
Uwe and Tom - thanks for the replies.
I think I'm persuaded by Tom that I should probably switch to static
linking. I'm used to thinking of it as wasteful and being a bit of a
recycler it goes against the grain; but it probably does make sense. I'm
not running multiple apps - just the one standalone app.
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.
Well I've used VC6 and I found that marginally better than VC5 but for my
purposes, the differences were so slight that it was barely worth
upgrading (and I'd have to do a lot of regression testing - there are some
differences which could result in bugs).
After VC6, I got the impression that MS lost interest in C++ and MFC and
became obsessed by Java, C# and .net - none of which are relevant to my
rich client app. Also, I have always loved the IDE that you get with VC5
and VC6 and what I heard about the later IDE made it sound like a big step
backwards (I always loathed the Visual Basic IDE, and I gathered it was
based on that). But perhaps I'm wrong. Go ahead - tempt me. What
improvements are there that would be of value to someone like me?
Simon
"Tom Serface" <tom.nospam@camaswood.com> wrote in message
news: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.