Prev: Property Sheet Problem
Next: CToolTipCtrl pointer or non-pointer member variable
From: JCO on 22 Apr 2010 13:51
VS 2008; C++
When creating a dialog application using MFC, I have the option to:
1. Use MFC in a Shared DLL
2. Use MFC in a Static Link DLL

Can someone tell me the difference in the two?
Can I change from one to the other while I'm still have programming to do?
Will one of these options allow my Released Version of my Executable to run
on another computer alone (without transferring a DLL to the other
computer)?

Also; if I need to take DLL's with me to run my dialog, how can I tell what
DLL's I need?
Thanks


From: David Ching on 22 Apr 2010 14:18
"JCO" <someone(a)somewhere.com> wrote in message
news:eTF5sRk4KHA.3880(a)TK2MSFTNGP04.phx.gbl...
> VS 2008; C++
> When creating a dialog application using MFC, I have the option to:
> 1. Use MFC in a Shared DLL
> 2. Use MFC in a Static Link DLL
>
> Can someone tell me the difference in the two?

Static linking puts all the MFC code into your .exe. Shared DLL has the MFC
code in the other DLL's which you must distribute along with your .exe. If
you are creating additional MFC DLL's besides your .exe, you will need to
use shared dll, static linking is not an option (and you wouldn't want to
put MFC into both the .exe and .dlls anyway as that is wasteful).


> Can I change from one to the other while I'm still have programming to do?

Sure, I think you will find it doesn't really matter which one you use for
programming.


> Will one of these options allow my Released Version of my Executable to
> run on another computer alone (without transferring a DLL to the other
> computer)?
>

Static linking obviously is easier, you only have to distribute your single
..exe and that's it. Shared DLL's is not much harder using "app local
deployment" - you can create one folder containing both your .exe and the
MFC DLL's. There are further options to use .msi merge modules or
vc_redist.exe to globally install the DLL's onto the user's windows\system32
folder, but that requires use of an installer and is more complicated than
the first options that only need xcopy deployment.


> Also; if I need to take DLL's with me to run my dialog, how can I tell
> what DLL's I need?

Run depends.exe (google it). Also to make sure, I use a virtual machine
containing only the OS installed and no apps and make sure my app runs in
it.

-- David

From: ab` on 22 Apr 2010 14:24
There's a thread on the topic titled "Static linking to MFC/CRT and
Standard C++ libraries" from April 8th in:

microsoft.public.vc.language
From: John H. on 22 Apr 2010 14:42
On Apr 22, 12:51 pm, "JCO" <some...(a)somewhere.com> wrote:
> VS 2008; C++
> When creating a dialog application using MFC, I have the option to:
> 1. Use MFC in a Shared DLL
> 2. Use MFC in a Static Link DLL
>
> Can someone tell me the difference in the two?

A library is a collection of functions/objects/etc. that another
program can use, in this case MFC. You have an application that uses
MFC, and it needs to know what exactly to do when it uses MFC
functionality. These are two different ways that it can "find out
what to do".
A DLL stands for dynamic linked library. In this case, the "what to
do" is not included in the binary of the application itself. Instead,
it lives in its own binary (the dll). When the application runs, it
tells the operating system "I need to get at this library". The OS
will then make available that library to the application.
A statically linked library is one where the "what to do" is included
in the applications binary. It doesn't need to look elsewhere to get
the functionality.

DLL pros:
- Smaller application binary. Since the application relies on the
library existing elsewhere, it doesn't need to include it.
- More efficient use of computer resources. Say there exist three
applications running on the PC that dynamically use the library. Each
will ask the operating system to make available the library. The
operating system can load the library just once, and make it available
to all three applications.

DLL cons:
- Application distribution. Now the full functionality of your
application is not in one binary. You can give someone your
application binary, and it is not all they need to run it. They have
to somehow have the DLL also. You can provide this to them as a
separate binary from your main application or you can depend on the
fact they have happen to have a copy of that DLL already. For MFC,
you get a little lucky because it is a Windows library and I think
ships with most versions of Windows anyways, so you don't have to
worry if they have it.
- Clean up. Say the user uses your application and a DLL you
provide. Sometimes the DLL goes into the Windows folder. They now
decide they are done with your application, They know to delete your
application, but now they have a DLL. The problem is that other
applications may also use that DLL because it is a "shared" concept.
Deleting it might break other programs.
- Versioning. Libraries evolve and different versions come out. Some
software may require version 1.01 of a DLL while another wants version
1.02 of the DLL. It is possible for these two libraries to live
together at the same time, but some care is needed for the library
developer and OS to know that they are two different libraries that
offer (slightly) different functionality. I am not sure how good
Windows is at this, it is probably not a very big issue.

Static link pros (mostly just the opposite of DLL cons):
- Application distribution. The full functionality of your
application is included in one binary. You can give someone your
application binary and it is all they need to run it.
- Clean up, The user is done delete your application binary and not
have to be bothered if there are now un-used DLLs laying somewhere
that they could get rid of. (Although other types of files could be
there, logs, help files, changes to the registry, etc.)
- Versioning. Since the application is self-contained, you know the
right version of the library will be used and it will not interfere
with any other application running.

Static link cons (mostly just the opposite of DLL pros)::
- Bigger application binary. All the functionality needed from the
library must be included in the application binary itself. Depending
on the library/compiler it may only need to include the parts of the
library that you actually use rather than the entire library.
- Less efficient use of computer resources. Say there exist three
applications running on the PC that statically use MFC. Each will
have there own copy of MFC fighting over memory. This can lead to
more paging, etc.

> Can I change from one to the other while I'm still have programming to do?

Yes. Usually only requires a change in the build configuration. Your
code should be able to be the same.

> Will one of these options allow my Released Version of my Executable to run
> on another computer alone (without transferring a DLL to the other
> computer)?

Static link library lets you do this. Although in some situations,
that other computer might already have the dll, and in that situation
you also would not have to trasfer the dll. Since MFC is a popular
library, there is a pretty good chance the other computer has it.
Also to keep in mind, is that MFC might not be the only library that
is needed. For instance, the C++ standard library faces the same
questions. You can pick and choose between statically and dynamically
linking the libraries.

> Also; if I need to take DLL's with me to run my dialog, how can I tell what
> DLL's I need?

Try searching for a MS application called "dependency checker". You
will probably be surprised at the number of libraries you are
dependent on. Although again, a lot of these are going to be Window
libraries and very likely to be on the destination machine anyways.

Take my words with caution, I am not expert on this stuff!
From: JCO on 22 Apr 2010 17:37
Thanks everybody for the help. I figured out, in the configuration
Properties how to change my dialog from a Shared DLL to Static. That's all
I need to do right now.
Thanks again.

"John H." <oldman_fromthec(a)yahoo.com> wrote in message
news:e19781c3-0328-44f6-8ead-23a8c91d1721(a)11g2000yqr.googlegroups.com...
> On Apr 22, 12:51 pm, "JCO" <some...(a)somewhere.com> wrote:
>> VS 2008; C++
>> When creating a dialog application using MFC, I have the option to:
>> 1. Use MFC in a Shared DLL
>> 2. Use MFC in a Static Link DLL
>>
>> Can someone tell me the difference in the two?
>
> A library is a collection of functions/objects/etc. that another
> program can use, in this case MFC. You have an application that uses
> MFC, and it needs to know what exactly to do when it uses MFC
> functionality. These are two different ways that it can "find out
> what to do".
> A DLL stands for dynamic linked library. In this case, the "what to
> do" is not included in the binary of the application itself. Instead,
> it lives in its own binary (the dll). When the application runs, it
> tells the operating system "I need to get at this library". The OS
> will then make available that library to the application.
> A statically linked library is one where the "what to do" is included
> in the applications binary. It doesn't need to look elsewhere to get
> the functionality.
>
> DLL pros:
> - Smaller application binary. Since the application relies on the
> library existing elsewhere, it doesn't need to include it.
> - More efficient use of computer resources. Say there exist three
> applications running on the PC that dynamically use the library. Each
> will ask the operating system to make available the library. The
> operating system can load the library just once, and make it available
> to all three applications.
>
> DLL cons:
> - Application distribution. Now the full functionality of your
> application is not in one binary. You can give someone your
> application binary, and it is not all they need to run it. They have
> to somehow have the DLL also. You can provide this to them as a
> separate binary from your main application or you can depend on the
> fact they have happen to have a copy of that DLL already. For MFC,
> you get a little lucky because it is a Windows library and I think
> ships with most versions of Windows anyways, so you don't have to
> worry if they have it.
> - Clean up. Say the user uses your application and a DLL you
> provide. Sometimes the DLL goes into the Windows folder. They now
> decide they are done with your application, They know to delete your
> application, but now they have a DLL. The problem is that other
> applications may also use that DLL because it is a "shared" concept.
> Deleting it might break other programs.
> - Versioning. Libraries evolve and different versions come out. Some
> software may require version 1.01 of a DLL while another wants version
> 1.02 of the DLL. It is possible for these two libraries to live
> together at the same time, but some care is needed for the library
> developer and OS to know that they are two different libraries that
> offer (slightly) different functionality. I am not sure how good
> Windows is at this, it is probably not a very big issue.
>
> Static link pros (mostly just the opposite of DLL cons):
> - Application distribution. The full functionality of your
> application is included in one binary. You can give someone your
> application binary and it is all they need to run it.
> - Clean up, The user is done delete your application binary and not
> have to be bothered if there are now un-used DLLs laying somewhere
> that they could get rid of. (Although other types of files could be
> there, logs, help files, changes to the registry, etc.)
> - Versioning. Since the application is self-contained, you know the
> right version of the library will be used and it will not interfere
> with any other application running.
>
> Static link cons (mostly just the opposite of DLL pros)::
> - Bigger application binary. All the functionality needed from the
> library must be included in the application binary itself. Depending
> on the library/compiler it may only need to include the parts of the
> library that you actually use rather than the entire library.
> - Less efficient use of computer resources. Say there exist three
> applications running on the PC that statically use MFC. Each will
> have there own copy of MFC fighting over memory. This can lead to
> more paging, etc.
>
>> Can I change from one to the other while I'm still have programming to
>> do?
>
> Yes. Usually only requires a change in the build configuration. Your
> code should be able to be the same.
>
>> Will one of these options allow my Released Version of my Executable to
>> run
>> on another computer alone (without transferring a DLL to the other
>> computer)?
>
> Static link library lets you do this. Although in some situations,
> that other computer might already have the dll, and in that situation
> you also would not have to trasfer the dll. Since MFC is a popular
> library, there is a pretty good chance the other computer has it.
> Also to keep in mind, is that MFC might not be the only library that
> is needed. For instance, the C++ standard library faces the same
> questions. You can pick and choose between statically and dynamically
> linking the libraries.
>
>> Also; if I need to take DLL's with me to run my dialog, how can I tell
>> what
>> DLL's I need?
>
> Try searching for a MS application called "dependency checker". You
> will probably be surprised at the number of libraries you are
> dependent on. Although again, a lot of these are going to be Window
> libraries and very likely to be on the destination machine anyways.
>
> Take my words with caution, I am not expert on this stuff!

 |  Next  |  Last
Pages: 1 2 3 4
Prev: Property Sheet Problem
Next: CToolTipCtrl pointer or non-pointer member variable