v0.5.5

Unofficial community build. Not affiliated with Modular or Qualcomm.

A patch release, and the first one since v0.5.0 where the packaged runtime is actually a different program. A Mojo process that runs out of stack on Windows now says so instead of dying in silence, which closes the oldest open complaint on the manual acceptance checklist.

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

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

What changed

A stack overflow prints a line and exits with the right code. Windows delivers EXCEPTION_STACK_OVERFLOW to a thread that has almost no stack left, so the unhandled exception filter LLVM installs never gets far enough to run and nothing was printed at all. A vectored handler runs earlier and on the same stack, and SetThreadStackGuarantee reserves enough of that stack for one line of text, so the handler has somewhere to stand. The program now prints the thread it happened on and the usual cause, and exits with 0xC00000FD. That is #239. The related report that deep recursion arrived as an access violation rather than as a stack overflow no longer reproduces either, so #238 is closed with it. Ordinary faults are unchanged and still print the symbolised frame list they always did.

test_external_call builds and runs on Windows. It called fcntl directly to check that a variadic argument survives being forwarded through an argument pack, and there is no fcntl on Windows, so the whole target failed to build and four tests in it never ran anywhere near Windows. The forwarding check now goes through snprintf, which every platform has, and the fcntl test keeps its own coverage on the platforms that have it. That is #210.

//bazel/internal:uv has a Windows arm. It had three and picked between them with a select, which resolves in the configuration of whatever asked for it, so adding a fourth arm on its own would have handed a Linux build machine a uv.exe on a cross build. The select now sits behind a small rule that takes its dependency in an exec configuration, so the answer is about the machine running the build rather than the machine being built for, and the one consumer that takes the tool as data gets that for free. That is #117.

Test results

Every suite is exactly where it was in v0.5.4, and the four tests #210 unblocked are inside those counts rather than added to them.

Windows tier 0 is 232 of 238, with 232 passing, one target that does not build and five skipped. Windows tier 1 is 75 of 78, with 75 passing and three skipped. The Win64 ABI conformance suite is 13 of 13 passing. Linux tier 0 is 236 of 238, with 236 passing and two that do not build. Linux tier 1 is 76 of 78, with 76 passing and two skipped. The target that does not build on either platform is #230, an AMDGPU codegen test that has nothing to do with Windows.

Manual acceptance

Run against this archive, unpacked, on a machine with the archive and nothing else from the build tree. The full record is in docs/acceptance.md.

Item 6 is the one worth reading. It has been a partial failure since v0.4.2 and it passes now: an ordinary fault gives the five frame symbolised trace, and a stack overflow gives the new line and 0xC00000FD. Items 3, 4, 7 and 8 pass as before, covering non ASCII paths, paths with spaces, the import table and a Defender scan that left all twelve files alone. Item 1 is still not applicable because there is no mojo.exe to start a REPL with. Items 2 and 5 still need a person at a real console, one to judge how the colours read and one to press Ctrl-C.

What still does not work

There is still no Mojo compiler for Windows. Everything here is cross compiled from Linux, and the archive contains a runtime and one example program rather than a toolchain.

Shared objects built for Windows export no symbols and cannot reach the C runtime, which is #134, and there is no COFF JIT, so there is no REPL and no mojo run, which is #31. The prebuilt MAX wheel has no Windows build, so a large block of aliases has nothing to resolve to, which is #115.

Files

The overlay archives are built by CI from the tag and carry a provenance attestation. The Windows archives are cross compiled from Linux by hand and carry checksums only, because CI cannot build them and attesting them there would sign a claim that is false. docs/releasing.md explains that at more length.

Verify what you downloaded before using it:

sha256sum -c SHA256SUMS
sha256sum -c SHA256SUMS-windows
gh attestation verify <file> --repo tamnd/mojo.windows

The Windows binaries are unsigned, so Windows will warn about them the first time you run one from Explorer. That is expected. docs/downloading.md says what the warning looks like, what decides whether you see it at all, and how to get past it.