Betsy,
The file MFC42.DLL is part of a set that comes with any program built
with
the Microsoft Foundation Classes v4.2 - in fact is the main DLL file with
that set. On my Windows NT 4.0 (Workstation) installation, that file, same
internal version, is already present in the ...\Windows\System32 directory.
But the ADSM backup/archive client for Windows32, v3.1, does have those
files included with it. On my system, these files were installed in
C:\Program Files\ADSM\shared :
CTL3D32.DLL v 2.31.000
MFC42.DLL v 4.2.6068
MSVCRT.DLL v 4.20.6164
MSVCRT40.DLL v 4.10.6038
OLEPRO32.DLL v 4.2.6068
I don't know if they would also be installed under the Windows 95
installation, but I suspect they are. But probably your trouble would then
be that the standard search of directories (to get DLLs) doesn't include
the ...\ADSM\shared directory. So, yes, you would need to make sure a copy
of those files is in the \Windows95\System directory - maybe just by
copying them from \ADSM\shared .
Since your client installs ADSM on a server, it might also work just as
well to put MFC42.DLL, or any other of those files that are missing,
actually in the ...\ADSM directory on the server. What's needed is to get
those files into any of the directories that applications search while
looking to load DLLs. I don't know the exact sequence - and it differs by
operating system - but that search set always includes the current
directory, the directory the application ran from, \Windows (or
\Windows95), and \Windows\System32 ( "\Windows\System" under Win95 ).
However, you want to be careful! Hopefully you are familiar with the
problem of "DLL skew", where application installations can carelessly
overwrite newer versions of the same-named DLL with an older version. This
is a possible problem with all applications - even ones from Microsoft.
When an application overwrites a DLL that was already present, the new
instance may be newer or older in version number, and this may cause other
applications to behave strangely, in subtle or obvious ways.
To test in advance whether this will happen, we use a test machine that has
our standard setup of applications already installed, and install the
suspect application under the control of a utility called Inctrl3 (freeware
from PC Magazine). Inctrl3 can tell you nearly all changes to files and
Registry that an application causes when installed. In this way, we can
see what "common" DLLs are changed and delve deeper when we discover
suspicious changes and DLLs overwritten - BEFORE the application screws up
any production system.
On my production WindowsNT 4 (SP3) systems, the above files have the almost
exact same version nos as the same-named files already on my system. So I
just delete them from ...\ADSM\shared . But you will want to check
versions of these files on *your* Win95 and WinNT systems, and do testing
if ADSM tries to install newer or older versions.
I'd be glad to discuss this further if you have any questions... my phone
number is in the signature.
Tony
=======================
At 07:40 AM 3/25/98 -0600, you wrote:
>A client of mine recently pulled down ADSM V3 Client for Windows to an NT 4.0
>server. She ran the unpacksb.bat and then ran setup and installed the
>software on a drive on her server. She then spent the day setting up her own
>machine to run the client from the server and everything was fine.
>
>She then ran setup again and installed it on a different drive on the same NT
>server that was set up for her specifically for this purpose. Everything on
>her machine ran fine.
>
>She then set up the other workstations in her area to access ADSM on the
>server. Some of the workstations gave her an error because she didn't have
>mfc42.dll installed anywhere. Further investigation showed that the
>workstations that worked (hers included) had this file on their workstations
>in the Windows95\System subdirectory, but the ones that didn't work didn't
>have this file on their workstations. When she copied mfc42.dll onto their
>hard drives, everything worked fine.
>
>Does this file have to be present on the workstations themselves? I'm
>assuming ADSM doesn't load this onto their workstations. Is there something
>we should be doing differently in the setup process? Should I tell her she's
>going to have to copy this file to any workstations that don't already have
>it?
>
>As always, thanks for your help.
>
----------------------------------
Tony White, Research Scientist II Tony.White AT gtri.gatech DOT edu
Tony White, Research Scientist II Tony.White AT gtri.gatech DOT edu
GTRI Computer Coordinator (404) 894-8157 fax: 894-9337
GT/GTRI/AIST, Atlanta, GA 30332-0816
"Optimist: a Yugo owner with a trailer hitch."
|
