To MFC Or Not To MFC

[wey97]

Hi all.

I've become quite comfortable with Win32 API programming but
have found it extremely time consuming and frankly impossible to
do more advanced controls like the Outlook style ListView and
Toolbar. I'm considering using MFC to try this but I'm worried
about the issue of MFC and the run-times, especially since there's
not a standard installation pack like the VB run-times.

Every simple MFC app I've made has never had a problem
running without installing run-times. So, my questions are:

1. Do all MFC apps require the same run-times?

2. Is there a standard set of run-times that guarantees all of your
MFC apps will run smoothly?

[CornedBee]

1) No, you can link statically against the runtimes, then the parts you need are directly included in the exe. Unfortunatly this leads to large exe sizes.

2) There might be, let me check something...
Ok, my rather advanced MFC app built with VC++7 needs these DLLs (those where I know they're part of windows are not listed):
MFC70.DLL
MSVCRT.DLL (VC++6 C-runtime, comes with 98 or NT and higher)
MSVCR70.DLL (VC++7 C-runtime)
GDIPLUS.DLL (installed with XP, but no earlier windows, installed with the .NET framework)
MSVCP70.DLL (VC++7 C++-runtime)
OLEACC.DLL (quite sure this belongs to windows)
RPCRT4.DLL (this too)

Various other DLLs are loaded on request, you only need those if you acturally use something from in there. And I think they're all part of windows anyway.

The dangerous part are the COM DLLs. Those don't show up in the registry as they're only located and loaded at runtime, referenced as GUIDs of contained COM-objects.
There suddenly appear (when watching the loading sequence in the debugger):
nvdesk32.dll (I think that's part of windows)
mfc70xxx.dll (pure resource dlls for various languages)
clbcatq.dll
dao360.dll
msjet40.dll
mswstr10.dll
vbajet32.dll
expsrv.dll
msjtes40.dll

Most of this only because I use DAO