MFC vs Win32 API

Analogy categoryAnalogies

The Win32 API is the low-level, C-based interface that Windows itself exposes for creating windows, handling input, drawing graphics through GDI, and managing system resources; every GUI framework on Windows, including MFC, WPF, and WinUI, ultimately sits on top of it somewhere. MFC does not replace Win32 - it wraps a large, commonly used subset of it in C++ classes, so a developer can call CWnd::MoveWindow() instead of MoveWindow(hwnd, x, y, w, h, TRUE), while still being able to drop down to the raw HWND or HDC whenever the wrapped API doesn't cover a particular need.

🏏

Cricket analogy: Win32 is like the raw laws of cricket as written by the MCC - every format (Test, ODI, T20) ultimately obeys them, the same way MFC, WPF, and WinUI all ultimately sit on top of the same Win32 primitives.

What Raw Win32 Programming Looks Like

In pure Win32 C, creating a window requires filling out a WNDCLASSEX structure, calling RegisterClassEx, then calling CreateWindowEx with a long list of positional parameters, and finally implementing a global or static WndProc callback that receives every message (WM_PAINT, WM_DESTROY, WM_LBUTTONDOWN, and dozens more) as raw integer and pointer parameters that must be manually cast and interpreted, with the developer responsible for calling DefWindowProc for anything not explicitly handled.

🏏

Cricket analogy: Filling out a WNDCLASSEX structure before RegisterClassEx is like a team submitting a detailed playing XI form to match officials before a Test starts - every field must be correct and complete before play (window creation) can begin.

How MFC Reduces the Boilerplate

MFC replaces the raw WndProc switch statement with a message map - a table, declared with BEGIN_MESSAGE_MAP/END_MESSAGE_MAP macros, that associates a specific message (or command ID) with a specific member function, so a developer writes OnLButtonDown(UINT nFlags, CPoint point) instead of manually checking 'if (uMsg == WM_LBUTTONDOWN)' and extracting x/y coordinates from LPARAM by hand. The framework's CWnd::Create() and CFrameWnd::Create() member functions also collapse RegisterClassEx and CreateWindowEx into simpler calls with sensible defaults, meaning far fewer lines of code produce the same working window.

🏏

Cricket analogy: A message map routing WM_LBUTTONDOWN to OnLButtonDown is like a scorer's table automatically crediting a boundary to the striker's tally the instant the ball crosses the rope, rather than someone manually cross-referencing footage frame by frame.

cpp

// Raw Win32: handling a left mouse click
LRESULT CALLBACK WndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
    case WM_LBUTTONDOWN:
    {
        int x = LOWORD(lParam);
        int y = HIWORD(lParam);
        // handle click at (x, y)
        return 0;
    }
    case WM_DESTROY:
        PostQuitMessage(0);
        return 0;
    default:
        return DefWindowProc(hwnd, uMsg, wParam, lParam);
    }
}

// MFC equivalent: message map routes the same event to a member function
BEGIN_MESSAGE_MAP(CMyWnd, CWnd)
    ON_WM_LBUTTONDOWN()
END_MESSAGE_MAP()

void CMyWnd::OnLButtonDown(UINT nFlags, CPoint point)
{
    // point.x, point.y already extracted for you
}

Even inside MFC code, you can always retrieve the raw Win32 handle with CWnd::GetSafeHwnd() or the m_hWnd member, and call any raw Win32 API directly when MFC doesn't wrap something you need - the abstraction is additive, not a wall.

Trade-offs to Consider

Raw Win32 gives maximum control and the smallest possible binary with no framework overhead, which still matters for tiny utilities, drivers-adjacent tools, or teaching how Windows messaging actually works, but it demands far more boilerplate and is more error-prone since nothing prevents you from forgetting a case in the switch statement or mismanaging a handle's lifetime. MFC trades a modest amount of runtime overhead and a learning curve around its class hierarchy and macros for significantly faster development of anything beyond a trivial window, plus built-in support for common patterns like dialogs, toolbars, and serialization that would otherwise need to be built by hand.

🏏

Cricket analogy: Choosing raw Win32 for a tiny utility is like a local club match using a simple hand-scored scorebook instead of a full Hawk-Eye and DRS setup - overkill infrastructure isn't worth it when the stakes and scale don't call for it.

MFC's macros (BEGIN_MESSAGE_MAP, DECLARE_MESSAGE_MAP) generate hidden code behind the scenes; if you forget to declare a message map entry correctly, the compiler error can be cryptic. When debugging odd message-routing behavior in MFC, it's often worth checking the generated message map by hand against the Class Wizard's view.

Win32 is the low-level C API that Windows exposes; MFC wraps a large subset of it in C++ classes.
Raw Win32 requires manual WNDCLASSEX/RegisterClassEx/CreateWindowEx calls and a hand-written WndProc switch statement.
MFC replaces the switch statement with a message map that routes each message to a named member function.
You can always drop down to the raw HWND via GetSafeHwnd() when MFC doesn't cover a need.
Raw Win32 offers maximum control and minimal overhead, useful for tiny utilities and teaching the underlying model.
MFC trades a small amount of overhead and a learning curve for dramatically less boilerplate on non-trivial applications.
The choice between them is a trade-off between control/footprint and development speed, not a strict replacement.