blakeslee-research/nucleic-windows
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge nucleic/olive-jade-civet-rznt into dev

Browse Source
This commit is contained in:
abkslm
2026-07-29 00:40:38 -07:00
parent 6d06dcd4d0
commit dcb9f428bb
3 changed files with 158 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files
spikes/README.md
+21 -11
View File
@@ -41,24 +41,34 @@ It writes the full public object model to `wslc-api-dump.txt` (`--out` to reloca
It exits 0 even when assumptions fail — a mismatch is the product, not an error. Only a genuinely
broken run (the assembly won't load) exits non-zero.
Every path in it has been exercised against a stand-in assembly carrying the observed 2.9.3 type
and member names, so a failure on your machine is a finding about wslc, not about this tool.
**What to send back:** the console output, and `wslc-api-dump.txt` if anything is MISSING —
which now means the package moved under us, not that we guessed wrong.
### Why `--session` earns its risk
`--session` creates a real wslc session named `nucleic-spike` under
`%LOCALAPPDATA%\Nucleic\spike\wslc` and leaves it running. It exists for one question that type
metadata cannot answer: **where does the WSL-facing host gateway address come from?** §5 makes
gateway TCP the primary control-plane transport, `WslcContainerEngine.ensureRunning` returns that
address to the Swift side, and `control-bridge.js` dials it. The facade guesses
`Session.HostGatewayAddress`. Dumping the live *values* of every session property lets us
recognise a gateway IP whatever it is called — and if nothing on the session looks like one,
that is itself the finding, and §5's hvsocket fallback gets promoted from upside to dependency.
`%LOCALAPPDATA%\Nucleic\spike\wslc`, starts it, and then **creates a second one with the same
name**. That second construction is the whole point, and it is the last open question D13 turns
on: the compat SDK exposes a `Session` *constructor* and no attach, so does constructing over an
existing name re-adopt it, or refuse?
Leaving the session running is also the cheap version of a §2.3 question: broker supervision
assumes wslc state is **service-backed**, so that a crashed `nucleic-brokerd` can reattach and
re-enumerate rather than orphaning containers. If `wslc session ls` still shows `nucleic-spike`
after this process exits, that assumption holds. Tear it down with `wslc` when you're done.
- **Refused** (expect `WSLC_E_SESSION_RESERVED`, `0x80040607`) — D13's premise is confirmed on
hardware rather than inferred from an IDL, and session reattach genuinely requires
`IWSLCSessionManager::OpenSessionByName` on the internal interface.
- **Constructed** — the compat surface may re-adopt by name, and the session half of §2.3 reattach
may not need the internal interface at all. Check `wslc container ps` for the first session's
containers before believing it.
It leaves the session running on purpose, because that is the other half of the same question:
broker supervision assumes wslc state is **service-backed**, so a crashed `nucleic-brokerd` can
re-adopt rather than orphaning containers. If `wslc session ls` still shows `nucleic-spike` after
this process exits, that holds. Tear it down with `wslc` when you're done.
The gateway address is *not* what this probe is for any more — §13.1 established that no API
surfaces one, and D13 moves the control plane to hvsocket via `IWSLCVirtualMachine::GetId`.
### The three answers that change the design