v0.5.10

Unofficial community build. Not affiliated with Modular or Qualcomm.

The release where there is a mojo.exe. Not in this archive, and not one you can use for anything yet, but the compiler now compiles for a Windows target with zero failing compile actions, links with zero undefined symbols, and the binary that comes out runs on the machine that built it. Nine changes land here, six of them are the road to that, and the last of them moves the pin 145 commits.

Pinned to upstream modular/v25.7.0-29887-g2b47eeef01, commit 2b47eeef01fd2d85269184ced847dc75d2c5040a.

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

The compiler builds

#300 opened with 44 files failing to compile the moment the compiler sources were pointed at a Windows target for the first time. Five changes took that to zero, and they are worth reading in order because each one was hiding the next.

#301 is the one that accounts for 35 of the 44 and has nothing to do with the compiler. curl's BUILD file lists its own source directory in includes, and includes propagates, so every target that reaches curl anywhere in its graph was compiling with -isystem external/curl+/lib on the command line. That is harmless until the header names start colliding, and the CRT and the Windows SDK between them own a few thousand short generic names. share.h is one. Microsoft's <xiosbase> says #include <share.h> and means the CRT's, got curl's, and curl's pulls in curl_setup.h and so winsock2.h and so the whole of windows.h. The visible symptom was that including <sstream> defined IGNORE in every translation unit in the compiler, and 35 files then failed to parse an enumerator by that name. The directory is a -iquote copt now, which reaches curl and nothing else.

#303 and #304 are the ordinary porting work underneath. Four places passed a std::filesystem::path where a std::string was wanted and let the implicit conversion do it, which only exists where path::value_type is char, and on Windows it is wchar_t. Two files were getting <string> and <deque> handed to them by some other header, which libstdc++ and libc++ both do and Microsoft's STL does not. And three files included headers Windows has never had. <dlfcn.h> was unused and simply went. <unistd.h> in the interpreter's write folder became <io.h> and _write. The signal handler is the real one and it now keeps the LLVM half, which is the stack trace and the host machine info, and loses the detail block that names the signal and the faulting address, because producing that on Windows means a vectored exception handler and that is separate work.

#305 is the last four, and both of them are a constant rather than an API. kExprDestOperandIdx is ~1ULL in an enum with no fixed underlying type, and the implementation picks the type: the Itanium ABI picks an unsigned one, the Microsoft ABI picks int, which cannot hold it. Clang warns, carries on with -2, and the first braced initializer for a size_t turns that into an error. The enum says enum : size_t now. The other is four InsertValueOp::create calls with a position of zero, where create is overloaded on ArrayRef<int64_t> and on DenseI64ArrayAttr and mlir::Attribute has an implicit constructor from a pointer. Under -fms-compatibility clang keeps the pre C++11 rule that any constant expression evaluating to zero is a null pointer constant, so the attribute overload became viable and neither candidate won. Only the zeroes failed, which is why a position of one sitting on the next line compiled fine.

#307 is the link. Init and AsyncRT:Runtime are both plain static libraries and both declared functions with MODULAR_CXX_EXPORT, which is dllexport when MODULAR_BUILDING_LIBRARY is defined and dllimport when it is not. The only thing that defines it is modular_shared_library, and neither of these is one, so every caller was being sent to an import table entry that no import library has, while lld-link pointed out that the definition was in an object file it already had. This is the same mistake Support:Context made in v0.5.9 and it gets the same answer, MODULAR_CXX_STATIC_VISIBLE, which is default visibility on ELF and Mach-O and nothing at all on Windows, because there is no DLL boundary here for either word to be about. On Linux and macOS this changes nothing.

With that in, //Mojo/tools/mojo builds natively on Windows: 0 failing compile actions, 0 undefined symbols, bazel-bin/Mojo/tools/mojo/mojo.exe produced and it starts. What it cannot do yet is the point of the next section.

Three other things

#297 finishes off #207, which asked how widespread the #201 problem is rather than assuming. A value whose last use is an argument of a raising call is destroyed on the way out of that call, and naming it in the except block does not count as a use, so the handler reads a slot something else now owns. Linux usually gets the right answer by luck because the old bytes are still there, and the Windows allocator scrubs them. scripts/find-dead-handler-values.py counts it: 2003 Mojo files, 23 sites in 17 files, and reading all 23 leaves two real ones. io/file.mojo puts a destroyed directory name into an error message. tempfile/tempfile.mojo uses a destroyed path to clean up after a failed write, so on Windows the cleanup looks at a scrubbed path, finds nothing, and leaves the temporary file behind. Both are fixed. Two sites is not enough to justify carrying a compiler change in the overlay, and the compiler change is not ours to make, so what this leaves behind is the script and a number that can be re-run against a new pin.

#298 closes #230 the long way round. Two GPU codegen tests fail to build on every platform, and the issue framed it as a choice: either the released mojo from the wheel builds them, in which case our LLVM configuration is wrong and this is a build setting, or it does not, in which case they belong behind a constraint. The released one does build them, so the first branch looked right. Adding AMDGPU and NVPTX to the LLVM configuration is a one line change through an extra_targets hook nothing was using, and it was made, and 2721 actions ran over 22 minutes, and the error did not move by a byte. It does not move because the triple is not served by an LLVM backend, it is served by a Mojo TargetBackend, and HostBackend is the only one in this tree. amdgcn-amd-amdhsa appears in no C++ source here at all. Both tests take a constraint now, each with a comment saying why the obvious fix does not work, so nobody spends the same 22 minutes.

#299 closes #115. All thirteen @modular_wheel aliases are selects over the three platforms Modular publishes the MAX wheel for, Windows is not one, and nothing was checking that the default arm which makes that survivable is still there. The failure mode is why it matters: a select with no matching arm fails in whatever reaches it rather than in the file that lost the arm, and one standard library test importing DeviceContext takes its whole package's lit aggregate down, which is where most of the old analysis allowlist came from. The check names the aliases directly now. The audit came out clean, all thirteen analyze for Windows, and the compiler does not reach the wheel at all.

The pin

#308 is the first pin move since M5, 145 commits, and it closed #302. Two of the 225 overlay files needed a real merge. The one that conflicted was our rules_mypy patch meeting upstream's own version of the same fix, and theirs turned out to be ours plus a second bug we did not have, so ours was dropped and theirs taken. The other was a test added to a lit list and it merged without comment. The bump also turned up that the lock had been recording the string main as its tag, because branch mode used the branch name where tag and commit modes both use git describe, and that tag is exactly what release notes and issues quote. Branch mode describes now, which is why the tag above reads the way it does.

What is different in the archive

The four binaries all changed, and this time one of them changed in a way you can see from outside.

KGENCompilerRTShared.lib no longer exports AsyncRT::getOrCreateCPUDevice. That is #307 arriving: the function lives in a static library, it was marked for export anyway, and so it was being published out of a DLL that had no business publishing it. MSupportGlobals.lib and AsyncRTRuntimeGlobals.lib are byte for byte what they were in v0.5.9, so nothing else about what these DLLs offer has moved, and the rest of the difference in the binaries is 145 commits of upstream plus whatever the relink stamped into them.

example/hello.mojo, LICENSE and NOTICE are unchanged. README.txt differs only in the version number. upstream.lock names the new pin.

Test results

Linux tier 0 is 237 pass and 2 skipped of 239. Linux tier 1 is 76 pass and 2 skipped of 78, with the usual nonzero exit because //Mojo/stdlib/test/os:test_trap_gpu.mojo fails to build for a target this machine does not have. Windows tier 0 is 233 pass and 6 skipped of 239. Windows tier 1 is 75 pass and 3 skipped of 78. Windows ABI conformance is 13 of 13.

Both tier 0 totals are one higher than v0.5.9 because the pin move brought in a new compile-fail test and the merge put it in the list. Everything else is exactly what it was before the bump, which was the point of running all five suites twice.

The kgen and mojo-tool lit suites were not re-run. They were 321 of 321 in v0.5.8 and that number is now two pin moves old, so treat it as a reason to expect a result rather than as a result.

Manual acceptance

This exact archive was unpacked on a Windows machine into a clean directory and bin\hello.exe run from where it landed, printing Hello from Mojo and built for Windows: True and exiting zero.

Th...

v0.5.9

Unofficial community build. Not affiliated with Modular or Qualcomm.

The release where the native Windows build of //Support/... stops being a list of problems and becomes one problem. Two changes land, they close #272 and #292, and the top level count goes from 480 of 503 to 504 of 505. The one that is left is a Nanobind extension, which Linux does not build either. There is still no Mojo compiler for Windows and nothing in this release produces one, but the support library that a compiler would be built on now compiles and links on the machine that would build it.

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

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

What changed

#293 is the source half of #272, which the last three releases kept approaching from the build configuration side and kept finding another layer under. Eleven of them were about the C library. Nine tests and two benchmarks call setenv, which is POSIX rather than C, and the MSVC runtime implements C. It has _putenv_s instead, same idea and a different signature. The choice was an #ifdef at every call site or one small header that supplies the POSIX spelling in terms of what the platform has, and the header won, because the call sites are otherwise identical and there are a lot of them.

The rest of #293 is smaller and the same shape. Six log tests built a temporary file path by writing /tmp into a string, and now ask LLVM where the temporary directory is. Two benchmarks wrote to /dev/null, which on Windows is spelled NUL and is not in the filesystem. One test expected testing::KilledBySignal, which a Windows gtest does not have because Windows has no signals to be killed by, so it matches on the exit code the C runtime produces instead. Two files passed a std::filesystem::path where a narrow string was wanted, which works everywhere that a path's native character type is char. And six #error "Test requires modification for Windows" markers, left by somebody who meant them, are gone.

#295 is the link half, and both failures in it are the same mistake: a symbol told to travel through a DLL when it was never going to.

Seven targets got mlir::detail::FallbackTypeIDResolver::registerImplicitTypeID twice, once from MLIR's own object file and once from the MSupportGlobals import library. The build forces that function into the shared library and exports it, which on Linux and macOS is not about having a copy there. It is about every other loaded module giving up its own copy and using that one, and it works because ELF and Mach-O resolve a global symbol to a single definition across the whole process. Windows has no such rule. A module reaches a symbol in a DLL only if it was compiled to look for it there, and the MLIR header declares this function plainly, so nothing ever is. Both flags that spell the trick on Windows worked exactly as documented and produced a DLL exporting a function that no caller could be pointed at, plus a duplicate symbol in every executable linking both MLIR and that DLL.

The eighth was M::Context::~Context, wanted as an import and found sitting in an object file. The header marked it for export and the target carried the define to match, but that target is a static library, so there was no DLL for the marking to be about, and every consumer that links the object directly was being sent to look elsewhere. Deleting the marking outright was not an option, because the build compiles with -fvisibility=hidden and that would have changed what Linux exports. So there is a new macro for the static library case which says default visibility on ELF and Mach-O and says nothing at all on Windows.

What the second one costs

Emptying that select is not free. MLIR type identity no longer survives a module boundary on Windows: each module keeps its own registry, and a type registered in one is not the same type in another. That is a real gap, it is written up as #294 with three cheaper workarounds listed, and the actual fix is on the other side of it, which is one shared MLIR rather than a static MLIR in every module and a trick to make the copies agree.

Nothing shipped here depends on that, and eight link failures traded for a gap that is written down is the right way round. But it is a gap and not a fix.

What is different in the archive

Unlike the last two releases, the runtime is not byte for byte what it was. MSupportGlobals.dll and its import library changed, and that is the #295 change arriving: the exported registerImplicitTypeID is in the v0.5.8 DLL and is not in this one, which was checked rather than assumed.

hello.exe, AsyncRTRuntimeGlobals.dll and KGENCompilerRTShared.dll also differ, and there the honest answer is that no interface of theirs changed, because their import libraries are byte for byte identical to v0.5.8. What moved is almost certainly the embedded debug signature, which changes whenever something they are built on top of is relinked. example/hello.mojo, upstream.lock, LICENSE and NOTICE are unchanged, and README.txt differs only in the version number.

Test results

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

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. Linux //Support/... is 324 of 326, with one target that does not build and one that fails, both of them Nanobind and both of them failing on the previous release too.

The target that does not build on either platform is #230, an AMDGPU codegen test with nothing to do with Windows. The second Linux one is an nvptx64 test that only Linux gets far enough to attempt.

The kgen and mojo-tool lit suites were not re-run for this release. They were 321 of 321 in v0.5.8 and nothing here touches them, but that is a reason to expect a number rather than a number.

Manual acceptance

The smoke test was done properly: this exact archive was unpacked on a Windows machine into a clean directory and bin\hello.exe run from where it landed, printing Hello from Mojo and built for Windows: True and exiting zero.

The rest of the v0.5.6 record stands and is in docs/acceptance.md. Items 3, 4, 6, 7 and 8 passed there, covering non ASCII paths, paths with spaces, crash output for an access violation and a stack overflow, an import table with nothing unexpected in it, and a Defender scan that left everything alone. Those were checked against a runtime that has since been relinked, which is worth knowing when reading them. 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, and nobody has done either yet.

What still does not work

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

There is no COFF JIT, so 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. MLIR type identity does not cross a module boundary on Windows, which is #294 and is new in this release. And the native build, now that it gets through //Support, has the rest of the tree in front of it.

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.

v0.5.8

Unofficial community build. Not affiliated with Modular or Qualcomm.

A patch release about a machine that has never been able to build this project: a Windows one. Four changes land, three of them are the same story told three times, and between them a native Windows build of //Support/... goes from 378 of 503 top-level targets to 480. That is not a working compiler yet and nothing in the archive below changed, but it is the first release where the native build stops being a wall and starts being a list.

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

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

What changed

#272 says the support tests and benchmarks do not compile when the machine driving the build is Windows. Work on it started at the cheapest looking end, the link flags, and each target behind those flags turned out to have a second thing wrong underneath it. So three releases worth of finding out, in one release.

#287 is protobuf. Its link options have an arm for Windows carrying -ldbghelp, -lpthread and -lm, written for MinGW where all three name real libraries. Against an MSVC target the last two become pthread.lib and m.lib, and neither exists, because the C runtime already provides both. Twenty four missing library errors went to none and the top level count did not move at all, which is how the next two got found.

#290 is abseil. It marks its per thread semaphore functions with a weak attribute, which it turns on for Windows whenever clang is new enough, and that is right for compiling and wrong for linking. Bazel puts a library's object files inside a start-lib group, which makes each one lazy, and lld-link will not pull in a lazy object to satisfy a reference that is only weak. So the definitions sat on the link line unread while mutex.obj went looking for them. Turning the attribute off on Windows is what abseil already does for MinGW. Twelve undefined symbols went to none and the count moved to 388.

#291 is the interesting one. Three DLL links failed with nothing but The command line is too long., which is not the linker talking, it is cmd.exe declining to start linker-driver.bat with about forty thousand characters after it. Bazel can write those arguments into a file and pass @file instead, and this toolchain has asked it to since the Windows host work started, but rules_cc decides the shared library case by asking whether a feature called targets_windows is on, and this toolchain does not turn that on. The comment above the check says the restriction is a Unix one and probably unintended, and what it is really protecting is a shell script that reads its arguments positionally and that we never run. So the check now asks about the tool rather than about the platform. That one change moves the count from 388 to 480, because the DLL it was blocking is what most of //Support is built on.

#286 is unrelated and much smaller. Python 3.10 on Windows cannot work out where its own standard library is unless something tells it, so an embedded interpreter now gets a PYTHONHOME pointing at the install it was found in. Every version after 3.10 works this out for itself.

Being straight about the number

480 of 503 is up ninety two, and the error count went up too, from 21 lines to 25. That is not a contradiction, it is what happens when a blockage clears: ninety two targets that had never been attempted got attempted, and some of them failed.

Eleven of the 25 are the source level failures #272 was always about, setenv and unsetenv and mkstemp with no MSVC C runtime equivalent, testing::KilledBySignal missing from a Windows gtest, and an explicit #error "Test requires modification for Windows" that somebody left in years ago and meant. Six are a duplicate mlir::detail::FallbackTypeIDResolver::registerImplicitTypeID, which is a known MLIR problem on Windows. Two are an undefined M::Context::~Context marked dllimport, which is new and has not been looked at yet. The rest are Nanobind and mypy failures downstream of the ones above.

Test results

Every cross compiled suite is exactly where it was in v0.5.7, and for #291 that is provable rather than observed: the check it patches returns early unless the toolchain says it supports parameter files, which this one only says on a Windows host.

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 321 of 321, unchanged from v0.5.7.

Manual acceptance

Not re-run in full, for the same reason as last time and checked the same way. Every file inside this archive has the same CRC as the file of the same name inside the v0.5.7 archive: all three DLLs, all three import libraries, hello.exe, hello.mojo, upstream.lock, LICENSE and NOTICE. The only entry that differs is README.txt, which has the version number in it. That is what you would expect from four changes to how the build works on a Windows host and one to how an embedded interpreter finds its standard library, none of which are in a cross compiled runtime.

The smoke test was done: this archive was unpacked on a Windows machine and bin\hello.exe run from where it landed, printing Hello from Mojo and built for Windows: True and exiting zero.

The rest of the v0.5.6 record stands and is in docs/acceptance.md. Items 3, 4, 6, 7 and 8 passed there, covering non ASCII paths, paths with spaces, crash output for an access violation and a stack overflow, an import table with nothing unexpected in it, and a Defender scan that left everything 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, and nobody has done either yet.

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. The native build is closer than it was this morning and still does not produce one.

There is no COFF JIT, so 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. And #272 is still open, now down to the parts that need actual source changes rather than build configuration.

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.

v0.5.7

Unofficial community build. Not affiliated with Modular or Qualcomm.

A patch release, and it closes the oldest open item left over from #134. A shared library built for Windows can now reach outside itself: the link line knows about library search paths and import libraries, so a module that calls into the C runtime or back into the Mojo runtime links instead of failing on symbols it was never going to be able to resolve on its own.

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

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

What changed

All of it is #280, in three parts.

The link that turns an object into a Windows shared library now takes arguments from configuration. mojo-max.shared_object_libs is a comma separated list that goes on the lld-link line untouched, which is where an install puts the /libpath: for its C runtime and the /defaultlib: for the libraries in it. ELF and Mach-O do not need this, because either format is happy to leave a symbol undefined and let the loader find it at load time. COFF is not: a DLL has to resolve everything it references at link time, and it reaches the C runtime through an import library or not at all. Nothing in the compiler knows where an install put one, so somebody has to say, and until now there was no way to.

The Mojo runtime's own import library is the exception, because the compiler can find that one itself. It sits in the install as lib/KGENCompilerRTShared.lib, right next to the DLL it describes, and the compiler already knows where the rest of its files are. It goes on the line automatically when the target is COFF and the file is really there, and the second half of that matters more than it looks: most of these builds are a Linux host cross compiling for Windows, and naming a file that does not exist would turn every link that never wanted a runtime into an error about a missing library.

Then a test that proves the whole thing rather than proving an argument arrived. It links a module that calls puts and does not define it, and checks the symbol comes out of the result as an import from api-ms-win-crt-stdio-l1-1-0.dll. That is a link that failed before this release and succeeds now. It needs a real Windows CRT and SDK on the machine, which cannot be redistributed, so it is gated on a new windows-sysroot lit feature and is reported as unsupported anywhere MOJO_WINDOWS_SYSROOT does not point at a real one. docs/building.md has the command that runs it.

Worth being clear that this is the kgen -emit=shared-lib path only. mojo build --emit shared-lib goes through the linker driver and gets its libraries from there, so it was never affected.

None of this is in the archive below. The archive is a runtime and an example rather than a toolchain, and nothing that goes into it changed in this release. It matters for what comes next.

Test results

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

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 lit suite is 220 of 220 and mojo-tool is 101 of 101. kgen was 217 in v0.5.6 and the three new tests are the three parts above. The last of them was also run with a sysroot present, to check it passes rather than only that it is skipped, and run with a sysroot path that does not exist, to check it is skipped rather than failing.

Manual acceptance

Not re-run, and that is a deliberate call rather than an omission. Nothing that goes into the archive changed between v0.5.6 and this tag: the three pull requests touch the compiler's object emission, its configuration, the lit harness and the docs, and none of them touch the runtime, the example or the packaging.

That is checked rather than asserted. Every file inside this archive has the same CRC as the file of the same name inside the v0.5.6 archive, all three DLLs, all three import libraries, hello.exe, hello.mojo, upstream.lock, LICENSE and NOTICE. The only entry that differs is README.txt, which has the version number in it. The zips themselves have different checksums because a zip records when it was made.

What was done is the smoke test: this archive was unpacked on a Windows machine and bin\hello.exe was run from where it landed, which prints and exits zero. That is the check that catches a packaging mistake, and a packaging mistake is the only kind of thing that could have gone wrong between the two tags.

The rest of the v0.5.6 record stands, and it is in docs/acceptance.md. Items 3, 4, 6, 7 and 8 passed there, covering non ASCII paths, paths with spaces, crash output for both an access violation and a stack overflow, an import table of KGENCompilerRTShared.dll and KERNEL32.dll and nothing else, and a Defender scan that left everything 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, and nobody has done either yet.

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 can link against the C runtime now, and an install still has to be told where its C runtime is, because the compiler has no way to find one. 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. The support tests and benchmarks do not compile when the machine driving the build is Windows, which is #272 and is the largest thing left in this milestone.

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.

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.

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.

v0.5.4

Unofficial community build. Not affiliated with Modular or Qualcomm.

Verify what you downloaded before using it:

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

The overlay archives are built by CI and carry a provenance attestation. The Windows archives, if this release has any, do not. CI cannot build them: that needs a Windows sysroot and hours of Bazel, so they are cross compiled on a known machine and uploaded by hand, and the checksums are what there is to check them against. docs/releasing.md says how they were made.

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.

Releases are drafted rather than published automatically. Fill in what works and what does not before you publish, because that list is the most useful part of the notes.

What's Changed

• Put the arguments in a file on a Windows host by @tamnd in #268
• Point the llvm-project links at a name Bazel does not rewrite by @tamnd in #269
• Close the include search on a Windows host by @tamnd in #271

Full Changelog: v0.5.3...v0.5.4

v0.5.3

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 that a Windows host now gets past analysis and runs a real compile action, with clang actually executing on Windows. That is not a compiler yet, but it is the difference between a machine that can plan the build and a machine that has started doing it. M6 work, native hosting.

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

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

What changed

All five changes here came out of the same exercise, which was to sit at a Windows machine, ask Bazel for a real target, and fix whatever it hit. Each one was invisible until the one before it was fixed.

The pip lock file now has a Windows environment. The rc turns on the mypy aspect for every build, so every target in the tree depends on mypy resolving, and the lock file declared darwin and linux and nothing else. Analysis stopped on a Windows host before it had looked at a single source file. That is #252.

The TestRunner strategy chain no longer names a strategy that does not exist on Windows. It named sandboxed, and there is no sandbox on Windows, and Bazel validates every name in a chain up front rather than quietly skipping the ones that are not registered. So the invocation failed after analysis had already succeeded, which is a confusing place to be told about a test strategy when you asked for a build. That is #256.

The crosstool module map is built without a shell. builtin_module_map was shelling out to find, once per include directory, to list the files under it. There is no shell on Windows for Bazel to run that in, and on a machine with WSL installed it finds bash.exe in System32 and runs the script inside the Linux distribution, where none of the Windows execroot paths exist. The list find was producing is one Bazel already had, since the same depset was being handed to the action as its inputs, so the rule builds the file in Starlark now and there is no action left to fail. Checked byte for byte against the old output on Linux, 3076 lines either way. That is #259.

Path mapping is set per host instead of unconditionally. --experimental_output_paths=strip stops a configuration transition from rebuilding C++ that did not change, and Bazel only implements it for a spawn that runs sandboxed or remotely. With no sandbox on Windows, every C++ compile in the tree refused to run and blamed the strategy flags for being too strict, which was not the problem: the two strategies a Windows host has are the only two it can have and neither can do path mapping, so the requirement could never be met. It is now on the linux and macos arms. The cost is that a Windows host rebuilds C++ across a configuration change that would have been free on the other two, which is the right trade while the alternative is not building. That is #260.

The three cc toolchain drivers can be started. They are Python scripts, Windows has no shebang, and CreateProcess refuses a .py whatever the file association says, so the first compile action failed to launch with error 193 before anything had been compiled. Each driver now gets a small .bat generated beside it on a Windows host, which Bazel does know how to start through cmd.exe, and the interpreter is written into it as an absolute path found by a new repository rule. It has to be absolute: the rc sets --incompatible_strict_action_env, which on Windows gives an action a PATH of system32, windows, wbem and powershell, and no Python installer puts anything in any of them. That is #253.

One more, found while cutting this release rather than while building. package-windows.sh walked the Bazel output tree for the import library beside each DLL, and the rc only materialises the outputs the requested target names, so it was reading files left over from an earlier build rather than files this build produced. On a machine where they were not lying around it stopped, correctly, with an error. Debug information was the same shape with a worse ending: a missing .pdb was treated as debug information not being wanted, so the -pdb.zip was quietly not made. Both are errors now and this build downloads what it reads. That is #266.

Test results

Every suite is unchanged, 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 14 of 14. Linux tier 0 is 236 passing with two that do not build, Linux tier 1 is 76 passing and two skipped. The build failures are #230, an AMDGPU codegen test, and an overflow test, neither of them Windows specific. Two Windows tier 0 tests failed on the first run with cp: ... Cannot allocate memory while staging to /mnt/c, which is the WSL to Windows filesystem boundary running out of room at eight jobs rather than anything about the test, and both pass on a rerun.

The manual acceptance checklist is unchanged from v0.5.2 and every result is in docs/acceptance.md. Nothing in this release touches the packaged archive, so nothing in that list could have moved.

What still does not work

There is still no mojo.exe. A compile action that starts is not a compiler.

Two things are in the way now and both were found by getting this far. Command lines on Windows are too long: cmd.exe caps at 8191 characters, CreateProcess at 32767, and a few hundred compile actions and seven link actions in the compiler's graph are past those limits, so the Windows toolchain needs param files. That is #263. Underneath it, the llvm-project repository reaches its sources through relative symlinks that do not resolve through the execroot junction on Windows, so an LLVM compile is handed a source path that is not there. That is #264.

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.

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.

v0.5.2

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 and v0.5.1. What changed is that Bazel now runs on Windows and resolves a C++ toolchain there, which is the boundary between a machine that can start the build and a machine that can do it. That is M6 work, native hosting.

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

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

What changed

Bazelisk can now fetch a Bazel that runs on Windows. .bazelversion names buildbuddy-io/5.0.382, a fork BuildBuddy publishes with four assets, and none of them is Windows, so bazelisk asked for one, got a 404 and stopped before it had started. The Windows wrapper maps that name to the stock Bazel it is actually a fork of. That is #243.

The Bazel on Windows friction list has been checked against a real machine rather than assumed. #34 collected the problems that get described as inevitable, and most of them do not survive contact: case insensitivity is not a problem at this pin, clang-cl version parsing cannot apply because nothing here runs clang-cl, and long path support is the one item on the list that is real and not optional. What actually stopped the build was three things that were not on the list at all, and docs/building.md now has the whole account. That is #34.

One of those three was ours and it took a while to find. Bazel's rc parser treats a backslash as an escape character and drops it, so the SystemRoot line the Windows wrapper generates arrived at the build as C:WINDOWS, which is not a broken path but a drive relative one. What that broke was Bazel's own Windows SDK autoconfiguration, which sat waiting on a shell dialog on a desktop nobody was looking at until it timed out ten minutes later. Doubling the backslash is the only form the parser leaves alone. That is #248.

The cc toolchain has a Windows execution platform. Every toolchain() was registered with exec_compatible_with naming Linux or macOS, so with Bazel running on Windows nothing resolved and analysis stopped with no matching toolchain for the C++ toolchain type, which is a confusing thing to be told on a machine with a compiler on it. This adds a clang that runs on Windows, the tool definitions that go with it, and a registration that names Windows as a machine and not only as a target. The part that took the work was the selects that are keyed on the target platform and mean the execution platform, which had been right only because host and target always agreed. That is #247.

Test results

Every suite is unchanged, 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 test passes. 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 against this archive and every result 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. A resolving toolchain is not a compiler, and analysis on a Windows host is not a build.

Two things are in the way and both were found while finishing the toolchain work. The pip lock file has three environments and none of them is Windows, so the mypy aspect the build turns on for every target cannot resolve its own dependencies, which is #252. Behind that, the three toolchain driver scripts are bare Python files and Windows has no shebang, so the first compile action will fail to launch until they get something that Windows can actually start, which is #253.

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.

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.

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