ADSM-L

Re: mcf42.dll - where does it come from?

2015-10-04 18:00:06
Subject: Re: mcf42.dll - where does it come from?
From: owner-adsm-l (INTERNET.OWNERAD) at SNADGATE
To: Jerry Lawson at ASUPO
Date: 3/25/98 11:32AM
Also, is there a more subtle problem here in that while the Win32 clien=
t
supports both NT and Win95, is the installed code correct for BOTH plat=
forms.
I know that when it comes up it names the appropriate platform (at leas=
t the
V2 client did - the V3 client makes no mention of the platform in the s=
plash
screen).  In other words - is the install portable - can I take an NT
install, and move it to a Win95 machine, or point to it and run, or sho=
uld it
be installed from the same OS?

Jerry Lawson
jlawson AT thehartford DOT com


______________________________ Forward Header
__________________________________
Subject: Re: mcf42.dll - where does it come from?
Author:  owner-adsm-l (INTERNET.OWNERAD) at SNADGATE
Date:    3/25/98 11:32 AM


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 fi=
le with
that set.  On my Windows NT 4.0 (Workstation) installation, that file, =
same
internal version, is already present in the ...\Windows\System32 direct=
ory.
 But the ADSM backup/archive client for Windows32, v3.1, does have thos=
e
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 includ=
e 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 copyi=
ng
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 insta=
nce
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 (free=
ware
from PC Magazine).  Inctrl3 can tell you nearly all changes to files an=
d
Registry that an application causes when installed.  In this way, we ca=
n see
what "common" DLLs are changed and delve deeper when we discover suspic=
ious
changes and DLLs overwritten - BEFORE the application screws up any
production system.

On my production WindowsNT 4 (SP3) systems, the above files have the al=
most
exact same version nos as the same-named files already on my system.  S=
o 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 testi=
ng
if ADSM tries to install newer or older versions.

I'd be glad to discuss this further if you have any questions... my pho=
ne
number is in the signature.

Tony
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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.   Everyt=
hing on
>her machine ran fine.
>
>She then set up the other workstations in her area to access ADSM on t=
he
>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 workst=
ations
>in the Windows95\System subdirectory, but the ones that didn't work di=
dn'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 som=
ething
>we should be doing differently in the setup process?  Should I tell he=
r 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: 89=
4-9337
GT/GTRI/AIST, Atlanta, GA  30332-0816

"Optimist:  a Yugo owner with a trailer hitch."


=