WinAPI with C++

The Windows API (WinAPI, historically Win16 then Win32) is Microsoft’s core programming interface for the Windows operating system — thousands of C functions, structures, and messages covering everything from window creation and 2D graphics to files, threads, registry, networking, and security. It first appeared with Windows 1.0 in November 1985, and although the API itself is defined in C, C++ became its dominant driving language in the early 1990s and has remained so ever since: from raw WndProc programming through MFC, ATL, and COM to today’s C++/WinRT. “WinAPI with C++” is less a single language than a forty-year programming culture — message loops, HWNDs, Hungarian notation, and an almost fanatical commitment to backward compatibility — that underpins most of the desktop software ever written for the world’s most widely deployed PC operating system.

History & Origins

When Windows 1.0 shipped on November 20, 1985, it was not an operating system but a graphical environment running atop MS-DOS. Its programming model, however, was radical for PC developers: instead of owning the machine, a program registered a window class, supplied a window procedure, and entered a loop retrieving messages — an event-driven, cooperative model borrowed from the GUI research tradition rather than the sequential world of DOS. The API was C, but with a distinctive accent: 16-bit functions used the Pascal calling convention, and Microsoft’s Charles Simonyi popularized Hungarian notation (hwnd, lpszClassName, wParam) throughout its headers and documentation.

Early Windows programming was famously hard — developers juggled near and far pointers, movable memory handles, and cooperative multitasking. Charles Petzold’s Programming Windows (first edition 1988) tamed the learning curve and became the field’s defining textbook; generations of programmers began with its “Hello, Windows” skeleton.

C++ entered the picture in earnest in early 1992, when Microsoft C/C++ 7.0 shipped with MFC 1.0, a thin C++ class wrapper over the API. The decisive break came with Windows NT 3.1 on July 27, 1993, which introduced Win32: a flat 32-bit address space, preemptive multitasking, threads, and a vastly expanded API — while deliberately preserving the Win16 programming model so existing knowledge carried over. Win32s (1993) back-ported a subset to Windows 3.1, and Windows 95 (August 24, 1995) put Win32 on the consumer desktop, cementing C++ against the Win32 API as the standard way to build PC software for the next two decades.

Design Philosophy

Several principles give Windows API programming its unmistakable character:

• Event-driven message passing. A Windows program does not poll for input; the system delivers messages (WM_PAINT, WM_KEYDOWN, WM_CLOSE) to a callback — the window procedure — and the program’s while (GetMessage(...)) loop pumps them. Every GUI framework on Windows, however modern, ultimately sits on this loop.
• Opaque handles. Applications never touch OS objects directly; they hold typed but opaque handles — HWND, HDC, HANDLE, HKEY — and pass them back to API functions. This is object-oriented design expressed in C, which is precisely why thin C++ wrappers fit it so naturally.
• A C ABI as the universal contract. Defining the API in C with the stdcall convention made it callable from every language on the platform — C++, Pascal, BASIC, and today C#, Rust, and Python — while C++ became the language of choice for serious native work.
• Backward compatibility above nearly all else. Microsoft’s discipline here is legendary: many binaries built for Windows 95, and in some cases far earlier, still run on Windows 11. APIs are superseded (GDI by Direct2D, ANSI by Unicode variants) but almost never removed.
• Breadth over minimalism. The API grew to cover the entire operating system surface — thousands of functions across USER (windowing), GDI (graphics), KERNEL (processes, memory, files), plus shell, networking, cryptography, and more — with COM layering a binary object model on top from 1993 onward.

Key Features

The canonical Win32 C++ program is instantly recognizable — a window class, a window procedure, and a message loop:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#include <windows.h>

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) {
    switch (msg) {
    case WM_PAINT: {
        PAINTSTRUCT ps;
        HDC hdc = BeginPaint(hwnd, &ps);
        TextOut(hdc, 20, 20, TEXT("Hello, World!"), 13);
        EndPaint(hwnd, &ps);
        return 0;
    }
    case WM_DESTROY:
        PostQuitMessage(0);
        return 0;
    }
    return DefWindowProc(hwnd, msg, wParam, lParam);
}

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR, int nCmdShow) {
    WNDCLASS wc = {};
    wc.lpfnWndProc   = WndProc;
    wc.hInstance     = hInstance;
    wc.lpszClassName = TEXT("HelloWindow");
    RegisterClass(&wc);

    HWND hwnd = CreateWindow(TEXT("HelloWindow"), TEXT("Hello"),
                             WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT,
                             400, 300, nullptr, nullptr, hInstance, nullptr);
    ShowWindow(hwnd, nCmdShow);

    MSG msg;
    while (GetMessage(&msg, nullptr, 0, 0)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return static_cast<int>(msg.wParam);
}

Beyond windowing, the API’s major territories include:

Two idioms deserve special mention. Unicode duality: most text-taking functions exist in A (ANSI) and W (wide/UTF-16) forms behind a TEXT/TCHAR macro layer — a living fossil of the 1990s transition to Unicode. And structured error handling: most functions report failure through return values and GetLastError(), with COM adding HRESULT codes — conventions every Windows C++ framework wraps in its own way.

Evolution

The API’s history is one of expanding layers rather than replacements:

• Win16 (1985–1990s) — the original 16-bit API of Windows 1.0 through 3.1: cooperative multitasking, segmented memory, and the message-loop model that everything since has preserved.
• Win32 (1993) — the 32-bit flat-memory API of Windows NT and Windows 95: threads, preemptive scheduling, memory-mapped files, and a security model. This remains the substrate of Windows today.
• The C++ framework era (1992–2000s) — MFC (1992) wrapped the API for large applications like early Visual Studio and countless corporate tools; ATL (1996) served lightweight COM components; the community’s WTL offered a slimmer templated take on windowing.
• Win64 (2001–2005) — 64-bit Windows arrived on Itanium in 2001 and on x86-64 in April 2005. Microsoft chose an LLP64 model (pointers grow to 64 bits; int and long stay 32) precisely so that decades of Win32 C++ source could be recompiled largely unchanged.
• WinRT and modern C++ (2012–present) — Windows 8 introduced the Windows Runtime, a metadata-described, COM-based API layer, first consumed from C++ via the non-standard C++/CX extensions. C++/WinRT, begun independently by Kenny Kerr around 2014 and shipped in the Windows SDK in 2018 (10.0.17134), replaced it with a header-only projection in pure standard C++17.
• Decoupling (2021–present) — the win32metadata project machine-describes the whole Win32 surface (enabling generated bindings such as Rust for Windows), and the Windows App SDK (1.0 in November 2021) delivers modern UI and app-lifecycle APIs to classic Win32 desktop apps independently of OS releases.

Current Relevance

Reports of Win32’s death — issued regularly since the .NET era — have never survived contact with reality. The overwhelming majority of significant Windows desktop software in the 2020s is still native C++ on the Windows API: Office, the Adobe suite, Chrome and Firefox, essentially the entire PC game catalog, CAD and audio workstations, and Windows’ own shell and utilities. Microsoft’s own guidance now treats Win32 desktop apps as first-class citizens of the “Windows App SDK” era rather than a legacy tier, and the API remains fully supported and extended in Windows 11.

The tooling is livelier than its age suggests: Visual Studio’s C++ toolchain targets it directly, C++/WinRT brings modern C++ idioms to new APIs, and the win32metadata project has turned the API into a machine-readable specification consumed by Rust, C#, and other language bindings. Outside Microsoft’s world, Wine (and Valve’s Proton, which builds on it) reimplements the API to run Windows binaries on Linux — an independent testament to how much software the interface carries — while ReactOS attempts a compatible open-source OS, and MinGW-w64 lets GCC and Clang users target the API without Microsoft’s compiler. There is no official Docker story for GUI Win32 development on non-Windows hosts, though Windows containers exist for server workloads and MinGW-w64 cross-compilers can produce Windows executables from Linux.

Why It Matters

The Windows API is arguably the most consequential programming interface in the history of personal computing: for decades, learning it was simply what “becoming a PC programmer” meant, and Petzold’s message loop is among the most-typed program skeletons ever. Its pairing with C++ shaped both sides of the relationship — Windows made C++ the language of commercial desktop software in the 1990s, while the demands of wrapping a huge C API drove C++ framework design from MFC through ATL’s templates to C++/WinRT’s modern projections.

Its deepest legacy, though, is a philosophy: the contract with the developer is sacred. Microsoft’s willingness to carry forty years of API surface forward — quirks, Hungarian notation, A/W suffixes and all — is why software written for Windows 95 can still run today, and why an enormous industry could build on the platform with confidence. Event-driven GUI programming, the handle-based object model, and COM’s binary component contracts all spread far beyond Windows. Anyone who has written while (GetMessage(...)) has touched the machinery that ran the desktop era — machinery that, quietly and without fashion, is still running it.