Building a windows app from scratch

End goal is to publish a windows app in the windows app store

Background & Prerequisites — What You Need to Know Before Writing This Blog

Building a Windows app from scratch and publishing to the Microsoft Store involves deep understanding of multiple layers — from how code becomes an executable, to the packaging and submission process. Below is everything you need to cover.

1. How an .exe File is Built — Compilation Pipeline

Why: The blog promises to explore "building an .exe from scratch." This requires understanding each step of compilation.

• Source code → Preprocessor — For C/C++, the preprocessor handles #include, #define, #ifdef. It produces a single translation unit (expanded source).
• Preprocessor → Compiler — The compiler translates C/C++ source into assembly language (.asm), then assembles it into an object file (.obj on Windows, .o on Unix). Object files contain machine code but with unresolved external references (symbols).
• Object files → Linker — The linker resolves symbols across multiple .obj files and libraries. It produces the final .exe (or .dll). The linker:
  • Resolves function calls to their actual addresses
  • Merges code and data sections
  • Embeds metadata (entry point, import table, export table)
• PE (Portable Executable) Format — The .exe file format on Windows. Key sections:
  • .text — executable code
  • .data — initialized global variables
  • .rdata — read-only data (constants, import descriptors)
  • .rsrc — resources (icons, dialogs, version info)
  • Import Address Table (IAT) — Lists which DLLs and functions the exe depends on
  • Entry point — The address where execution begins (main() or WinMain())

2. DLLs (Dynamic Link Libraries)

Why: Any non-trivial Windows app uses DLLs. Understanding them is core to the blog.

• What is a DLL — A shared library loaded at runtime. Multiple processes can share a single DLL in memory. Contains exported functions and data.
• Static linking vs Dynamic linking — Static: library code is copied into the exe at compile time (larger exe, no runtime dependency). Dynamic: exe references the DLL and loads it at runtime (smaller exe, DLL must be present).
• Implicit vs Explicit loading — Implicit: linker resolves DLL at load time via import library (.lib). Explicit: code calls LoadLibrary() and GetProcAddress() at runtime.
• DLL Hell — Version conflicts when multiple apps need different versions of the same DLL. Modern Windows solves this with SxS (Side-by-Side) assemblies and app-local deployment.
• Creating a DLL — Write functions with __declspec(dllexport), compile to .dll + .lib (import library). Consumers use the .lib to implicitly link, or LoadLibrary to explicitly load.

3. Win32 API — The Foundation

Why: Even modern frameworks (WinUI, WPF) sit on top of Win32. Understanding it provides the mental model.

• Window creation — RegisterClassEx() → CreateWindowEx() → Message Loop (GetMessage, TranslateMessage, DispatchMessage). Every GUI app runs a message pump.
• Message handling — The WndProc callback receives messages (WM_PAINT, WM_DESTROY, WM_COMMAND, etc.). You handle messages to respond to user input, window events, and system notifications.
• GDI (Graphics Device Interface) — The original drawing API. BeginPaint(), TextOut(), BitBlt(), pens, brushes, fonts. Still used under the hood by many frameworks.
• Common Controls — Buttons, listboxes, treeviews, toolbars from comctl32.dll. Created via CreateWindowEx with specific class names.
• Resources — Icons, cursors, dialogs, string tables, version info compiled into the .exe via .rc (resource script) files processed by rc.exe.

4. Modern Windows App Frameworks

Why: You likely won't build the final app in raw Win32. Understanding modern options is essential.

• WinUI 3 — The recommended modern UI framework from Microsoft. XAML-based, runs on the Windows App SDK. Supports Fluent Design, adaptive layouts, dark/light themes. Accessible via C# or C++/WinRT.
• WPF (Windows Presentation Foundation) — Older but mature XAML framework. Runs on .NET. Rich data binding, MVVM pattern, extensive control library. Not the latest but still widely used.
• WinForms — The simplest desktop framework. Drag-and-drop designer, event-driven programming. Good for quick internal tools. Runs on .NET.
• .NET MAUI — Cross-platform (Windows, macOS, iOS, Android) using C# and XAML. If you want one codebase for multiple platforms.
• Electron / Tauri — Web-tech-based desktop apps. Electron uses Chromium + Node.js (heavy). Tauri uses system webview + Rust (lightweight). Both can be packaged for the Store.

5. MSIX Packaging

Why: The Microsoft Store requires MSIX packages. You cannot submit a raw .exe.

• What is MSIX — The modern packaging format for Windows apps. It's a container that bundles your app binaries, assets, manifest, and dependencies. Provides clean install/uninstall, automatic updates, and sandboxing.
• AppxManifest.xml — The manifest file declaring your app's identity (name, publisher, version), capabilities (file system access, internet, camera), entry point, visual assets, and supported extensions.
• Package Identity — Publisher ID (matches your MS Partner Center certificate), Package Name, Version. These must be consistent across updates.
• Tools for packaging —
  • MSIX Packaging Tool — GUI tool to capture an existing installer into MSIX
  • Visual Studio — Built-in MSIX packaging project template
  • makeappx.exe — Command-line tool to create .msix / .msixbundle from a folder layout
  • signtool.exe — Signs the package with a certificate (required for Store submission and sideloading)

6. Code Signing & Certificates

Why: Both sideloading and Store submission require signed packages.

• What is code signing — Cryptographically signing your executable/package to prove identity and integrity. Windows shows warnings for unsigned apps.
• Certificate types — Self-signed (for development/testing), OV (Organization Validated, for enterprise sideloading), EV (Extended Validation, highest trust, avoids SmartScreen warnings).
• For Store submission — Microsoft signs the package during Store processing. You provide the Publisher CN (common name) that matches your Partner Center account.
• For sideloading — You must sign with a trusted certificate. Install the cert on target machines.

7. Microsoft Store Submission Process

Why: The end goal of the blog.

• Partner Center — The portal (https://partner.microsoft.com) where you manage Store submissions. Requires a developer account ($19 one-time /$99 for company).
• App reservation — Reserve your app name in the Store.
• Submission flow — Upload MSIX bundle → set pricing (free/paid/subscription) → fill product listing (description, screenshots, category) → age rating → provide submission notes → submit for certification.
• Certification requirements — App must launch without crashing, no malware, follows Store policies (no misleading claims, appropriate content ratings, no unauthorized use of IP). Typical review takes 24-48 hours.
• App updates — Same process: increment version in manifest, re-package, re-submit. Updates are delivered automatically to installed users.

8. Development Environment Setup

Why: Practical first step for the blog.

• Visual Studio 2022 — Community edition is free. Install workloads: ".NET Desktop Development" or "Desktop Development with C++" plus "Windows Application Development" for WinUI/UWP.
• Windows SDK — Provides headers, libraries, and tools for Win32 and WinRT development. Installed with Visual Studio.
• Windows App SDK — The framework for WinUI 3 apps. NuGet package Microsoft.WindowsAppSDK.
• Developer mode — Enable in Windows Settings → Developer Settings. Required for sideloading and debugging MSIX packages locally.

TODO / Remaining Work

• Set up Visual Studio 2022 with required workloads
• Write a minimal Win32 "Hello World" app in C++ and document the compilation/linking process
• Explain the PE format with a hex dump of the resulting .exe
• Create and use a DLL (both implicit and explicit linking)
• Build a simple WinUI 3 app with XAML and C#
• Package the app as MSIX using Visual Studio
• Sign the package for local sideloading
• Walk through the Partner Center submission process (with screenshots)
• Document the certification review experience
• Add architecture diagram showing compilation pipeline (Mermaid)
• Compare WinUI 3, WPF, and WinForms with a decision matrix

Quick-Start: Minimal WinUI 3 App

Once Visual Studio 2022 is installed with the Windows App SDK workload:

# Create a blank WinUI 3 packaged app
dotnet new winui -n HelloWinUI
cd HelloWinUI
dotnet build
dotnet run

The winui template scaffolds a packaged app with Package.appxmanifest, an App.xaml / MainWindow.xaml, and the Microsoft.WindowsAppSDK NuGet reference. Editing MainWindow.xaml and hitting F5 hot-reloads the UI.

Packaging and Submission Checklist

Before hitting Submit in Partner Center, verify:

• Package.appxmanifest identity: Name, Publisher (exact CN from Partner Center), Version (4-part, increments on every update)
• Visual assets: 44×44, 150×150, 310×150, 620×300, 71×71 — all in Assets/ and referenced in the manifest
• App launches from a fresh install on a clean Windows 11 VM (Hyper-V / Sandbox)
• No crashes in the first 60 seconds on low-end hardware (2C/4G)
• Age rating questionnaire completed (IARC)
• Store listing: description ≤ 10,000 chars, at least 1 screenshot per form factor, short & full description localized
• Privacy URL (required if app collects any data — even telemetry)
• Windows App Certification Kit (WACK) passes locally: Get-AppxPackage | Test-AppxPackage or via Visual Studio's "Create App Package" wizard

When every box above is ticked and you've successfully published one update to an existing submission, flip this post to status: published.