Skip to content

Windows Setup And Verification

Windows Build Router

This page is the supported Windows workflow for toolchain setup, release builds, verification, and runtime diagnostics.

Audience

Use this page if you are building or validating the daemon on Windows. For day-to-day operation after the binaries already exist, go to Daily Operation.

Action Matrix

Goal Start here Typical follow-up
Prepare the machine for native builds Toolchain Setup Build the Release Artifacts
Produce the shipping binaries Build the Release Artifacts Launch Model
Verify lifecycle behavior first Preferred Verification Flow Daemon Diagnostics
Run an end-to-end seeded reminder check End-to-End Reminder Seeding Cleanup

Toolchain Setup

Install the native Windows Rust toolchain requirements:

  1. Install Visual Studio Build Tools 2022 or Visual Studio Community.
  2. Select Desktop development with C++.
  3. Install the Windows 10 or Windows 11 SDK.
  4. Install Rust with rustup from https://rustup.rs.

Verify the toolchain:

rustc --version
cargo --version

Why This Matters

The platform module depends on native Windows APIs for the tray app, toast notifications, resource embedding, and registry integration. A partial toolchain setup usually fails late, so verify the compiler first.

Build the Release Artifacts

From the repository root:

cd d:\Codes\full-calendar-remastered-ReminderApp
cargo build --release

Release outputs:

  • target\release\fcr-reminder.exe
  • target\release\fcr-reminder-cli.exe

Binary Roles

Use fcr-reminder.exe for the normal GUI/tray runtime and fcr-reminder-cli.exe for terminal commands, diagnostics, and scripted lifecycle control.

Launch Model

Windows release behavior:

  • fcr-reminder.exe is built as a GUI-subsystem app, so double-clicking it should not open a console window
  • the daemon starts in the tray
  • the tray menu exposes Status: Running, Info, and Quit
  • if another instance is already active, a duplicate launch exits and reuses the running daemon

For visible logs:

.\target\release\fcr-reminder.exe --debug

Preferred Verification Flow

Use Code-Backed Checks First

Start with executable verification that can fail deterministically before relying on manual tray interaction.

Recommended order:

  1. cargo test -- --test-threads=1
  2. powershell -File .\src\tests\dev-check.ps1
  3. powershell -File .\src\tests\windows-test.ps1 -StartDaemon -SeedReminder

The first command runs the lifecycle smoke test in tests/lifecycle_smoke.rs, which verifies daemon start and clean stop behavior.

Daemon Diagnostics

Use the CLI companion to inspect the active daemon:

.\target\release\fcr-reminder-cli.exe --health
.\target\release\fcr-reminder-cli.exe --storage
.\target\release\fcr-reminder-cli.exe --events
.\target\release\fcr-reminder-cli.exe --next
.\target\release\fcr-reminder-cli.exe --doctor

Best Runtime Verification Command

--doctor is the strongest single command for confirming the live instance because it returns the PID, executable path, storage paths, and registration checks.

End-to-End Reminder Seeding

For an end-to-end sync and notification check, use the scripted Windows harness:

powershell -File .\src\tests\windows-test.ps1 -StartDaemon -SeedReminder

That script can:

  • start a daemon if needed
  • push a synthetic sync payload to /sync
  • inspect health, storage, events, and next reminder data
  • optionally seed a reminder a few seconds into the future for scheduler validation

Cleanup

Cleanup should be run through the CLI companion in a terminal:

.\target\release\fcr-reminder-cli.exe --cleanup

Do Not Delete State Manually

The supported cleanup path stops the daemon first, waits for shutdown, and only then removes registry entries and local app data. Manual deletion can leave registration and process state out of sync.

Compact index: User Docs · Daily Operation · Commands and Diagnostics · Cleanup and Registration