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

Coming soon...