HELP: Problems with MFCxx.DLL 
Author Message
 HELP: Problems with MFCxx.DLL

 Hi all,

I compile and link my code using VC++ 6.0 and link it to 'MFC42.DLL'
dynamically. Of course it doesn't work on machines which don't have
'MFC42.DLL'. Can any one help me to answer following questions?

1) What are the differences between 'MFC42.DLL' and 'MFC40.DLL'?

2)  Is 'MFC40.DLL' always installed on Windows 95/98/2000/NT by default?

2.1) If yes, how can I link my code to 'MFC40.DLL' dynamically using
VC++ 6.0?
2.2) If yes, is it possible to or how to create 'MFC40.lib' from
'MFC40.DLL'?

3) How to load some classes (objects or instances, for e.g.: 'CDialog',
'COleControl', etc) from MFCxx.DLL dynamically? (Assumed that one
wouldn't use MFC  but Win32 programming).

4)  Does MFC40.dll support ActiveX Control?

Any help would be very appreciated.

Best regards,
Jonathan



Sun, 03 Nov 2002 03:00:00 GMT  
 HELP: Problems with MFCxx.DLL
Your install program is responsible for installing the necessary DLLs on the
PC. MFC40.DLL exists on a PC because some time ago an install program such
as Word97 setup placed it there. Therefore it may or may not be on a PC.

MFC42.DLL is Version 4.2 of MFC whereas MFC40.DLL is version 4.0 so you
would have to figure out what the differences are between these two versions
of MFC.

Basically you are approaching the problem from the wrong angle:

- You shouldn't be trying to link to old DLLs which may or may not be on
target PCs.
- You should be distributing the DLLs your program was compiled and linked
with.

A program such as InstallShield distributed on your Visual C++ CD ROM will
enable you to do this and you can replace existing DLLs possessing the same
file name with those that are newer by date and newer bvy version -
preventing the so called DLL Hell.

Unfortunately the installation is often a rush-job and is overlooked ... but
a professional and robust installation will hopefully be the first things
your end-user sees.


Quote:
> Hi all,

> I compile and link my code using VC++ 6.0 and link it to 'MFC42.DLL'
> dynamically. Of course it doesn't work on machines which don't have
> 'MFC42.DLL'. Can any one help me to answer following questions?

> 1) What are the differences between 'MFC42.DLL' and 'MFC40.DLL'?

> 2)  Is 'MFC40.DLL' always installed on Windows 95/98/2000/NT by default?

> 2.1) If yes, how can I link my code to 'MFC40.DLL' dynamically using
> VC++ 6.0?
> 2.2) If yes, is it possible to or how to create 'MFC40.lib' from
> 'MFC40.DLL'?

> 3) How to load some classes (objects or instances, for e.g.: 'CDialog',
> 'COleControl', etc) from MFCxx.DLL dynamically? (Assumed that one
> wouldn't use MFC  but Win32 programming).

> 4)  Does MFC40.dll support ActiveX Control?

> Any help would be very appreciated.

> Best regards,
> Jonathan



Sun, 03 Nov 2002 03:00:00 GMT  
 HELP: Problems with MFCxx.DLL
Hi Robert,

you are right if one deals with the conventional installation using for e.g.
InstallShield. I'm working with automatic download and installation via
Internet so it wouldn't make sense if user had to download 'MFC42.DLL' (about
900 KB).  I could link my code with MFC ('nafxcw.lib') statically but I need to
keep the small size of my code.

Regards,
Jon

Quote:

> Your install program is responsible for installing the necessary DLLs on the
> PC. MFC40.DLL exists on a PC because some time ago an install program such
> as Word97 setup placed it there. Therefore it may or may not be on a PC.

> MFC42.DLL is Version 4.2 of MFC whereas MFC40.DLL is version 4.0 so you
> would have to figure out what the differences are between these two versions
> of MFC.

> Basically you are approaching the problem from the wrong angle:

> - You shouldn't be trying to link to old DLLs which may or may not be on
> target PCs.
> - You should be distributing the DLLs your program was compiled and linked
> with.

> A program such as InstallShield distributed on your Visual C++ CD ROM will
> enable you to do this and you can replace existing DLLs possessing the same
> file name with those that are newer by date and newer bvy version -
> preventing the so called DLL Hell.

> Unfortunately the installation is often a rush-job and is overlooked ... but
> a professional and robust installation will hopefully be the first things
> your end-user sees.



> > Hi all,

> > I compile and link my code using VC++ 6.0 and link it to 'MFC42.DLL'
> > dynamically. Of course it doesn't work on machines which don't have
> > 'MFC42.DLL'. Can any one help me to answer following questions?

> > 1) What are the differences between 'MFC42.DLL' and 'MFC40.DLL'?

> > 2)  Is 'MFC40.DLL' always installed on Windows 95/98/2000/NT by default?

> > 2.1) If yes, how can I link my code to 'MFC40.DLL' dynamically using
> > VC++ 6.0?
> > 2.2) If yes, is it possible to or how to create 'MFC40.lib' from
> > 'MFC40.DLL'?

> > 3) How to load some classes (objects or instances, for e.g.: 'CDialog',
> > 'COleControl', etc) from MFCxx.DLL dynamically? (Assumed that one
> > wouldn't use MFC  but Win32 programming).

> > 4)  Does MFC40.dll support ActiveX Control?

> > Any help would be very appreciated.

> > Best regards,
> > Jonathan



Sun, 03 Nov 2002 03:00:00 GMT  
 HELP: Problems with MFCxx.DLL
OK, if after some amount of time has elapsed without reply I'd repost esp.
to microsoft.public.vc.mfcole perhaps ATL newsgroups might be able to help
although they wouldn't need MFC DLLs. There are quite a few warnings about
producing lightweight ( in the sense of object code footprint ) controls and
using MFC - they don't go hand in hand.


Quote:
> Hi Robert,

> you are right if one deals with the conventional installation using for
e.g.
> InstallShield. I'm working with automatic download and installation via
> Internet so it wouldn't make sense if user had to download 'MFC42.DLL'
(about
> 900 KB).  I could link my code with MFC ('nafxcw.lib') statically but I
need to
> keep the small size of my code.

> Regards,
> Jon

> > Your install program is responsible for installing the necessary DLLs on
the
> > PC. MFC40.DLL exists on a PC because some time ago an install program
such
> > as Word97 setup placed it there. Therefore it may or may not be on a PC.

> > MFC42.DLL is Version 4.2 of MFC whereas MFC40.DLL is version 4.0 so you
> > would have to figure out what the differences are between these two
versions
> > of MFC.

> > Basically you are approaching the problem from the wrong angle:

> > - You shouldn't be trying to link to old DLLs which may or may not be on
> > target PCs.
> > - You should be distributing the DLLs your program was compiled and
linked
> > with.

> > A program such as InstallShield distributed on your Visual C++ CD ROM
will
> > enable you to do this and you can replace existing DLLs possessing the
same
> > file name with those that are newer by date and newer bvy version -
> > preventing the so called DLL Hell.

> > Unfortunately the installation is often a rush-job and is overlooked ...
but
> > a professional and robust installation will hopefully be the first
things
> > your end-user sees.



> > > Hi all,

> > > I compile and link my code using VC++ 6.0 and link it to 'MFC42.DLL'
> > > dynamically. Of course it doesn't work on machines which don't have
> > > 'MFC42.DLL'. Can any one help me to answer following questions?

> > > 1) What are the differences between 'MFC42.DLL' and 'MFC40.DLL'?

> > > 2)  Is 'MFC40.DLL' always installed on Windows 95/98/2000/NT by
default?

> > > 2.1) If yes, how can I link my code to 'MFC40.DLL' dynamically using
> > > VC++ 6.0?
> > > 2.2) If yes, is it possible to or how to create 'MFC40.lib' from
> > > 'MFC40.DLL'?

> > > 3) How to load some classes (objects or instances, for e.g.:
'CDialog',
> > > 'COleControl', etc) from MFCxx.DLL dynamically? (Assumed that one
> > > wouldn't use MFC  but Win32 programming).

> > > 4)  Does MFC40.dll support ActiveX Control?

> > > Any help would be very appreciated.

> > > Best regards,
> > > Jonathan



Sun, 03 Nov 2002 03:00:00 GMT  
 HELP: Problems with MFCxx.DLL
You really should link staticly. It eliminates the problems that you are
experiencing with the DLL, and does not make your code significantly bigger,
since the linker is able to throw out the unused code in the MFC and CRT
libraries. Installing the MFC DLLs is becoming harder all the time, what
with the many versions of them that are floating around, and MS's insistence
that this is now a "core component" and therefore subject to protection
under new versions of Windows.


Quote:
> Your install program is responsible for installing the necessary DLLs on
the
> PC. MFC40.DLL exists on a PC because some time ago an install program such
> as Word97 setup placed it there. Therefore it may or may not be on a PC.

> MFC42.DLL is Version 4.2 of MFC whereas MFC40.DLL is version 4.0 so you
> would have to figure out what the differences are between these two
versions
> of MFC.

> Basically you are approaching the problem from the wrong angle:

> - You shouldn't be trying to link to old DLLs which may or may not be on
> target PCs.
> - You should be distributing the DLLs your program was compiled and linked
> with.

> A program such as InstallShield distributed on your Visual C++ CD ROM will
> enable you to do this and you can replace existing DLLs possessing the
same
> file name with those that are newer by date and newer bvy version -
> preventing the so called DLL Hell.

> Unfortunately the installation is often a rush-job and is overlooked ...
but
> a professional and robust installation will hopefully be the first things
> your end-user sees.



> > Hi all,

> > I compile and link my code using VC++ 6.0 and link it to 'MFC42.DLL'
> > dynamically. Of course it doesn't work on machines which don't have
> > 'MFC42.DLL'. Can any one help me to answer following questions?

> > 1) What are the differences between 'MFC42.DLL' and 'MFC40.DLL'?

> > 2)  Is 'MFC40.DLL' always installed on Windows 95/98/2000/NT by default?

> > 2.1) If yes, how can I link my code to 'MFC40.DLL' dynamically using
> > VC++ 6.0?
> > 2.2) If yes, is it possible to or how to create 'MFC40.lib' from
> > 'MFC40.DLL'?

> > 3) How to load some classes (objects or instances, for e.g.: 'CDialog',
> > 'COleControl', etc) from MFCxx.DLL dynamically? (Assumed that one
> > wouldn't use MFC  but Win32 programming).

> > 4)  Does MFC40.dll support ActiveX Control?

> > Any help would be very appreciated.

> > Best regards,
> > Jonathan



Sun, 03 Nov 2002 03:00:00 GMT  
 HELP: Problems with MFCxx.DLL
...and MS's insistence that this is now a "core component" and therefore
subject to protection under new versions of Windows.

What do you mean by "core component" and subject to protection?  I'm
deciding how to link my program and I'm interested in what you're saying.
Why does this make it harder to install?



Sun, 03 Nov 2002 03:00:00 GMT  
 HELP: Problems with MFCxx.DLL
As I understand it (everyone please jump in if I'm wrong here - )

Win 2000 and, someday, Win ME have a "feature" called "Windows File
Protection", which is designed to prevent third party developers from
overwriting core components. The system maintains a cache of these critical
files - about 160 meg of them - and continuously monitors their states. If
one of these files is overwritten by a third-party installer, the system
silently rewrites it from the cache.

MS has in the past said that MFC42.DLL and MSVCRT.DLL are core components
which should not be overwritten. I believe this means they are protected by
WFP. MS now proposes that, if you need a specific version of one of these
DLLs, you install it in your application's directory, and then jump through
some hoops to let the OS know it should load that copy, rather than the
system copy. Which of course completely negates all of the advantages of
using a DLL in the first place!

This info is based on my reading of a recent issue of Windows Developer's
Journal -


Quote:
> ...and MS's insistence that this is now a "core component" and therefore
> subject to protection under new versions of Windows.

> What do you mean by "core component" and subject to protection?  I'm
> deciding how to link my program and I'm interested in what you're saying.
> Why does this make it harder to install?



Mon, 04 Nov 2002 03:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. HELP: Problems with MFCxx.DLL

2. HELP: Problems with MFCxx.DLL

3. Problem linking with MFCxx.LIB

4. Help with problem when changing output filename for a DLL

5. DLL help needed: string-parameter problem

6. HELP!! Problem with making a DLL call

7. Help: problem with NT DLL RAS routine and DAO

8. Please help Me with my Dll Problem.

9. Please help Me with my Dll Problem.

10. Help! Problems debugging DLL

11. Help: First dll for VB calling, .def file problems

12. Simple DLL problem...can anyone help?

 

 
Powered by phpBB® Forum Software