v0.5.1

Unofficial community build. Not affiliated with Modular or Qualcomm.

A patch release. Nothing about the packaged runtime changed, the binaries here are the same programs built from the same pin as v0.5.0. What changed is the build tooling, which no longer assumes the machine running it is a Unix one. That is groundwork for M6, native hosting, where the build has to run on Windows rather than only produce things for it.

Pinned to upstream modular/v25.7.0-29742-g9aba62be84, commit 9aba62be844d73b574a4283a1a8ce760f9843134.

Download mojo-windows-runtime-0.5.1-x86_64.zip, unpack it, run bin\hello.exe. Nothing to install first. Windows 10 version 1809 or later, x64.

What changed

The three toolchain driver scripts the C++ toolchain shells out to were bash and are now Python. They run inside the build, where python3 is already something the host has to provide, so one implementation covers Linux, macOS and Windows instead of three. That is #33.

Bazel can now be started on Windows. bazelw and tools/bazel are shell scripts and there was no way to run either of them from a Windows shell, so the first thing anybody trying to build on Windows hit was that there was nothing to type. There are now PowerShell counterparts for both, plus the local resource detection they call, each behind a small .bat because a .bat is what cmd.exe and bazelisk can actually start. That is #32, and docs/building.md has a section on why the arrangement is shaped the way it is.

Two things about that were established by measurement rather than by reading documentation, and both are worth knowing if you touch this. Bazelisk looks for tools/bazel.ps1 before tools/bazel.bat and then hands the path it found to CreateProcess, which cannot start a PowerShell script at all, so shipping a tools/bazel.ps1 would break the build rather than help it. And powershell -File wrapper.ps1 %* silently drops quoting on an argument like --test_filter="Foo Bar", which is exactly the spelling PowerShell itself produces when it passes a spaced argument to a native program, so the arguments go across in an environment variable and get split with CommandLineToArgvW instead.

Test results

Every suite is unchanged from v0.5.0, which is the point of a patch release.

Windows tier 0 is 232 passing, one target that does not build and five skipped. Windows tier 1 is 75 passing and three skipped. The Win64 ABI conformance suite is thirteen of thirteen. Linux tier 0 is 236 passing with two that do not build, Linux tier 1 is 76 passing and two skipped. The Windows build failure is #230, an AMDGPU codegen test rather than anything Windows specific.

The manual acceptance checklist was run again against this archive and the result of every item is in docs/acceptance.md. Four items pass, one is not applicable without a compiler on Windows, one was not re-run because nothing it covers changed, and two still need a person sitting at a console.

What still does not work

There is still no mojo.exe. The wrappers above mean you can start Bazel on Windows, not that a build finishes there. The next thing in the way is #243: the pinned Bazel version has no Windows asset published, so bazelisk cannot fetch it, and all the wrapper verification for this release was done against a stock Bazel 8.8.0.

A stack overflow still prints nothing, which is #239, and it still arrives as an access violation rather than as STATUS_STACK_OVERFLOW, which is #238. Every other fault prints a proper symbolised trace.

The Windows archives have no provenance attestation. The overlay archives do, because CI builds those, and CI cannot build the binaries. Attesting locally built files in a workflow would produce a signature that verifies and a claim that is false, so what the Windows archives get instead is checksums, the pin inside the archive, and this paragraph.

The binaries are unsigned. docs/downloading.md explains what SmartScreen does about that and why it depends on how you started the file. Nothing has been tested on a Windows machine other than the one that built it, and nothing older than Windows 11 has been tested at all.

Verify what you downloaded

sha256sum -c SHA256SUMS
sha256sum -c SHA256SUMS-windows
gh attestation verify mojo-windows-overlay-0.5.1.tar.gz --repo tamnd/mojo.windows

What's Changed

• Rewrite the toolchain driver scripts in Python by @tamnd in #242
• Add PowerShell wrappers so bazel can start on Windows by @tamnd in #244
• Record the v0.5.1 acceptance run by @tamnd in #245

Full Changelog: v0.5.0...v0.5.1