MFC compatibiliity

[noble]

I'm starting to develop an app using MFC. I have a few questions
regarding compatibility and runtimes....

1) does everyone normally have the runtimes necessary to
run an MFC app or do they have to be included with the program
like vb programs ? If so, will statically linking MFC solve this
problem?
2) If i create an MFC app with VC++5, will users having a newer
mfc*.dll have any problems?
3) Are there any other downsides to using MFC as opposed to
using pure Win32 API?

The bottom line is I do'nt want to create any application that
will require me shipping runtimes. I believe I'm passed the
stage of infancy where VB is the route to go (instead of the need
for quick and dirty apps or a quick DB app) and I'm familiar enough
with C++ to port my vb programs to win32 C++.

Thanks for any help.

[FantastichenEin]

1) It is never certain that the target will have a dll. Even if they do, it could prove to be incompatable. Static linking will solve this problem. It will increase the size of your EXE though.

2) Should be, but not a certainty. You can never be totally sure about dll's on target machines. Either static link or distribute the dll's. The only downside to static linking mfc is the increased file size, i doubt the increase will be as much as the dll size though.

3) I expect there is a slight speed decrease using MFC but it is probably unnoticable. MFC is basically an OO wrapper for the some of the API after all.
If you find you are getting on OK with MFC, carry on learning it and then move to wxWindows, basically a stable version of MFC with much the same code.

[noble]

thx,
MFC is easier than some ppl may think when you already have
most of the basic OO knowledge. It seems too good to be true
in some aspects. I've spoken to ppl who have complained about
using it. Are there things you CAN'T do with MFC since a lot of the
functionality is hidden? or can everything be accessed through
inheritance?

[FantastichenEin]

I think you can do most things with MFC using inheritance and subclassing. I don't touch mfc anymore, I never built anything that tested it's abilties very far, parksie may know the limitations.

The thing that a lot of programmers are annoyed with is the amount of base code that is put in to be able to even use it (i.e. you cannot create an mfc app from scratch you must use the App wizard thing). The added code can be quite obscure, meaning that you just have to accept the code is there, but not understand what it does.

[CornedBee]

There is absolutely nothing you can't do in a MFC app, although there are some very exotic things you can't do with MFC. Understand what I mean? You can always access the windows API directly.

About runtimes:
Basically all MFC runtimes are installed with Windows. If you use new versions of MFC, there may be some users that don't have those runtimes, but basically you can assume that the end user has the library. Dynamic linking is recommended. If you distribute your app on a CD it doesn't hurt to include the DLL as space is usually not an issue. If you let people download it, they should be able to run it, but you should make the DLLs available as a seperate download. Linking statically in this case would probably be a failure as it dramatically increases EXE size.

MFC runtimes are never incompatible. If you look at your windows/system directory, you'll find several versions of the MFC dlls. Every version of MFC has it's own dll name. I have 14 different dlls (not counting the debug versions installed with VC++).

[noble]

thx for the input fellas, just what i was looking for