Shipping a Rust Synchronizer Node on Windows x86_64
The Windows source and PowerShell test suite for the Forerunner synchronizer node, covering native builds, cross-compilation, and the real friction of shipping an unsigned binary.
This is the Windows side of the Forerunner synchronizer node: source, build instructions, and a test suite, all targeting Windows x86_64. It is the least glamorous part of a distributed system and often the part that decides whether real people can actually run your software.
Two Ways to Build
The repo supports two build paths, and keeping both working is deliberate. The native path uses stable Rust (1.80 or newer) with the Visual Studio Build Tools, which is what a Windows developer expects. The second path is cross-compilation from macOS or Linux, so I can produce a Windows binary without sitting in front of a Windows machine.
That second path is the one that saves time day to day. Most of my development happens away from Windows, and being able to cross-compile means the Windows target does not fall behind the others between releases. There is a pre-built binary published for people who do not want to build anything, verified against a published SHA256SUMS file so a download can be checked for integrity before it runs.
The Unfun Part Is the Real Part
The Windows notes in the README are short, but they describe the two things that actually trip users up. SmartScreen flags the unsigned binary, so the instructions walk through the "More info" then "Run anyway" path. The firewall prompts on first launch, because the node needs network access on port 7080, and the fix is simply to allow it.
Neither of these is a code problem. They are the operating system doing its job, and the honest thing to do is document them plainly rather than pretend a fresh Windows install will run an unsigned network binary without friction. A user who hits an unexplained SmartScreen wall usually just gives up. A user who was told it would happen clicks through and keeps going.
Testing on the Target Platform
The test suite lives in tests/ and runs under PowerShell, which matters more than it sounds. A synchronizer node's behavior depends on the platform it runs on, so running the tests in PowerShell on the actual Windows target catches things a cross-platform test on Linux would miss. Testing where the code will actually live is worth the extra setup.
The takeaway is unglamorous but real: the Windows target is not finished when it compiles. It is finished when someone who has never seen your project can download the binary, verify it, get past the OS security prompts, and pass the tests. Writing those steps down is part of shipping, not an afterthought to it.
Have something that needs building, or stabilizing?
These notes are the work log. The paid work runs through Moonshine Labs, my product and engineering studio. Tell us what you're building, or grab a call.
Work with us →