Re: Help please: How do I redistribute system files with VC++ 6 Service Pack 6?
Note that for several years now, the System32 folder has been considered the domain of the operating
system (XP and later), and the OLD advice of installing files into it is deprecated. The System32
files MFC42.dll and MSVCRT.DLL now belong to Windows, and they are maintained by the OS product
group. The VC++ libraries group stopped supporting those files (along with VC++ as well) many years
ago. If you run a vcredist installer on a machine that has been getting Windows Updates, it's
likely that the DLLs in the system folder supercede the ones in the vcredist, and they won't be
installed. Older OS's (like 2000 and ME) don't support the vcredist installation method, so you are
stuck with manually installing the files there. But anyone still running 2000 or ME these days is
likely plagued with a host of other worries, so what's one more?
Are you sticking with VC++ 6.0 because of the cost of upgrading, or do you have some other reason?
Also, you may find the Dependency Walker tool very helpful in answering these types of questions.
(It's free):
Dependency Walker (depends.exe) Home Page:
http://www.dependencywalker.com/
"Simon" <Simon2@newsgroup.nospam> wrote in message
news:jMednYOJMt0ZbJzXnZ2dnUVZ8hidnZ2d@pipex.net...
Ajay
Thank you for your reply.
That is what you should be doing. Make sure you have the latest one (SP5?). <<
Well the one I got with SP6 is presumably more recent? Presumably I shouldn't be using anything
more recent than that?
What DLL conflict you think is happening? <<
I don't know that the symptoms I'm hearing about are caused by dll conflicts. I just wondered if
they might be. Some users are seeing some weird text effects which they see all the time, and
I've never seen, for example.
The link you gave says that "This package does not install these components on computers that are
running Microsoft Windows 2000 or Microsoft Windows Millennium (Me) systems. On computers that are
running Windows 2000 and Windows Millennium, these components can only be updated through
operating system updates and service packs for these operating systems. " So what does that mean?
What am I supposed to do with Windows 2000 and ME?
In VC6, you could put the DLLs in your directory and it will pick those up regardless. <<
I was very surprised to hear that, but I tested it with MFC42.DLL and MSVCRT.DLL on Windows XP.
The local version of MFC42.DLL was indeed loaded, but the MSVCRT.DLL one wasn't. Still - it could
be useful as a way of testing whether the problem is caused by the 'wrong' MFC42.DLL.
Simon
"Ajay" <ajaykalra@yahoo.com> wrote in message
news:181e114c-6445-4117-9455-9aa9192693b6@r3g2000vbp.googlegroups.com...
(1) Should I be running the vcredist.exe to distribute system dlls?
That is what you should be doing. Make sure you have the latest one
(SP5?). More here:
http://support.microsoft.com/kb/259403
should I just pull out the most recent versions of MFC42.dll and MSVCRT.DLL
from redist.exe (it can be opened using winzip) and redistribute them? If
not, what should I be doing?
I wouldnt do it this way. vcredis.exe is the way to do it correctly.
(2) Is there anything else I can do to reduce of dll conflicts? I thought
about a side-by-side assembly, but now am not sure even which dlls to do it
with, given that vcredist.exe redistributes several (and I would need help
on what I need to do if I were to give that a go)
What DLL conflict you think is happening? In VC6, you could put the
DLLs in your directory and it will pick those up regardless. Is it
because you think MFC42DLL your app is picking is somehow corrupt?
--
Ajay