← Back to all projects

LEARN WINDOWS GUI APPLICATION MODELS DEEP DIVE

Learn Windows GUI & Application Models: From Win32 to Modern UI

Goal: Deeply understand Windows GUI programming—from the foundational Win32 API with message loops and window procedures, through GDI graphics, to modern frameworks like WinUI 3 and UWP, with practical interop knowledge for WPF.

Why Windows GUI Programming Matters

Every Windows application you’ve ever used—from Notepad to Visual Studio to games—is built on these fundamentals. The Win32 API is the bedrock upon which all Windows UI frameworks are built. Even “modern” frameworks like WinUI 3 ultimately call into Win32 under the hood.

After completing these projects, you will:

  • Understand how Windows creates, manages, and destroys windows
  • Master the message loop—the heartbeat of every Windows application
  • Write window procedures that respond to user input and system events
  • Draw custom graphics using GDI/GDI+
  • Build modern applications with WinUI 3 and understand UWP
  • Know how to call managed WPF code from native C++ when needed
  • Debug UI issues by understanding what’s actually happening at the Win32 level

Core Concept Analysis

The Windows Application Architecture

┌─────────────────────────────────────────────────────────────┐
│                    Your Application                          │
├─────────────────────────────────────────────────────────────┤
│  WinUI 3  │  UWP/C++/WinRT  │  WPF (via interop)  │  MFC   │
├─────────────────────────────────────────────────────────────┤
│                    Windows Runtime (WinRT)                   │
├─────────────────────────────────────────────────────────────┤
│                      Win32 API (User32, GDI32)               │
├─────────────────────────────────────────────────────────────┤
│                 Windows Kernel (ntoskrnl.exe)                │
└─────────────────────────────────────────────────────────────┘

Fundamental Concepts

1. The Win32 Windowing Model

Everything in Windows is a “window”—buttons, text boxes, list views, even the desktop. Each window has:

  • HWND (Handle to Window): A unique identifier for the window
  • Window Class: A template defining behavior (registered with RegisterClass)
  • Window Procedure (WndProc): The function that handles messages
  • Parent/Child relationships: Windows form hierarchies
  • Styles: Flags that control appearance and behavior
┌─────────────────────────────────────────────┐
│ Parent Window (WS_OVERLAPPEDWINDOW)         │
│  ┌────────────────┐  ┌──────────────────┐   │
│  │ Child: Button  │  │ Child: Edit Box  │   │
│  │ (BS_PUSHBUTTON)│  │ (ES_MULTILINE)   │   │
│  └────────────────┘  └──────────────────┘   │
│  ┌──────────────────────────────────────┐   │
│  │ Child: List View (LVS_REPORT)        │   │
│  └──────────────────────────────────────┘   │
└─────────────────────────────────────────────┘

2. The Message Loop

The message loop is the heartbeat of every Windows GUI application. Windows communicates with your application through messages.

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Windows    │────▶│ Message Queue│────▶│ Your Message │
│   (System)   │     │ (per-thread) │     │    Loop      │
└──────────────┘     └──────────────┘     └──────┬───────┘
                                                  │
                           ┌──────────────────────┘
                           ▼
                    ┌──────────────┐
                    │   Dispatch   │
                    │   Message    │
                    └──────┬───────┘
                           │
         ┌─────────────────┼─────────────────┐
         ▼                 ▼                 ▼
   ┌──────────┐     ┌──────────┐      ┌──────────┐
   │ WndProc  │     │ WndProc  │      │ WndProc  │
   │ Window 1 │     │ Window 2 │      │ Window 3 │
   └──────────┘     └──────────┘      └──────────┘

The classic message loop:

while (GetMessage(&msg, NULL, 0, 0) > 0) {
    TranslateMessage(&msg);  // Keyboard input translation
    DispatchMessage(&msg);   // Send to window procedure
}

3. Window Procedures

The window procedure (WndProc) is where your application responds to events:

LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam) {
    switch (msg) {
        case WM_CREATE:    // Window being created
        case WM_PAINT:     // Window needs repainting
        case WM_SIZE:      // Window resized
        case WM_COMMAND:   // Menu/button/accelerator
        case WM_DESTROY:   // Window being destroyed
        default:
            return DefWindowProc(hwnd, msg, wParam, lParam);
    }
}

Key message categories:

  • WM_CREATE/WM_DESTROY: Lifecycle
  • WM_PAINT/WM_ERASEBKGND: Drawing
  • WM_SIZE/WM_MOVE: Geometry
  • WM_KEYDOWN/WM_KEYUP/WM_CHAR: Keyboard
  • WM_LBUTTONDOWN/WM_MOUSEMOVE: Mouse
  • WM_COMMAND/WM_NOTIFY: Control notifications

4. GDI (Graphics Device Interface)

GDI is Windows’ original 2D graphics API. Everything you draw uses device contexts (DC):

┌─────────────────────────────────────────────────────┐
│                  Device Context (HDC)                │
│  ┌───────────┐ ┌──────────┐ ┌──────────────────┐    │
│  │   Pen     │ │  Brush   │ │      Font        │    │
│  │ (lines)   │ │ (fill)   │ │ (text)           │    │
│  └───────────┘ └──────────┘ └──────────────────┘    │
│  ┌───────────┐ ┌──────────┐ ┌──────────────────┐    │
│  │  Bitmap   │ │  Region  │ │   Palette        │    │
│  │ (images)  │ │ (clip)   │ │   (colors)       │    │
│  └───────────┘ └──────────┘ └──────────────────┘    │
└─────────────────────────────────────────────────────┘
                          │
                          ▼
              ┌──────────────────────┐
              │   Output Device      │
              │ (Screen, Printer, etc)│
              └──────────────────────┘

5. Modern UI Frameworks

WinUI 3: Microsoft’s latest native UI framework

  • Part of Windows App SDK
  • Fluent Design System
  • XAML-based with C++/WinRT
  • Runs on Windows 10 1809+ and Windows 11

UWP (Universal Windows Platform):

  • Sandboxed app model
  • Windows Runtime (WinRT) APIs
  • C++/WinRT or C++/CX language projections
  • Store distribution

WPF (Windows Presentation Foundation):

  • .NET-based (managed code)
  • XAML UI definition
  • Requires interop (C++/CLI or CLR hosting) from native C++

Project List

Projects are ordered from fundamental Win32 understanding to modern framework mastery.

Project 1: The Minimal Window (Win32 From Scratch)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C
  • Alternative Programming Languages: C++, Rust (windows-rs)
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 1: Beginner
  • Knowledge Area: Win32 API / Window Creation
  • Software or Tool: Visual Studio, Windows SDK
  • Main Book: “Programming Windows, 5th Edition” by Charles Petzold

What you’ll build: A minimal Win32 application that creates a window, processes messages, and cleanly shuts down—with zero dependencies beyond the Windows SDK.

Why it teaches Win32: This strips away all frameworks to show you what every Windows application does at its core. You’ll see that a “window” is just a struct in kernel memory, identified by an HWND, that receives messages through a callback function.

Core challenges you’ll face:

  • Registering a window class → maps to understanding WNDCLASSEX and how Windows identifies window types
  • Creating the window with proper styles → maps to window styles (WS_) and extended styles*
  • Writing a proper message loop → maps to GetMessage vs PeekMessage, TranslateMessage purpose
  • Handling WM_DESTROY vs WM_CLOSE → maps to window lifecycle and cleanup

Key Concepts:

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic C programming, understanding of pointers and structures, ability to use Visual Studio or command-line compiler

Real world outcome:

When you run your program:
- A resizable window appears with your custom title
- The window can be moved, minimized, maximized
- Clicking the X button closes the application cleanly
- The console shows debug output for every message received:
  "WM_CREATE received"
  "WM_SIZE: 800x600"
  "WM_PAINT"
  "WM_CLOSE - posting quit message"

Implementation Hints:

The skeleton of every Win32 program follows this pattern:

  1. Define WinMain (not main) - Windows GUI entry point receives the instance handle, command line, and show command

  2. Fill out WNDCLASSEX - Think of this as a “template” for windows:
    • lpfnWndProc: Pointer to your message handler
    • hInstance: Your application’s instance
    • lpszClassName: A unique string name for this window type
    • hCursor: What cursor to show
    • hbrBackground: Default background brush

  3. Register the class with RegisterClassEx()

  4. Create the window with CreateWindowEx():
    • Pass the class name you registered
    • Choose styles (WS_OVERLAPPEDWINDOW is a good start)
    • Set initial position and size

  5. Show the window with ShowWindow() and UpdateWindow()

  6. Run the message loop:
    • GetMessage() blocks until a message arrives
    • Returns 0 when WM_QUIT is received
    • TranslateMessage() converts key presses to WM_CHAR
    • DispatchMessage() sends to the appropriate WndProc
  7. In your WndProc:
    • Switch on the message type
    • Handle WM_DESTROY by calling PostQuitMessage(0)
    • Call DefWindowProc() for messages you don’t handle

Ask yourself: What happens if you don’t call DefWindowProc? What if you handle WM_CLOSE but forget WM_DESTROY?

Learning milestones:

  1. Window appears and responds to close → You understand the basic Win32 flow
  2. You add WM_PAINT handling with BeginPaint/EndPaint → You understand the paint cycle
  3. You handle keyboard/mouse input → You understand message parameters
  4. You create child controls (buttons, edit boxes) → You understand the window hierarchy

Project 2: Message Spy (Understanding the Message Pump)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C
  • Alternative Programming Languages: C++, Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 1: Beginner
  • Knowledge Area: Win32 Messages / Event System
  • Software or Tool: Visual Studio, Spy++ (for comparison)
  • Main Book: “Programming Windows, 5th Edition” by Charles Petzold

What you’ll build: A tool that intercepts and logs all messages sent to a window, displaying them in real-time with decoded parameters—like Microsoft’s Spy++ but built from scratch.

Why it teaches message handling: By watching every message flow through, you’ll understand exactly how Windows communicates with applications. You’ll see the flood of WM_MOUSEMOVE messages, the WM_NCHITTEST that determines hit testing, and the intricate dance of WM_KEYDOWN/WM_CHAR/WM_KEYUP.

Core challenges you’ll face:

  • Subclassing a window → maps to SetWindowLongPtr with GWLP_WNDPROC
  • Decoding message parameters → maps to understanding WPARAM/LPARAM for each message type
  • Hook procedures for cross-process spying → maps to SetWindowsHookEx and DLL injection
  • High-frequency message filtering → maps to understanding which messages matter

Key Concepts:

  • Subclassing: “Programming Windows, 5th Edition” Chapter 9 - Charles Petzold
  • Windows Hooks: “Windows via C/C++” Chapter 22 - Jeffrey Richter
  • Message Decoding: Microsoft Learn - System-Defined Messages
  • WPARAM/LPARAM: “Programming Windows, 5th Edition” Chapter 6 - Charles Petzold

Difficulty: Beginner Time estimate: Weekend Prerequisites: Project 1 completed, understanding of function pointers

Real world outcome:

Message Spy v1.0
Target: [Calculator - Calculator]
─────────────────────────────────────────────
[12:34:56.789] WM_MOUSEMOVE     x=150, y=200
[12:34:56.812] WM_NCHITTEST     x=150, y=200 → HTCLIENT
[12:34:57.100] WM_LBUTTONDOWN   x=150, y=200, keys=MK_LBUTTON
[12:34:57.150] WM_LBUTTONUP     x=150, y=200
[12:34:57.152] WM_COMMAND       id=123, code=BN_CLICKED, hwnd=0x1234
[12:34:58.000] WM_KEYDOWN       vk=VK_RETURN, scancode=0x1C, repeat=1
[12:34:58.002] WM_CHAR          char='\\r' (0x0D)
[12:34:58.010] WM_KEYUP         vk=VK_RETURN
─────────────────────────────────────────────
Messages captured: 2,847 | Filtered: 12,503

Implementation Hints:

Start with your own window first (easier), then expand to other windows:

  1. For your own window: Instead of handling messages in WndProc, log them first, then process:
    • Create a lookup table mapping message IDs to names
    • Format each message with timestamp
    • Decode WPARAM/LPARAM based on message type
  2. For subclassing another window in your process:
    • Use SetWindowLongPtr(hwnd, GWLP_WNDPROC, (LONG_PTR)NewWndProc)
    • Store the old WndProc and call it after logging
    • Return the result from the original WndProc
  3. For hooking across processes (advanced):
    • Create a DLL with the hook procedure
    • Use SetWindowsHookEx(WH_CALLWNDPROC, ...) or WH_GETMESSAGE
    • The DLL gets injected into target processes
    • Use shared memory or messages to communicate back
  4. Message decoding challenges:
    • WM_NOTIFY uses NMHDR structures (need to know control type)
    • WM_COMMAND packs control ID in LOWORD(wParam)
    • Mouse messages pack coordinates in LPARAM (use LOWORD/HIWORD or GET_X_LPARAM/GET_Y_LPARAM)

Think about: Why do some messages use SendMessage (synchronous) while others use PostMessage (asynchronous)? What happens if your hook procedure takes too long?

Learning milestones:

  1. You log messages for your own window → You understand message flow
  2. You decode parameters correctly → You understand message packing
  3. You subclass another window → You understand window procedure chaining
  4. You hook cross-process → You understand DLL injection and hooks

Project 3: Custom Control from Scratch (Owner-Draw Mastery)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C
  • Alternative Programming Languages: C++, Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Win32 Custom Controls / GDI
  • Software or Tool: Visual Studio, Windows SDK
  • Main Book: “Programming Windows, 5th Edition” by Charles Petzold

What you’ll build: A fully custom slider control with smooth animation, custom skinning, and keyboard support—implementing all the control behaviors that Windows provides automatically for standard controls.

Why it teaches custom controls: Standard Windows controls are “black boxes.” By building one yourself, you’ll understand owner-draw, custom window classes, focus handling, keyboard navigation, and how controls communicate with their parent windows.

Core challenges you’ll face:

  • Registering a custom control class → maps to understanding control vs window classes
  • Handling mouse capture → maps to SetCapture/ReleaseCapture for dragging
  • Implementing keyboard navigation → maps to focus, tab stops, arrow keys
  • Sending notifications to parent → maps to WM_COMMAND/WM_NOTIFY protocols
  • Custom painting without flicker → maps to double buffering, WM_ERASEBKGND

Key Concepts:

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Projects 1-2 completed, basic GDI understanding

Real world outcome:

Your custom slider control that:
- Renders with a custom skin (gradient track, styled thumb)
- Smoothly animates the thumb when clicked on the track
- Responds to arrow keys (fine control) and Page Up/Down (large steps)
- Sends notifications: SLIDER_CHANGED, SLIDER_TRACKING, SLIDER_ENDTRACK
- Works correctly when tabbed to (shows focus indicator)
- Respects system DPI and themes
- Can be used in a dialog template like standard controls

Implementation Hints:

Building a custom control is like building a mini-application inside a window:

  1. Register your control class:
    • Use a unique class name like “MyCustomSlider”
    • Add CS_HREDRAW CS_VREDRAW for proper repainting
    • Store per-instance data using SetWindowLongPtr(hwnd, 0, data) or window properties
  2. Track internal state:
    • Current value, min/max range
    • Is thumb being dragged?
    • Does window have focus?
    • Current animation frame (if animating)
  3. Handle the mouse sequence:
    • WM_LBUTTONDOWN: Hit-test thumb vs track, call SetCapture()
    • WM_MOUSEMOVE: If captured, update thumb position
    • WM_LBUTTONUP: Release capture, finalize value, send notification
  4. Handle keyboard:
    • WM_KEYDOWN: Arrow keys adjust value, Home/End for min/max
    • WM_GETDLGCODE: Return DLGC_WANTARROWS to receive arrow keys
  5. Handle painting:
    • WM_ERASEBKGND: Return TRUE (we’ll paint everything ourselves)
    • WM_PAINT: Use double-buffering to avoid flicker
    • Draw: background track, filled portion, thumb, focus rectangle
  6. Communicate with parent:
    • Send WM_COMMAND or WM_NOTIFY when value changes
    • Include control ID and notification code
    • For custom notifications, define your own NMHDR-derived structure

Ask yourself: How does the Tab key work? (Hint: WM_KILLFOCUS/WM_SETFOCUS). How do screen readers interact with controls? (Hint: WM_GETOBJECT, UI Automation).

Learning milestones:

  1. Control appears and accepts clicks → You understand custom window classes
  2. Dragging works smoothly → You understand mouse capture
  3. Keyboard works, control tabs correctly → You understand focus management
  4. Parent receives notifications → You understand control/parent communication
  5. No flicker, animations work → You understand double buffering and timers

Project 4: Paint Program (GDI Mastery)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C, Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: GDI Graphics / Drawing
  • Software or Tool: Visual Studio, Windows SDK
  • Main Book: “Programming Windows, 5th Edition” by Charles Petzold

What you’ll build: A simple paint program with brushes, shapes, color selection, and undo/redo—like a minimal MS Paint clone that teaches you everything about GDI.

Why it teaches GDI: GDI is how Windows has drawn graphics for 30+ years. By building a paint program, you’ll work with every major GDI concept: device contexts, pens, brushes, bitmaps, regions, and coordinate transformations.

Core challenges you’ll face:

  • Managing device contexts → maps to HDC lifecycle, compatible DCs, memory DCs
  • Drawing primitives correctly → maps to pens, brushes, and their selection
  • Bitmap manipulation → maps to DIB sections, BitBlt, StretchBlt
  • Implementing undo with bitmaps → maps to memory management, copying DCs
  • Proper invalidation → maps to InvalidateRect, efficient repainting

Key Concepts:

  • Device Contexts: “Programming Windows, 5th Edition” Chapter 5 - Charles Petzold
  • GDI Objects: “Programming Windows, 5th Edition” Chapter 5 - Charles Petzold
  • Bitmaps and DIBs: “Programming Windows, 5th Edition” Chapter 15 - Charles Petzold
  • GDI Coordinate Systems: Microsoft Learn - Coordinate Spaces and Transformations

Difficulty: Intermediate Time estimate: 2-3 weeks Prerequisites: Projects 1-3 completed, understanding of basic graphics concepts

Real world outcome:

A paint program window with:
- Toolbar: Pencil, Line, Rectangle, Ellipse, Fill, Eraser
- Color palette with custom color picker
- Adjustable brush size
- Canvas that can be saved as BMP/PNG
- Unlimited undo/redo (Ctrl+Z/Ctrl+Y)
- Zoom in/out with scroll wheel
- Selection tool with copy/paste
- Status bar showing coordinates and canvas size

Implementation Hints:

The architecture centers around a “canvas bitmap”:

  1. The Canvas:
    • Create a memory DC and a compatible bitmap for your canvas
    • All drawing happens on this bitmap, not directly on screen
    • WM_PAINT just BitBlts the canvas to screen
  2. Device Context Management:
    • GetDC(hwnd) for drawing on window
    • CreateCompatibleDC(hdc) for off-screen drawing
    • ALWAYS release/delete what you create:
      • ReleaseDC() for GetDC
      • DeleteDC() for CreateCompatibleDC
      • DeleteObject() for pens, brushes, bitmaps
  3. Drawing with GDI:
    • Create a pen: CreatePen(PS_SOLID, width, color)
    • Create a brush: CreateSolidBrush(color)
    • Select into DC: SelectObject(hdc, pen) - save the return value!
    • Draw: MoveToEx(), LineTo(), Rectangle(), Ellipse()
    • Restore old objects and delete your objects
  4. Freehand Drawing:
    • WM_LBUTTONDOWN: MoveToEx() to start point
    • WM_MOUSEMOVE (while button down): LineTo() each point
    • Draw to canvas bitmap, then invalidate that region
  5. Undo/Redo:
    • Before each operation, copy the entire canvas bitmap to an undo stack
    • On undo, restore previous bitmap
    • Consider limiting stack depth for memory
  6. Saving:
    • Use GetDIBits() to get pixel data from bitmap
    • Write BMP header + pixel data
    • For PNG, use GDI+ or a library like stb_image_write

Think about: Why does GDI use “select into DC” instead of passing the pen to each draw call? What’s the difference between a DDB (device-dependent bitmap) and a DIB (device-independent bitmap)?

Learning milestones:

  1. You can draw lines that persist → You understand memory DCs
  2. Colors work, brush sizes work → You understand GDI object creation
  3. Undo/redo works without leaks → You understand resource management
  4. Save to file works → You understand bitmap formats
  5. Zoom works → You understand coordinate transformations

Project 5: GDI+ Image Viewer & Editor

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C (with C wrappers)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: GDI+ Graphics / Image Processing
  • Software or Tool: Visual Studio, Windows SDK, GDI+
  • Main Book: “Programming Windows, 5th Edition” by Charles Petzold

What you’ll build: An image viewer with modern graphics features: anti-aliased rendering, alpha blending, image filters (blur, sharpen), and format conversion—using GDI+, the object-oriented successor to GDI.

Why it teaches GDI+: GDI+ provides what GDI lacks: anti-aliasing, alpha transparency, gradient brushes, matrix transformations, and native image format support. It bridges the gap between old GDI and modern graphics APIs.

Core challenges you’ll face:

  • GDI+ initialization/shutdown → maps to GdiplusStartup/GdiplusShutdown lifecycle
  • Graphics object management → maps to C++ RAII patterns with GDI+ objects
  • Image loading and format conversion → maps to Image class, codecs, encoders
  • Applying transformations → maps to Matrix class, rotation, scaling
  • Alpha blending and transparency → maps to ColorMatrix, ImageAttributes

Key Concepts:

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Project 4 completed, understanding of C++ classes

Real world outcome:

An image viewer/editor that:
- Opens JPG, PNG, GIF, BMP, TIFF with drag-and-drop
- Displays images with high-quality anti-aliased scaling
- Rotates images at any angle with smooth interpolation
- Applies filters: brightness/contrast, blur, sharpen, grayscale
- Shows transparent PNGs correctly (checkerboard background)
- Exports to any supported format with quality options
- Displays EXIF data (dimensions, camera info, date)
- Handles animated GIFs
- Provides thumbnail strip for folder browsing

Implementation Hints:

GDI+ is object-oriented and much cleaner than GDI:

  1. Initialization (must do before any GDI+ calls): 
    GdiplusStartupInput startupInput;
ULONG_PTR token;
GdiplusStartup(&token, &startupInput, NULL);
// ... use GDI+ ...
GdiplusShutdown(token);
  2. Drawing with Graphics:
    • Create: Graphics graphics(hdc); or Graphics graphics(hwnd);
    • Set quality: graphics.SetSmoothingMode(SmoothingModeAntiAlias);
    • Draw: graphics.DrawImage(), graphics.DrawLine(), etc.
    • No explicit cleanup—C++ destructors handle it
  3. Loading Images:
    • Image* image = Image::FromFile(L"photo.jpg");
    • Check status: if (image->GetLastStatus() != Ok) {...}
    • Get dimensions: image->GetWidth(), image->GetHeight()
  4. Transformations:
    • Create matrix: Matrix matrix;
    • Apply transforms: matrix.Rotate(45); matrix.Scale(2, 2);
    • Set on graphics: graphics.SetTransform(&matrix);
    • Draw—everything is transformed
  5. Image Effects (ColorMatrix for color adjustments):
    • Create a 5x5 color matrix
    • Adjust values for brightness, contrast, grayscale
    • Apply with ImageAttributes
  6. For blur/sharpen:
    • GDI+ doesn’t have built-in convolution
    • Lock bitmap bits with LockBits()
    • Apply kernel manually (or use GDI+ Effects on Vista+)

Ask yourself: What’s the performance difference between GDI and GDI+? When would you still use GDI? How does GDI+ handle color profiles?

Learning milestones:

  1. Images load and display → You understand GDI+ basics
  2. Rotation/scaling works smoothly → You understand transformations
  3. Filters work → You understand pixel manipulation
  4. Alpha blending works → You understand transparency
  5. Format conversion works → You understand encoders/decoders

Project 6: Notepad Clone (Common Controls & Dialogs)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C
  • Alternative Programming Languages: C++, Rust
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Win32 Common Controls / Common Dialogs
  • Software or Tool: Visual Studio, Windows SDK
  • Main Book: “Programming Windows, 5th Edition” by Charles Petzold

What you’ll build: A feature-complete Notepad clone with file operations, find/replace, font selection, print preview, and recent files—demonstrating mastery of common controls and dialogs.

Why it teaches common controls: Win32 provides pre-built controls (edit boxes, list views, toolbars) and dialogs (open/save, font, color, print). Learning to use these correctly—with all their quirks—is essential for any Win32 developer.

Core challenges you’ll face:

  • Rich Edit control for text → maps to EM_ messages, text formatting*
  • Common dialogs → maps to GetOpenFileName, ChooseFont, PrintDlg
  • Menus and accelerators → maps to resource files, keyboard shortcuts
  • Status bar and toolbar → maps to common controls initialization
  • Print preview → maps to printer DC, page layout

Key Concepts:

  • Common Controls: “Programming Windows, 5th Edition” Chapter 12 - Charles Petzold
  • Common Dialogs: “Programming Windows, 5th Edition” Chapter 11 - Charles Petzold
  • Menus and Resources: “Programming Windows, 5th Edition” Chapter 10 - Charles Petzold
  • Printing: “Programming Windows, 5th Edition” Chapter 13 - Charles Petzold

Difficulty: Intermediate Time estimate: 2 weeks Prerequisites: Projects 1-3 completed, understanding of resource files

Real world outcome:

A text editor with:
- File menu: New, Open, Save, Save As, Recent Files, Print, Exit
- Edit menu: Undo, Cut, Copy, Paste, Find, Replace, Go To Line
- Format menu: Word Wrap, Font, Tab Size
- View menu: Status Bar, Zoom
- Toolbar with common actions
- Status bar showing line/column, encoding, line endings
- Drag-and-drop file opening
- "Save changes?" prompt on exit
- Keyboard shortcuts (Ctrl+S, Ctrl+F, etc.)
- Print with proper pagination and headers/footers

Implementation Hints:

This project ties together many Win32 concepts:

  1. The Edit Control:
    • Use Rich Edit control (load Msftedit.dll first)
    • Create with CreateWindowEx(0, MSFTEDIT_CLASS, ...)
    • Handle EM_* messages for text manipulation
    • EN_CHANGE notification for “modified” flag
  2. Common Dialogs:
    • Initialize OPENFILENAME structure carefully
    • Set filters: L"Text Files\0*.txt\0All Files\0*.*\0"
    • Check return value and CommDlgExtendedError() on failure
    • Font dialog returns LOGFONT—create font with CreateFontIndirect()
  3. Menus from Resources:
    • Define menu in .rc file
    • Load with LoadMenu() or in WNDCLASS
    • Handle WM_COMMAND with LOWORD(wParam) = menu ID
    • Update menu state with CheckMenuItem(), EnableMenuItem()
  4. Accelerators (keyboard shortcuts):
    • Define accelerator table in .rc file
    • Load with LoadAccelerators()
    • Call TranslateAccelerator() in message loop
    • Must be before TranslateMessage()
  5. Printing:
    • Use PrintDlg() to get printer DC
    • Call StartDoc(), StartPage()
    • Draw text with proper pagination
    • EndPage(), EndDoc(), delete DC
  6. Recent Files:
    • Store in registry (HKEY_CURRENT_USER)
    • Update menu dynamically
    • Handle file-not-found gracefully

Think about: Why does Windows use resource files (.rc) for UI definition? How does the system know which control should receive keyboard focus?

Learning milestones:

  1. Basic editing works → You understand edit controls
  2. Open/Save dialogs work → You understand common dialogs
  3. Menus and shortcuts work → You understand resources
  4. Find/Replace works → You understand modal dialogs
  5. Printing works → You understand printer DCs

Project 7: File Explorer Pane (Advanced Common Controls)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C, Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Win32 Common Controls / Shell Integration
  • Software or Tool: Visual Studio, Windows SDK
  • Main Book: “Programming Windows, 5th Edition” by Charles Petzold

What you’ll build: A file explorer panel with tree view, list view (with details/icons/thumbnails modes), shell integration for icons and context menus, and virtual folder support—like one panel of Windows Explorer.

Why it teaches advanced controls: TreeView and ListView are complex controls with virtual modes, custom draw, and shell integration. Building a file browser requires mastering all these features plus interacting with the Windows Shell APIs.

Core challenges you’ll face:

  • Tree view with lazy loading → maps to TVN_ITEMEXPANDING, folder enumeration
  • List view virtual mode → maps to LVN_GETDISPINFO, large folder handling
  • Shell icon extraction → maps to SHGetFileInfo, IShellFolder
  • Context menus from shell → maps to IContextMenu, shell extensions
  • Drag and drop → maps to IDropSource, IDropTarget, OLE D&D

Key Concepts:

Difficulty: Advanced Time estimate: 3-4 weeks Prerequisites: Projects 1-6 completed, understanding of COM basics

Real world outcome:

A file explorer panel with:
- Tree view showing drives, folders, network locations
- List view with: Details, List, Small Icons, Large Icons, Thumbnails
- Sorting by name, date, size, type
- Shell icons that match Windows Explorer exactly
- Right-click context menus (from shell extensions)
- Drag files in/out, copy/move operations
- Navigation breadcrumb bar
- Address bar with autocomplete
- Quick access / favorites
- Search with results displayed

Implementation Hints:

This is a complex project requiring shell integration:

  1. TreeView Setup:
    • Create with TVS_HASLINES TVS_HASBUTTONS TVS_LINESATROOT
    • Use image list for folder icons
    • Add root items for drives (use GetLogicalDrives())
    • On TVN_ITEMEXPANDING: enumerate children with FindFirstFile()
    • Insert “dummy” child to show [+] before expanding
  2. ListView with Virtual Mode:
    • Create with LVS_OWNERDATA style
    • Handle LVN_GETDISPINFO—system asks for item data on demand
    • Maintain internal list of file info
    • Sorting: re-sort internal list, call ListView_SetItemCount()
  3. Shell Icons:
    • SHGetFileInfo(path, 0, &sfi, sizeof(sfi), SHGFI_ICON | SHGFI_SMALLICON)
    • For thumbnails: use IThumbnailProvider or IExtractImage
    • Cache icons—extraction is slow
  4. Shell Context Menus:
    • Get IShellFolder for parent folder
    • Get child PIDL
    • QueryInterface for IContextMenu
    • Create popup menu with IContextMenu::QueryContextMenu()
    • On selection, call IContextMenu::InvokeCommand()
  5. Drag and Drop:
    • Implement IDropSource for dragging out
    • Implement IDropTarget for dropping in
    • Use SHDoDragDrop() for shell integration
    • Handle DROPEFFECT_COPY, DROPEFFECT_MOVE
  6. Virtual Folders:
    • Desktop, Computer, Network aren’t filesystem paths
    • Use SHGetDesktopFolder() and IShellFolder navigation
    • Parse display names with IShellFolder::ParseDisplayName()

Think about: Why does Windows Shell use PIDLs (item ID lists) instead of paths? How would you handle very large folders (100,000+ files)?

Learning milestones:

  1. TreeView shows folder hierarchy → You understand tree view basics
  2. ListView shows files with icons → You understand shell integration
  3. Virtual mode handles large folders → You understand virtual controls
  4. Context menus work → You understand COM and IContextMenu
  5. Drag and drop works → You understand OLE drag and drop

Project 8: Multi-Document Interface (MDI) Application

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Win32 MDI / Document Management
  • Software or Tool: Visual Studio, Windows SDK
  • Main Book: “Programming Windows, 5th Edition” by Charles Petzold

What you’ll build: A multi-document text editor where each document opens in its own child window within the main frame—like old-style Word or Visual Studio’s MDI mode.

Why it teaches MDI: MDI (Multiple Document Interface) is a classic Win32 pattern requiring special window classes, message handling, and state management. Understanding MDI teaches you about window relationships and document/view architecture.

Core challenges you’ll face:

  • MDI frame and client setup → maps to MDICLIENT window class, CreateMDIWindow
  • Cascading message handling → maps to DefFrameProc, DefMDIChildProc
  • Window menu management → maps to automatic window list, WM_MDIACTIVATE
  • Per-document state → maps to associating data with child windows
  • Child window lifecycle → maps to WM_MDICREATE, WM_MDIDESTROY

Key Concepts:

  • MDI Architecture: “Programming Windows, 5th Edition” Chapter 19 - Charles Petzold
  • Document/View Pattern: “Windows via C/C++” Chapter 26 - Jeffrey Richter
  • Window Management: Microsoft Learn - MDI

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Project 6 completed

Real world outcome:

An MDI text editor with:
- Multiple documents in child windows
- Window menu: Cascade, Tile Horizontal, Tile Vertical, list of open windows
- Each document has own undo history, selection, scroll position
- Title bar shows active document name
- Modified indicator (*) in window title
- "Save All" and "Close All" functionality
- Maximize child → takes over frame client area
- Ctrl+Tab to switch between documents
- Drag tabs to reorder (bonus: tabbed MDI)

Implementation Hints:

MDI requires a specific window hierarchy:

Frame Window (your main window)
  └── MDICLIENT (pre-registered class, manages children)
       ├── MDI Child 1 (your document window)
       ├── MDI Child 2
       └── MDI Child 3
  1. Creating the Frame:
    • Register your frame window class
    • In WM_CREATE, create the MDICLIENT child:
      • Class name is “MDICLIENT”
      • Pass CLIENTCREATESTRUCT with menu info
      • Store MDICLIENT hwnd for later use
  2. Creating Children:
    • Register your child window class
    • Use CreateMDIWindow() or send WM_MDICREATE to MDICLIENT
    • MDICREATESTRUCT specifies class, title, size
  3. Message Handling (tricky!):
    • Frame: Use DefFrameProc() instead of DefWindowProc()
    • Child: Use DefMDIChildProc() instead of DefWindowProc()
    • Must pass messages through correctly or MDI breaks
  4. Window Menu:
    • MDICLIENT automatically adds open windows to menu
    • Specify menu position in CLIENTCREATESTRUCT
    • Handle WM_MDIACTIVATE for active window changes
  5. Accelerators with MDI:
    • Must call TranslateMDISysAccel() in message loop
    • Before TranslateAccelerator()
    • Handles Ctrl+F4, Ctrl+Tab, etc.
  6. Per-Document Data:
    • Use SetWindowLongPtr(childHwnd, 0, data) with extra window bytes
    • Or use SetProp()/GetProp() for window properties
    • Update when document state changes

Modern alternative: Tabbed interfaces (implement yourself with tab control + switching content).

Learning milestones:

  1. Multiple child windows appear → You understand MDI structure
  2. Window menu works → You understand MDICLIENT
  3. Per-document state works → You understand window data association
  4. Maximize/minimize works correctly → You understand MDI quirks
  5. All lifecycle edge cases handled → You’ve mastered MDI

Project 9: Dialog-Based Application with Custom Dialogs

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C
  • Alternative Programming Languages: C++
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Win32 Dialogs / UI Layout
  • Software or Tool: Visual Studio Resource Editor, Windows SDK
  • Main Book: “Programming Windows, 5th Edition” by Charles Petzold

What you’ll build: A configuration/settings application with multiple dialog pages, property sheets, custom control layout, and input validation—demonstrating professional dialog design.

Why it teaches dialogs: Dialogs are fundamental to Win32 applications. Understanding dialog templates, DDX (dialog data exchange), validation, and property sheets is essential for building user-facing configuration UI.

Core challenges you’ll face:

  • Dialog templates → maps to resource scripts, DIALOGEX syntax
  • Dialog procedure vs window procedure → maps to different return conventions
  • Control data exchange → maps to GetDlgItemText, SetDlgItemInt
  • Property sheets → maps to PROPSHEETPAGE, PROPSHEETHEADER
  • Input validation → maps to EN_KILLFOCUS, error feedback

Key Concepts:

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Projects 1-3 completed, understanding of resource files

Real world outcome:

A settings application with:
- Property sheet with tabs: General, Appearance, Advanced, About
- Each page has grouped controls (group boxes, labels, inputs)
- Input validation with error tooltips
- Apply button (commits changes without closing)
- Reset to defaults button
- Settings persisted to registry/INI
- Help button opens context-sensitive help
- Accelerator keys for all controls (underlined letters)
- Tab order flows logically
- DPI-aware layout that scales properly

Implementation Hints:

  1. Dialog Templates in Resources: 
    IDD_SETTINGS DIALOGEX 0, 0, 300, 200
STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU
CAPTION "Settings"
FONT 9, "Segoe UI"
BEGIN
    GROUPBOX "Options", IDC_STATIC, 10, 10, 280, 100
    CHECKBOX "Enable feature", IDC_ENABLE, 20, 25, 100, 10
    LTEXT "Value:", IDC_STATIC, 20, 45, 40, 8
    EDITTEXT IDC_VALUE, 70, 42, 80, 14, ES_NUMBER
    DEFPUSHBUTTON "OK", IDOK, 180, 175, 50, 14
    PUSHBUTTON "Cancel", IDCANCEL, 240, 175, 50, 14
END
  2. Dialog Procedure Differences:
    • Return TRUE if you handled the message, FALSE otherwise
    • For WM_INITDIALOG, return TRUE to set default focus
    • Call SetDlgItemText/GetDlgItemText for control data
    • Use EndDialog() to close modal dialogs
  3. Property Sheets:
    • Create PROPSHEETPAGE array, one per tab
    • Fill PROPSHEETHEADER
    • Call PropertySheet()—it’s modal
    • Handle PSN_APPLY in each page’s dialog proc
  4. Validation:
    • Validate on EN_KILLFOCUS (edit control loses focus)
    • Or validate all on OK button
    • Use ErrorBalloon tooltips for feedback
    • Disable OK button until valid
  5. Data Exchange Pattern:
    • WM_INITDIALOG: Load settings → controls
    • OK button: Validate all → Extract from controls → Save
    • Apply button: Same, but don’t close
    • Cancel: Just close (settings not saved)
  6. DPI Awareness:
    • Use dialog units, not pixels (template handles this)
    • Call SetProcessDPIAware() or use manifest
    • Or use per-monitor DPI awareness (Windows 10+)

Think about: What’s the difference between modal and modeless dialogs? When would you use CreateDialog() vs DialogBox()?

Learning milestones:

  1. Basic dialog appears with controls → You understand templates
  2. Data round-trips correctly → You understand dialog data exchange
  3. Property sheet works → You understand multi-page dialogs
  4. Validation prevents bad input → You understand error handling
  5. Settings persist → You understand registry/file integration

Project 10: WinUI 3 Hello World (Modern Native UI)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++ (C++/WinRT)
  • Alternative Programming Languages: C# (easier), Rust (windows-rs)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: WinUI 3 / Windows App SDK
  • Software or Tool: Visual Studio 2022, Windows App SDK
  • Main Book: (No single book) Microsoft Learn WinUI 3 Documentation

What you’ll build: A modern Windows application using WinUI 3 with Fluent Design, responsive layout, dark mode support, and XAML-defined UI—experiencing Microsoft’s current recommended native UI framework.

Why it teaches WinUI 3: WinUI 3 is Microsoft’s latest native UI framework. Understanding it shows you how modern Windows apps are built, the differences from Win32, and how XAML compares to procedural UI construction.

Core challenges you’ll face:

  • C++/WinRT projection → maps to smart pointers, coroutines, IInspectable
  • XAML and code-behind → maps to declarative UI, binding, events
  • Windows App SDK setup → maps to NuGet, SDK versions, deployment
  • Fluent Design integration → maps to Acrylic, Reveal, animations
  • Async patterns → maps to IAsyncOperation, co_await

Key Concepts:

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: Projects 1-6 completed, understanding of C++17 features

Real world outcome:

A modern WinUI 3 app with:
- Navigation view (hamburger menu)
- Multiple pages with smooth transitions
- Responsive layout that adapts to window size
- Dark/light theme toggle (respects system setting)
- Modern controls: InfoBar, TeachingTip, ProgressRing
- Acrylic and Mica backgrounds
- Notification system using App.Notifications
- Settings page that persists preferences
- About page with version info

Implementation Hints:

WinUI 3 is fundamentally different from Win32:

  1. Project Setup:
    • Install Visual Studio 2022 with “Windows application development” workload
    • Select “C++ WinUI app development tools”
    • Create project: “Blank App, Packaged (WinUI 3 in Desktop)”
  2. Understanding C++/WinRT:
    • WinRT types are projected to C++ classes
    • winrt:: namespace for runtime types
    • Smart pointers handle lifetime automatically
    • Async returns IAsyncOperation<T>, use co_await
  3. XAML Structure: 
    <Window ...>
    <NavigationView x:Name="NavView">
        <NavigationView.MenuItems>
            <NavigationViewItem Content="Home" Tag="home"/>
            <NavigationViewItem Content="Settings" Tag="settings"/>
        </NavigationView.MenuItems>
        <Frame x:Name="ContentFrame"/>
    </NavigationView>
</Window>
  4. Code-Behind Pattern:
    • MainWindow.xaml.h/cpp contains logic
    • Access XAML elements by x:Name
    • Connect events in XAML or code
    • XAML compiler generates stubs from .idl files
  5. Navigation:
    • NavigationView handles menu
    • Frame hosts pages
    • On selection: ContentFrame().Navigate(xaml_typename<HomePage>())
  6. Theming:
    • Set RequestedTheme in App.xaml
    • Or use Application.Current.RequestedTheme
    • Acrylic: <NavigationView Background="{ThemeResource NavigationViewDefaultPaneBackground}">

Key Differences from Win32:

  • No message loop (WinUI has its own run loop)
  • No HWNDs at application level (though WinUI uses them internally)
  • Declarative UI instead of CreateWindow calls
  • Properties and events instead of messages

Learning milestones:

  1. App builds and runs → You understand WinUI setup
  2. Navigation works → You understand XAML and pages
  3. Theme switching works → You understand WinUI styling
  4. Async file operations work → You understand C++/WinRT async
  5. You can compare to Win32 → You understand the abstraction layers

Project 11: WinUI 3 Without XAML (Pure C++)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++ (C++/WinRT)
  • Alternative Programming Languages: None (this is framework-specific)
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 1. The “Resume Gold”
  • Difficulty: Level 4: Expert
  • Knowledge Area: WinUI 3 / C++/WinRT Internals
  • Software or Tool: Visual Studio 2022, Windows App SDK
  • Main Book: None (community-driven knowledge)

What you’ll build: A WinUI 3 application written entirely in C++ without any XAML files—creating all UI elements programmatically and understanding what XAML compiles to.

Why it teaches WinUI internals: XAML is compiled to code. By building without XAML, you see exactly what the framework does: object construction, property setting, event connection. This deep understanding helps debug complex WinUI issues.

Core challenges you’ll face:

  • Programmatic UI construction → maps to element instantiation, property setting
  • Resource handling without XAML → maps to ResourceDictionary, themes
  • Event hookup without XAML → maps to delegates, event handlers
  • Layout without XAML → maps to Panels, Grid row/column definitions
  • Understanding XAML compilation → maps to what .g.h files contain

Key Concepts:

Difficulty: Expert Time estimate: 1-2 weeks Prerequisites: Project 10 completed, strong C++ skills

Real world outcome:

A WinUI 3 app entirely in C++ that:
- Creates a Window with title
- Builds a layout with Grid/StackPanel
- Adds buttons, text blocks, input controls
- Handles events with C++ lambdas
- Applies styles programmatically
- Responds to theme changes
- Demonstrates that XAML is "just" syntax sugar

Implementation Hints:

This is unsupported by Microsoft, so expect friction:

  1. Minimal Setup:
    • Remove all .xaml files
    • Keep the .appxmanifest
    • Modify App to not load XAML resources
  2. Creating the Window: 
    #include <winrt/Microsoft.UI.Xaml.h>

auto window = Window();
window.Title(L"Pure C++ WinUI");
  3. Building UI Programmatically: 
    auto grid = Grid();
auto row1 = RowDefinition();
row1.Height(GridLengthHelper::FromPixels(50));
grid.RowDefinitions().Append(row1);

auto button = Button();
button.Content(box_value(L"Click Me"));
Grid::SetRow(button, 0);
grid.Children().Append(button);

window.Content(grid);
  4. Event Handling: 
    button.Click([](IInspectable const&, RoutedEventArgs const&) {
    // Handle click
});
  5. Challenges:
    • No x:Bind—must set up bindings manually
    • Resources harder to access
    • Styles require programmatic application
    • Some features may not work (XAML hot reload, designer)
  6. Learning Value:
    • See exactly what every XAML element translates to
    • Understand WinUI object model at deepest level
    • Debug issues others can’t because you know the internals

Learning milestones:

  1. Window appears with content → You understand element construction
  2. Layout works → You understand panels and attached properties
  3. Events work → You understand WinRT delegates
  4. Compare to XAML version → You understand the translation
  5. You can explain what XAML compiles to → Deep understanding achieved

Project 12: UWP Application with C++/WinRT

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++ (C++/WinRT)
  • Alternative Programming Languages: C++/CX (legacy)
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 3: Advanced
  • Knowledge Area: UWP / Windows Runtime
  • Software or Tool: Visual Studio 2022, Windows 10/11 SDK
  • Main Book: (No single book) Microsoft Learn UWP Documentation

What you’ll build: A Universal Windows Platform app that accesses UWP-specific capabilities: live tiles, notifications, background tasks, and device APIs—understanding the sandboxed app model.

Why it teaches UWP: UWP is the app model for Windows Store distribution. Understanding its sandboxing, capabilities model, and lifecycle is essential for publishing apps and accessing modern Windows features.

Core challenges you’ll face:

  • App lifecycle → maps to suspend/resume, state preservation
  • Capabilities and permissions → maps to Package.appxmanifest
  • Live tiles and notifications → maps to tile templates, ToastNotification
  • Background tasks → maps to BackgroundTaskBuilder, triggers
  • File access in sandbox → maps to StorageFile, pickers, future access list

Key Concepts:

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Project 10 completed, understanding of sandboxed apps

Real world outcome:

A UWP app demonstrating:
- Live tile that updates with dynamic content
- Toast notifications with actions
- Background task that runs periodically
- Access to camera/microphone (with permissions)
- File picker and brokerless file access
- Settings roaming across devices
- Proper suspend/resume with state preservation
- Share contract (receive/send data)
- Protocol activation (custom URL scheme)

Implementation Hints:

UWP is about controlled access:

  1. App Lifecycle:
    • OnLaunched: App started fresh
    • OnActivated: App activated by contract/protocol
    • Suspending: Save state, you may be terminated
    • Resuming: Restore state
  2. Capabilities (Package.appxmanifest): 
    <Capabilities>
    <Capability Name="internetClient"/>
    <DeviceCapability Name="webcam"/>
    <DeviceCapability Name="microphone"/>
</Capabilities>
  3. Live Tiles:
    • Create TileContent with template
    • Create TileNotification
    • Get TileUpdater and call Update()
    • For scheduled updates, use ScheduledTileNotification
  4. Toast Notifications: 
    ToastContent content = ...;  // Build with ToastContentBuilder
ToastNotification notification(content.GetXml());
ToastNotificationManager::CreateToastNotifier().Show(notification);
  5. Background Tasks:
    • Register in manifest with trigger type
    • Implement IBackgroundTask
    • Create BackgroundTaskBuilder
    • Request access with BackgroundExecutionManager
  6. File Access:
    • Can’t use paths directly outside app folder
    • Use FileOpenPicker, get StorageFile
    • For future access: FutureAccessList.Add()
    • Some locations need capabilities

UWP vs Win32:

  • UWP runs in AppContainer (sandbox)
  • No raw Win32 API access (mostly)
  • Better security, worse compatibility
  • Store distribution required capabilities

Learning milestones:

  1. App runs and handles lifecycle → You understand UWP basics
  2. Live tile updates → You understand tile APIs
  3. Background task runs → You understand app extensions
  4. Capabilities work → You understand the permission model
  5. You can explain sandbox limitations → You understand UWP deeply

Project 13: WPF Control in Win32 Application (Interop)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++/CLI
  • Alternative Programming Languages: C++ with CLR hosting
  • Coolness Level: Level 4: Hardcore Tech Flex
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 4: Expert
  • Knowledge Area: WPF Interop / CLR Hosting
  • Software or Tool: Visual Studio, .NET Framework/Core
  • Main Book: “Windows via C/C++” by Jeffrey Richter

What you’ll build: A native Win32 application that hosts a WPF control—demonstrating managed/native interop and allowing use of WPF’s rich controls in native applications.

Why it teaches WPF interop: Sometimes you have existing C++ code but want WPF’s rich controls (charts, animations, data grids). Understanding interop lets you bridge these worlds without rewriting everything.

Core challenges you’ll face:

  • C++/CLI compilation → maps to /clr compiler switch, mixed assemblies
  • HwndSource for hosting → maps to WPF window handle wrapper
  • Marshaling data → maps to gcroot, pin_ptr, marshaling
  • Threading issues → maps to Dispatcher, STAThread
  • Lifetime management → maps to preventing premature GC

Key Concepts:

Difficulty: Expert Time estimate: 2-3 weeks Prerequisites: Projects 1-6 completed, understanding of .NET basics

Real world outcome:

A Win32 application that:
- Hosts a WPF UserControl in a child window region
- Passes data from C++ to WPF (displays in WPF chart/grid)
- Receives events from WPF controls
- Handles focus correctly between native and WPF
- Doesn't leak memory or GC handles
- Shows complex WPF visuals (animations, 3D) in native frame
- Demonstrates mixed UI (Win32 menus, WPF content area)

Implementation Hints:

Two main approaches:

Approach 1: C++/CLI Bridge (recommended)

  1. Create a C++/CLI DLL:
    • New project: “CLR Class Library (.NET Framework)”
    • This DLL compiles with /clr
    • Export pure native functions that internally use managed code
  2. Create HwndSource: 
    // In C++/CLI DLL
#include <vcclr.h>
using namespace System::Windows::Interop;

HwndSource^ CreateWpfHost(HWND parent) {
    HwndSourceParameters^ params = gcnew HwndSourceParameters();
    params->ParentWindow = IntPtr(parent);
    params->WindowStyle = WS_CHILD | WS_VISIBLE;
    // ... set position, size

    HwndSource^ source = gcnew HwndSource(*params);
    source->RootVisual = gcnew MyWpfControl();
    return source;
}
  3. Export Native Interface: 
    // Header for pure native consumers
extern "C" {
    __declspec(dllexport) void* CreateWpfHost(HWND parent);
    __declspec(dllexport) void DestroyWpfHost(void* handle);
    __declspec(dllexport) void UpdateWpfData(void* handle, const char* json);
}
  4. Handle Threading:
    • WPF requires STA (Single-Threaded Apartment)
    • Either run Win32 message loop on STA thread
    • Or create separate STA thread for WPF

Approach 2: Native CLR Hosting

  1. Use ICLRRuntimeHost to host CLR
  2. Load WPF assembly
  3. Call managed methods via CorBindToRuntimeEx
  4. More complex, but no /clr needed in main app

Key Considerations:

  • Focus: WPF and Win32 handle focus differently
  • Keyboard: May need message translation
  • DPI: Both sides must agree on scaling
  • Lifetime: Pin managed objects, prevent premature GC

Learning milestones:

  1. WPF control appears in Win32 window → You understand HwndSource
  2. Data flows from C++ to WPF → You understand marshaling
  3. Events flow from WPF to C++ → You understand callbacks
  4. No memory leaks → You understand mixed lifetime
  5. Professional integration → You can bridge the worlds

Project 14: Multi-Threaded UI Application

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C, Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Win32 Threading / UI Synchronization
  • Software or Tool: Visual Studio, Windows SDK
  • Main Book: “Windows via C/C++” by Jeffrey Richter

What you’ll build: An application that performs long operations on background threads while keeping the UI responsive, with proper progress reporting, cancellation, and thread-safe UI updates.

Why it teaches threading with UI: UI programming requires understanding that the message loop runs on a single thread. Learning to offload work, communicate back safely, and handle cancellation is essential for responsive applications.

Core challenges you’ll face:

  • UI thread ownership → maps to only UI thread can touch controls
  • Posting messages from threads → maps to PostMessage vs SendMessage
  • Progress reporting → maps to custom messages, shared state
  • Cancellation → maps to event signaling, checking cancel flag
  • Synchronization → maps to critical sections, atomic operations

Key Concepts:

  • Threading Fundamentals: “Windows via C/C++” Chapters 6-8 - Jeffrey Richter
  • Message Posting: “Programming Windows, 5th Edition” Chapter 20 - Charles Petzold
  • Synchronization: “Windows via C/C++” Chapters 8-9 - Jeffrey Richter
  • Thread Pools: Microsoft Learn - Thread Pool

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: Projects 1-6 completed, understanding of threading concepts

Real world outcome:

An application that:
- Downloads files in background
- Shows real-time progress bar that updates smoothly
- Allows cancellation of in-progress operations
- Queues multiple tasks with parallel execution
- Never freezes UI during operations
- Shows notifications on completion
- Handles errors gracefully on worker threads
- Uses thread pool for efficiency
- Demonstrates all UI updates happen on UI thread

Implementation Hints:

The golden rule: Only the UI thread can touch UI controls.

  1. Starting Background Work: 
    // Option 1: CreateThread
HANDLE thread = CreateThread(NULL, 0, WorkerProc, data, 0, NULL);

// Option 2: Thread Pool (preferred)
QueueUserWorkItem(WorkerProc, data, 0);

// Option 3: C++ std::thread
std::thread worker([data]() { DoWork(data); });
  2. Communicating Back to UI:
    • Define custom messages: #define WM_PROGRESS (WM_USER + 1)
    • From worker: PostMessage(hwnd, WM_PROGRESS, percent, 0)
    • UI thread handles WM_PROGRESS in WndProc
    • Never use SendMessage from worker (can deadlock)
  3. Shared Data Access: 
    typedef struct {
    CRITICAL_SECTION cs;
    volatile BOOL cancelled;
    volatile int progress;
} WorkData;

// Worker checks:
EnterCriticalSection(&data->cs);
if (data->cancelled) { LeaveCS; return; }
LeaveCs...
  4. Cancellation Pattern:
    • Set cancelled flag from UI thread
    • Worker periodically checks flag
    • Worker posts WM_WORKERCOMPLETE when done/cancelled
    • UI thread handles cleanup
  5. Thread Pool Benefits:
    • Reuses threads (faster startup)
    • Manages thread count
    • Use QueueUserWorkItem or newer CreateThreadpoolWork
  6. Modern C++ Alternative:
    • std::async returns std::future
    • But still need to post to UI thread for updates
    • Consider PPL (Parallel Patterns Library)

Think about: What happens if you close the window while work is in progress? How do you ensure cleanup?

Learning milestones:

  1. Work runs without freezing UI → You understand background threading
  2. Progress updates correctly → You understand message posting
  3. Cancellation works → You understand thread signaling
  4. Multiple concurrent operations → You understand thread pools
  5. Clean shutdown → You understand lifecycle management

Project 15: DPI-Aware Application (High DPI Support)

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C, Rust
  • Coolness Level: Level 2: Practical but Forgettable
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Win32 DPI / Display Scaling
  • Software or Tool: Visual Studio, Windows SDK
  • Main Book: None (Microsoft documentation)

What you’ll build: An application that renders correctly at any DPI setting, with per-monitor DPI awareness, dynamic DPI change handling, and proper scaling of all UI elements.

Why it teaches DPI awareness: High DPI displays are everywhere. Applications that ignore DPI look blurry or too small. Understanding DPI scaling is essential for professional Windows applications.

Core challenges you’ll face:

  • Declaring DPI awareness → maps to manifest settings, SetProcessDpiAwarenessContext
  • Scaling coordinates → maps to logical vs physical pixels
  • Per-monitor DPI → maps to WM_DPICHANGED, GetDpiForWindow
  • Scaling images → maps to multiple icon sizes, image scaling
  • Dialog scaling → maps to dialog units, font sizes

Key Concepts:

Difficulty: Intermediate Time estimate: 1 week Prerequisites: Projects 1-3 completed

Real world outcome:

An application that:
- Looks crisp at 100%, 125%, 150%, 200%, 300% scaling
- Handles dragging between monitors with different DPI
- Dynamically resizes when user changes DPI (no restart)
- Icons/images stay sharp at all scales
- Text is readable and properly sized
- Dialogs scale correctly
- Custom-drawn elements scale properly

Implementation Hints:

  1. Declare DPI Awareness (application manifest): 
    <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
        <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
            PerMonitorV2
        </dpiAwareness>
    </windowsSettings>
</application>
  2. Or Programmatically: 
    SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2);
  3. DPI Awareness Levels:
    • Unaware: System scales bitmap (blurry)
    • System Aware: Uses primary monitor DPI for all
    • Per-Monitor: Different DPI per monitor
    • Per-Monitor V2: Plus non-client scaling, dialog scaling
  4. Handle WM_DPICHANGED: 
    case WM_DPICHANGED: {
    RECT* suggested = (RECT*)lParam;
    SetWindowPos(hwnd, NULL,
        suggested->left, suggested->top,
        suggested->right - suggested->left,
        suggested->bottom - suggested->top,
        SWP_NOZORDER | SWP_NOACTIVATE);
    // Recreate scaled resources
    UINT dpi = HIWORD(wParam);
    RecreateResources(dpi);
    return 0;
}
  5. Scaling Calculations: 
    int ScaleForDpi(int value, UINT dpi) {
    return MulDiv(value, dpi, 96);
}

// Get current DPI
UINT dpi = GetDpiForWindow(hwnd);
int scaledSize = ScaleForDpi(100, dpi);  // 100 DIP → physical pixels
  6. Images:
    • Provide multiple sizes: 16, 24, 32, 48, 256 pixels
    • Use LoadImage with desired size, let Windows choose best
    • Or use vector graphics (WIC, Direct2D)

Learning milestones:

  1. App is DPI-aware (not scaled) → You understand manifest settings
  2. Multi-monitor works → You understand per-monitor DPI
  3. Dynamic DPI change works → You understand WM_DPICHANGED
  4. Images scale correctly → You understand resource management
  5. Everything is crisp at all scales → Full DPI mastery

Project 16: Win32 Application with Modern Visual Styles

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C
  • Alternative Programming Languages: C++, Rust
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 2. The “Micro-SaaS / Pro Tool”
  • Difficulty: Level 2: Intermediate
  • Knowledge Area: Win32 Theming / Visual Styles
  • Software or Tool: Visual Studio, Windows SDK
  • Main Book: None (Microsoft documentation)

What you’ll build: A Win32 application that uses Windows visual styles, dark mode support (Windows 10+), and custom theming—making your classic Win32 app look modern.

Why it teaches visual styles: Win32 apps don’t get modern styling by default. Understanding the Common Controls manifest, theme APIs, and dark mode support lets you build native apps that fit with modern Windows aesthetics.

Core challenges you’ll face:

  • Enabling visual styles → maps to ComCtl32 v6, manifest
  • Dark mode detection → maps to registry, ShouldAppsUseDarkMode
  • Custom dark mode rendering → maps to theme overrides, owner-draw
  • Mica/Acrylic effects → maps to DwmSetWindowAttribute (Win11)
  • High contrast support → maps to accessibility, theme colors

Key Concepts:

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Projects 1-6 completed

Real world outcome:

A Win32 application that:
- Has modern button, scrollbar, and control styling
- Respects Windows light/dark mode setting
- Updates in real-time when user changes theme
- Has Mica backdrop on Windows 11
- Handles high contrast themes correctly
- Custom controls adapt to theme
- Status bar and toolbars match theme
- Looks like a modern Windows app

Implementation Hints:

  1. Enable Visual Styles (application manifest): 
    <dependency>
    <dependentAssembly>
        <assemblyIdentity type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"/>
    </dependentAssembly>
</dependency>
  2. Initialize Common Controls: 
    INITCOMMONCONTROLSEX icex = {
    sizeof(INITCOMMONCONTROLSEX),
    ICC_WIN95_CLASSES | ICC_STANDARD_CLASSES
};
InitCommonControlsEx(&icex);
  3. Detect Dark Mode (Windows 10 1809+): 
    // Undocumented API (use dynamic loading)
typedef BOOL(WINAPI* fnShouldAppsUseDarkMode)();
HMODULE uxtheme = LoadLibrary(L"uxtheme.dll");
auto ShouldAppsUseDarkMode = (fnShouldAppsUseDarkMode)
    GetProcAddress(uxtheme, MAKEINTRESOURCEA(132));
BOOL darkMode = ShouldAppsUseDarkMode ? ShouldAppsUseDarkMode() : FALSE;
  4. Apply Dark Title Bar (Windows 10): 
    BOOL dark = TRUE;
DwmSetWindowAttribute(hwnd, DWMWA_USE_IMMERSIVE_DARK_MODE, &dark, sizeof(dark));
  5. Mica Effect (Windows 11): 
    DWM_SYSTEMBACKDROP_TYPE backdrop = DWMSBT_MAINWINDOW;
DwmSetWindowAttribute(hwnd, DWMWA_SYSTEMBACKDROP_TYPE, &backdrop, sizeof(backdrop));
  6. Theme Change Notification:
    • Handle WM_SETTINGCHANGE (may be “ImmersiveColorSet”)
    • Handle WM_THEMECHANGED for visual style changes
    • Repaint/recreate themed resources
  7. Custom Control Dark Mode:
    • Owner-draw controls with dark colors
    • Use GetSysColor() with dark mode awareness
    • Or draw directly with appropriate brushes

Learning milestones:

  1. Visual styles enabled → Controls look modern
  2. Dark mode detected → You understand the APIs
  3. Title bar darkens → You understand DWM
  4. Controls adapt to theme → You understand theming
  5. Mica effect works → You’re fully modern

Project 17: Accessibility-First Application

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++
  • Alternative Programming Languages: C
  • Coolness Level: Level 3: Genuinely Clever
  • Business Potential: 3. The “Service & Support” Model
  • Difficulty: Level 3: Advanced
  • Knowledge Area: Win32 Accessibility / UI Automation
  • Software or Tool: Visual Studio, Windows SDK, Accessibility Insights
  • Main Book: None (Microsoft documentation)

What you’ll build: An application designed from the start for accessibility: screen reader support, keyboard navigation, high contrast, UI Automation providers—usable by everyone.

Why it teaches accessibility: Accessibility is often an afterthought but should be foundational. Understanding UI Automation, screen reader interactions, and keyboard navigation makes you a better UI developer and opens your app to more users.

Core challenges you’ll face:

  • UI Automation providers → maps to IRawElementProviderSimple, patterns
  • Keyboard navigation → maps to tab stops, arrow keys, accelerators
  • Screen reader support → maps to accessible names, roles, states
  • High contrast themes → maps to system colors, not hardcoded colors
  • Focus indication → maps to visible focus rectangles

Key Concepts:

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Projects 1-6 completed

Real world outcome:

An application that:
- Works fully with keyboard only (no mouse needed)
- Screen readers (Narrator, NVDA) announce all elements
- Custom controls have proper accessibility properties
- High contrast mode works correctly
- Focus is always visible
- Passes Accessibility Insights automated tests
- Has accessible names, roles, and states
- Keyboard shortcuts are documented and work

Implementation Hints:

  1. Basic Keyboard Navigation:
    • Use WS_TABSTOP for focusable controls
    • Handle WM_GETDLGCODE for arrow key behavior
    • Ensure logical tab order
    • Draw focus rectangles (DrawFocusRect or WM_NCPAINT)
  2. Accessible Names:
    • Standard controls: Use associated label (STATIC before EDIT)
    • Or set WM_GETOBJECT/IAccessible implementation
    • For custom controls: Implement IRawElementProviderSimple
  3. UI Automation for Custom Controls: 
    // Implement IRawElementProviderSimple
HRESULT GetProviderOptions(ProviderOptions* pVal) {
    *pVal = ProviderOptions_ServerSideProvider;
    return S_OK;
}

HRESULT GetPropertyValue(PROPERTYID propertyId, VARIANT* pVal) {
    if (propertyId == UIA_NamePropertyId) {
        pVal->vt = VT_BSTR;
        pVal->bstrVal = SysAllocString(L"My Custom Control");
        return S_OK;
    }
    // ... handle other properties
}
  4. Handle WM_GETOBJECT: 
    case WM_GETOBJECT:
    if (lParam == UiaRootObjectId) {
        return UiaReturnRawElementProvider(hwnd, wParam, lParam,
            &myProvider);
    }
    break;
  5. High Contrast:
    • Use GetSysColor() for colors, not hardcoded values
    • Check SystemParametersInfo(SPI_GETHIGHCONTRAST)
    • Handle WM_SYSCOLORCHANGE
    • Test with high contrast themes
  6. Testing:
    • Use Accessibility Insights tool
    • Test with Narrator (Windows+Ctrl+Enter)
    • Test keyboard-only navigation
    • Test at 200%+ DPI

Learning milestones:

  1. Keyboard navigation works → You understand focus management
  2. Standard controls work with Narrator → You understand system accessibility
  3. Custom controls announce properly → You understand UI Automation
  4. High contrast works → You understand theme support
  5. Passes automated accessibility checks → Full accessibility mastery

Project Comparison Table

Project Difficulty Time Depth of Understanding Fun Factor
1. Minimal Window Beginner Weekend ⭐⭐⭐ ⭐⭐
2. Message Spy Beginner Weekend ⭐⭐⭐⭐ ⭐⭐⭐
3. Custom Control Intermediate 1-2 weeks ⭐⭐⭐⭐ ⭐⭐⭐
4. Paint Program Intermediate 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐
5. GDI+ Image Viewer Intermediate 1-2 weeks ⭐⭐⭐ ⭐⭐⭐⭐
6. Notepad Clone Intermediate 2 weeks ⭐⭐⭐⭐ ⭐⭐⭐
7. File Explorer Pane Advanced 3-4 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐
8. MDI Application Intermediate 1-2 weeks ⭐⭐⭐ ⭐⭐
9. Dialog Application Intermediate 1 week ⭐⭐⭐ ⭐⭐
10. WinUI 3 Hello World Advanced 1-2 weeks ⭐⭐⭐⭐ ⭐⭐⭐⭐
11. WinUI Without XAML Expert 1-2 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐
12. UWP Application Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐
13. WPF Interop Expert 2-3 weeks ⭐⭐⭐⭐⭐ ⭐⭐⭐
14. Multi-Threaded UI Advanced 1-2 weeks ⭐⭐⭐⭐ ⭐⭐⭐
15. DPI-Aware App Intermediate 1 week ⭐⭐⭐ ⭐⭐
16. Modern Visual Styles Intermediate 1-2 weeks ⭐⭐⭐ ⭐⭐⭐⭐
17. Accessibility App Advanced 2-3 weeks ⭐⭐⭐⭐ ⭐⭐⭐

Phase 1: Win32 Foundation (Weeks 1-4)

  1. Project 1: Minimal Window - Understand the basics
  2. Project 2: Message Spy - See how Windows communicates
  3. Project 4: Paint Program - Learn GDI thoroughly
  4. Project 6: Notepad Clone - Master common controls and dialogs

Phase 2: Advanced Win32 (Weeks 5-8)

  1. Project 3: Custom Control - Understand control internals
  2. Project 7: File Explorer Pane - Master advanced controls and shell
  3. Project 14: Multi-Threaded UI - Learn threading with UI

Phase 3: Modern Frameworks (Weeks 9-12)

  1. Project 10: WinUI 3 Hello World - Transition to modern UI
  2. Project 12: UWP Application - Understand the sandboxed model
  3. Project 16: Modern Visual Styles - Modernize Win32 apps

Phase 4: Specialization (Weeks 13-16)

Choose based on your needs:

  • Native Interop Path: Projects 11, 13
  • Graphics Path: Project 5, then Direct2D/DirectX
  • Enterprise Path: Projects 15, 17, 9

Final Capstone Project: Modern Desktop Application Suite

  • File: LEARN_WINDOWS_GUI_APPLICATION_MODELS_DEEP_DIVE.md
  • Main Programming Language: C++ (mixed Win32 + WinUI 3)
  • Alternative Programming Languages: None (this is comprehensive)
  • Coolness Level: Level 5: Pure Magic (Super Cool)
  • Business Potential: 4. The “Open Core” Infrastructure
  • Difficulty: Level 5: Master
  • Knowledge Area: Full Windows GUI Stack
  • Software or Tool: Visual Studio 2022, Windows SDK, Windows App SDK
  • Main Book: All previous books combined

What you’ll build: A professional-quality desktop application that combines Win32 for performance-critical components, WinUI 3 for modern UI, with accessibility, theming, and multi-window support—demonstrating mastery of the entire Windows GUI stack.

Why this is the capstone: This project requires synthesizing everything: Win32 window management, GDI for custom drawing, modern WinUI controls, threading, DPI awareness, accessibility, and theming. It proves you can build production-quality Windows applications.

The Application: “DevNote” - A Developer’s Notebook

A note-taking application for developers with:

  • WinUI 3 main interface with navigation, modern controls
  • Win32 text editor core for performance (syntax highlighting)
  • GDI+ image annotation tool for screenshots
  • File explorer sidebar with shell integration
  • Multi-window support (tear-off tabs to new windows)
  • Full accessibility for screen readers
  • Dark mode and theming
  • Background sync with cloud storage
  • Keyboard-driven workflow

Core challenges you’ll face:

  • Mixing WinUI and Win32 → maps to DesktopWindowXamlSource, HWND interop
  • High-performance text rendering → maps to DirectWrite or custom GDI
  • Complex window management → maps to multi-window, docking, tear-off
  • State persistence → maps to settings, recent files, window layout
  • Production polish → maps to installer, updates, crash reporting

Implementation Hints:

This is a major undertaking, so structure carefully:

  1. Architecture: 
    DevNote.exe (WinUI 3 main application)
├── MainWindow (WinUI 3 NavigationView)
│   ├── NotesPage (WinUI 3 ListView + Editor)
│   │   └── EditorControl (Win32 child window)
│   ├── ExplorerPage (Win32 TreeView/ListView)
│   └── SettingsPage (WinUI 3 settings)
└── Floating windows (tear-off, annotation)
  2. Win32 in WinUI 3:
    • Use DesktopWindowXamlSource for reverse (XAML in Win32)
    • Or create Win32 child windows in WinUI with GetWindowHandle()
    • Handle message routing between frameworks
  3. Editor Component (Win32 for speed):
    • Custom window class with owner-draw
    • DirectWrite for text rendering
    • Scintilla-style approach for syntax highlighting
    • Efficient data structure for large files
  4. Project Structure:
    • Core library (pure C++, no UI)
    • Win32 components (editor, explorer)
    • WinUI 3 shell (main window, pages)
    • Shared resources (icons, strings)
  5. Polish Items:
    • MSIX packaging for distribution
    • Auto-update mechanism
    • Crash reporting (minidump)
    • Telemetry (opt-in)
    • Help documentation

Learning milestones:

  1. WinUI shell with navigation → You’ve mastered WinUI 3
  2. Win32 editor works within WinUI → You understand interop
  3. File explorer with shell integration → You’ve mastered shell APIs
  4. All windows handle DPI/theme changes → You understand modern requirements
  5. Application is accessible → You’ve built inclusively
  6. Application is shippable → You’re a Windows developer

Summary

# Project Main Language
1 The Minimal Window C
2 Message Spy C
3 Custom Control from Scratch C
4 Paint Program C++
5 GDI+ Image Viewer & Editor C++
6 Notepad Clone C
7 File Explorer Pane C++
8 MDI Application C++
9 Dialog-Based Application C
10 WinUI 3 Hello World C++ (C++/WinRT)
11 WinUI 3 Without XAML C++ (C++/WinRT)
12 UWP Application C++ (C++/WinRT)
13 WPF Control in Win32 C++/CLI
14 Multi-Threaded UI Application C++
15 DPI-Aware Application C++
16 Modern Visual Styles C
17 Accessibility-First Application C++
Final DevNote - Developer’s Notebook C++ (mixed)

Essential Resources

Books

  • “Programming Windows, 5th Edition” by Charles Petzold - The definitive Win32 guide
  • “Windows via C/C++” by Jeffrey Richter - Advanced Windows programming
  • “Windows System Programming” by Johnson M. Hart - System-level programming

Online Resources

Tools

  • Visual Studio 2022 (Community is free)
  • Windows SDK
  • Spy++ (included with Visual Studio)
  • Accessibility Insights
  • Process Monitor / Process Explorer (Sysinternals)

Master these projects and you’ll understand Windows GUI programming at every level—from raw Win32 messages to modern XAML, from GDI pixels to Fluent Design.