v0.5.6

Unofficial community build. Not affiliated with Modular or Qualcomm.

A patch release. A Mojo program on Windows no longer ends without a word when something hands it a descriptor it does not own, which was the last of the silent failures on the list. Away from the packaged runtime, a shared library built for Windows now exports its symbols and links when it touches floating point, which closes the oldest p1 in the milestone.

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

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

What changed

A bad file descriptor gets an answer instead of ending the process. The Windows CRT treats a call on a descriptor it does not recognise as a programming error and invokes the invalid parameter handler, whose default behaviour is to end the process there and then. No exception, no message, no exit code anybody can read. So close(4) on a descriptor that was never open took a Mojo program down in silence, and so did anything else that went near one. The startup wrapper now installs a handler that returns instead, once and for the whole process, before anything else runs. The call then fails the way the C standard says it should, with EBADF, and the program carries on. That is #197.

print no longer flushes a stream that never held anything. It opened a FILE over a duplicate of the descriptor and called fflush on it, which starts with an empty buffer and has no connection to anything written before. print does not buffer in user space, so there was nothing to flush. That is #214.

A shared library built for a Windows target exports what it should. COFF publishes nothing unless the object asks, so a Mojo shared library on Windows linked, loaded, and had an empty export table. Every definition that is still externally visible after the call graph slicing is now marked for export, which is the same set ELF and Mach-O put in a dynamic symbol table.

A shared library that touches floating point links at all. Any object with a floating point signature references _fltused, which the asm printer emits on its own with no way to turn it off and which the C runtime would normally define. There is no C runtime on a /DLL /NOENTRY link, so the link failed on a symbol that means nothing and that nothing reads. The link line now maps the name onto a symbol the linker always defines, and that mapping goes inert the moment a real C runtime is present. Those two together are #134.

None of the shared library work is in the archive below, because the archive is a runtime and an example rather than a toolchain. It matters for what comes next rather than for what you can download today.

Test results

Every suite is exactly where it was in v0.5.5.

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.

The kgen and mojo-tool lit suites are 217 of 217 and 101 of 101, which is where the shared library work is actually checked.

Earlier notes gave the tier 1 totals as 79. The number Bazel reports is 78 and always was, so the counts above are what to diff against.

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 was re-run rather than carried over, because #197 changed the startup code and item 6 is the item that covers what happens when a program goes wrong. Both kinds still behave: an access violation prints Exception Code: 0xC0000005 and a frame list, and a program that recurses until the stack runs out prints the thread it happened on and exits with 0xC00000FD. Items 3, 4, 7 and 8 pass as before, covering non ASCII paths, paths with spaces, an import table of KGENCompilerRTShared.dll and KERNEL32.dll and nothing else, and a Defender scan that left all twelve files in both unpacked copies 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.

A shared library built for Windows exports its symbols now, and it still cannot reach anything outside itself. There is no library search path and no import library on the link line, so a module that calls memcpy or reaches back into the Mojo runtime fails to link. That is #280, and it is what is left of #134. 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.