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.
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())
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.
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.
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.
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)
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.
Partner Center — The portal (https://partner.microsoft.com) where you manage Store submissions. Requires a developer account (19one−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.
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.
Once Visual Studio 2022 is installed with the Windows App SDK workload:
# Create a blank WinUI 3 packaged appdotnet new winui -n HelloWinUIcd HelloWinUIdotnet builddotnet 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.