windows-ucrt64 runtime: no mount tier (exit 69) — windows payloads cannot execute on their own platform

[ronaldtse]

Summary

The windows python runtime (windows-ucrt64 packages) has no mount tier: the fs TU answers any mount request with a named exit 69, so the interpreter runs only in bare/dev mode. This is documented in this repo's README ("the windows boundary"), so this issue tracks closing it — a windows payload cannot execute on its own platform until then.

Impact (who is blocked)

• tebako-packages/xml2rfc: the x86_64-windows-ucrt payload leg was built and iterated through five CI runs before being deferred (PR Publish: ping the versions catalog (plan 05) #11) — the payload builds and stages cleanly, but boot-smoke on windows-2022 can never pass while every mount exits 69.
• Downstream: any client composing python payloads for windows (e.g. metanorma's ietf chain, which today keeps windows on a host-python path).

What landing it means

• The fs TU gains the windows mount implementation (the runtime root + payload mounts, longest-prefix dispatch) so the spec-17 driver path works on windows the same as POSIX.
• Acceptance: the xml2rfc windows leg's boot smoke (tebako check version + render-txt through the mounted payload) passes on windows-2022; the exit-69 refusal remains only for genuinely unsupported requests.

Notes from the feedstock-side exploration

• Staging a windows runtime consumer-side already works end-to-end (shard fetch, three-way digest verification, .dll facet + install_as layout) — the mirror is correct; only the mount tier is missing.
• Independent of this issue, a mingw socket defect in the source factory's windows-msys build also blocks real workloads in bare mode (WinError 10035 on timed connects) — filed against the source factory; it will matter for mounted mode too once mounts exist.

[ronaldtse]

Recon update (2026-09-15) — the port target is confirmed and the work shape is now pinned down.

Where the 69 lives: build/resources/tebako_python_main.c (the fs TU template) — on _WIN32, after tebako_driver_boot mounts the env image, the interpreter's own IO cannot see the mounts (the POSIX visibility mechanism is libtfs-preload's constructor re-mount; no windows interpose tier exists), so the TU fails closed by name.

The port target: the ruby factory's windows answer is patched interpreter IO, not a preload equivalent — tamatebako/ruby's msys patch family (io_c_shims_msys, dir_c_memfs_msys, file_c_tebako_includes, mkconfig_memfs_prefix_msys, loadpath_mount_root) routes ruby's own file layer through libtfs in-process.

So this lands in two repos:

1. tamatebako/python — a fileio_memfs_msys patch family in patches/3.14/ (ordered after 0040) covering CPython's IO surface: Modules/posixmodule.c, Modules/_io/fileio.c, importlib's path-based finders (the frozen bootstrap reads .py files before any user code runs — the widest part of the surface), and getpath.py resolving PYTHONHOME to the mount root.
2. tebako-runtime-python — the fs TU's _WIN32 branch drops the 69 answer when the patched-IO grant is present, PYTHONHOME exports from the effective mount root on windows, and boot smoke gains a mounted-mode assertion on windows-2022.

Also noted: the bare-mode socket defect this issue mentioned (WinError 10035) is fixed as of tamatebako/python#26 (the 0040 _PyIsSelectable_fd patch) — mounted mode is all that remains here.

[ronaldtse]

Design for the windows mount tier — options and a recommendation

The blocker, precisely: CPython is unpatched, so its libc IO can only see the driver's mounts through spec 22 tier-1 preload interposition — and windows has no preload tier. Everything else already works: the windows-ucrt64 runtime builds, publishes (exe + dll facet + env image), stages consumer-side, and answers the driver contract's named errors.

Three ways to close it:

• (a) True windows interposition — a shim DLL hooking the CRT file-IO surface (IAT/inline hooks). Jail-preserving, the "real" tier, but no precedent in the codebase; weeks-class; per-CRT coverage risk.
• (b) msys-scenario io patches — port the ruby memfs-patch approach into the source factory's windows tree. Jail-preserving but breaks the zero-patch contract on one platform, and the C surface is large (posixmodule / fileio / importlib).
• (c) Materialize tier (recommended v1) — the boot mounts and verifies exactly as today, then extracts the env image and each payload image into the content-addressed exec cache (sha-keyed, digest-pinned, write-once — the driver's boot-materialization discipline generalized per-file → per-tree, pinned by the image's tree hash). PYTHONHOME = the extracted runtime root, PYTHONPATH = the extracted payload roots; the interpreter runs on plain host paths. Native extensions already materialize on windows through the dlmap PE-closure walk, so (c) extends a precedent the platform set rather than inventing one.

Recorded deviations for (c), deliberately on the table: it is extract-not-mount (windows only — POSIX untouched), and the jail cannot interpose plain host IO, so a materialized payload's reads are unguarded. Since nothing runs mounted on windows today, that is a capability gain with a documented weaker posture, not a regression. (a) remains the long-term answer if windows ever needs the interposition semantics.

Unblock chain once the tier lands: re-enable the xml2rfc x86_64-windows-ucrt leg (deferred in tebako-packages/xml2rfc#11; its boot smoke is the acceptance) → the metanorma manifest's triplets: conditioning gains the ucrt triplet → the ietf chain works on windows, airgap bundles included.

Independent adjacent defect, noted for the record: the source factory's windows-msys build carries a mingw socket defect (WinError 10035 on timed connects, filed against tamatebako/python) — it will matter for mounted mode once the tier exists.

[ronaldtse]

Owner decision (2026-09-17): approved — option (c), the materialize tier.

The windows python runtime boots by mounting + verifying the env/payload images, then extracting them into the sha-keyed, digest-pinned exec cache (the per-file materializer generalizes to per-tree), with PYTHONHOME/PYTHONPATH pointing at the extracted roots. Accepted deviations, windows only:

• "mounted — never extracted" relaxes on windows only (POSIX stays mount-forever).
• The jail cannot interpose host IO under an extracted tree — windows python exec runs under the OS's own file ACLs on the cache dir (read-only cache entries, per-entry flock discipline unchanged).

Landing order per the design-first rule:

1. Spec delta in tamatebako/tebako (driver contract amendment: the windows materialize tier, its cache discipline, its exit codes).
2. Driver implementation (crates/tebako-driver — per-file → per-tree materialize generalization) + a tebako release carrying it.
3. tebako-runtime-python windows leg on that release.
4. xml2rfc windows leg re-enable + closure lock; metanorma's xml2rfc edge gains x86_64-windows-ucrt; flavor bundles gain ietf on windows.

The adjacent mingw socket defect (WinError 10035 in the windows-msys build, filed on tamatebako/python) stays an independent track.