MFC belongs to a category of software called application frameworks. Of course, if you've never used an app framework before, that statement probably doesn't tell you much.
What exactly is an app framework?
Consider the process that you go through when you write a Windows application in C using the Windows SDK. You produce a source-code module that contains WinMain() (the starting point of all Windows programs). You write code to initialize your application, followed by a message loop (which never seems to change much, regardless of the type of program that you are writing). You register your window classes (with RegisterClass()) and write a window callback procedure (otherwise known as a WndProc) for each window class that you create. If your program uses dialog boxes, you create them either by using some sort of resource editor or by writing the .RC file by hand. Then you write a dialog procedure (or DlgProc) for each dialog box. Then you must hook the dialog procedure to your code so that it displays at the appropriate time. In your window procedures, you create a large switch statement, with a case statement for each message from Windows that you expect to handle. For each case statement, you must remember how to break apart the parameters that Windows passes to you (in the LPARAM and WPARAM variables), making sure that you pass back the right value to Windows (or calling DefWndProc, if necessary). If you had done some exploring in the header files provided with your C++ compiler, you might have discovered windowsx.h (which contains Microsoft's "message crackers") and used those to help you obtain values from the variables that Windows passes to you.

After going through this process a few times, most programmers go into "cookie-cutter" mode, in which you simply modify a previously written program to match your current need. The Windows SDK's Guide to Programming manual (supplied with earlier versions of Windows SDKs) and other popular Windows books taught this method of Windows program development, in which you have to examine each program to find the exact differences among them.
After using this programming method a while, you notice that you spend much of your time just setting down your programs' basics, which almost always look the same. At this point, you create a do-nothing program with which you can start any project. Also, after examining the code that you write, you notice all the silly rules that you have to remember[md]such as "use CreateBitmap() to create a bitmap, but use DeleteObject() to get rid of it" and "make sure that you use BeginPaint() and EndPaint() in your WM_PAINT code so that you won't confuse Windows."

If this sounds familiar to you, you probably wonder whether a better method exists. Why do you have to remember all these details? That is the job for which application frameworks were designed. Instead of making you churn out the same code every time that you start an application, a framework provides the "core components" that you need for every application that you write.
Frameworks actually perform two functions: defining the behavior of a basic application, and (under Windows) providing a class-based interface to the underlying API (the Windows API). Because a framework defines a basic application, you can write a simple program with very little code. The framework provides the application's default behavior, which your program simply inherits. When you want your program to do something different, you can override (or extend) the functionality that the framework provides. In the case of a C++ app framework, you can inherit large amounts of work from the framework