Re: Building an app on VC8 for Win2000

From:

David Wilkinson <no-reply@effisols.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Thu, 08 Jun 2006 17:17:22 -0400

Message-ID:

<uDPEpD0iGHA.3440@TK2MSFTNGP02.phx.gbl>

Jo wrote:

David Wilkinson wrote:

Jo wrote:

Norbert Unterberg wrote:

Jo schrieb:

I'd say use VC8 in it's default setup, and put a

What do you mean by that? I've put all those references to the PSDK
include directories to the bottom of the list, so that that VS ones are
searched first.

Yes, I meant use the header files and libraries that came with VS2005.

#define WINVER 0x0500 // Win2000 compatible code only

at the beginning of your stdafx.h file.

I've changed all the WINVERs (and _WIN32_WINNTs) to 0x0500. The
dependency walker confirms that my executable still needs mfc80.dll,
and so does this Win2000 box I've got here.

In your original post you had problems compiling, not running your
application. So you are a step farther. The WINVER and _WIN32_WINNT
defines just make sure that you do not use windows API functions that
are not available in earlier windows versions.

When you configure your project to use MFC as a dynamically linked DLL,
then of course you need to redistribute and install MFC on your target
system. That is a work that every windows application developer needs to do:
* validate what other modules your application depends on
* check which of the modules are always available on the target
(example: DAO is always available on Win2k but needs to be installed on
WinNT4)
* distribute the missing components with your application's installer
or setup instructions. If you are not allowed to distribute, then list
them in your documenation, or tell the user how to get and install the
missing components.

The files that you are allowed to redistribute can be found in the
"Microsoft Visual Studio 8\VC\redist" folder of your visual studio
setup. MFC80.dll is one of them.

MFC80.dll is a dependency that comes when using MFC version 8 in your
project. If this is the only dependency, and if you want your
application to be able to run without install, then configure at least
your release build to link to the static version of MFC. You find that
switch in your project's configuration properties, in the "General"
section, "Use of MFC".

I was hoping to build against the DLLs that are available with
2000, but if redistribution is what people usually do in this
situation, then ok. Thanks.

Jo:

Have you thought about using static linking? In that case you do not
need any MFC or CRT DLL's at all. This is much the easiset way to go
when your app is just a single .exe (and often, IMHO, even when it isn't).

No, I hadn't. I guess it makes more sense than to have a big cow of
an install file, with all those DLLs. But static linking... I've never
done it Microsoft's libs before, because I expected it to link too
much, i.e. things that would already be in DLL-form on the target
system. I didn't even install the static libs when I installed Visual.
How easy is it to selectively link staticly w/MFC, CRT, and whatever
else?

Jo:

In VS2003 (probably similar in VS2005), in your Project properties,
select the first General category, and select "Use MFC in Static
Library" for your Release build. I think this should automatically set
the corresponding CRT library, but you can check under C/C++ -> Code
Generation -> Runtime library. It should be set to "Multi-threaded
(/MT)". Then rebuild. Your .exe will be bigger, but your total
deployment will be much smaller (if you only have a single .exe).

David Wilkinson