# The tail *does* draw under active contents — the trade-raid gate, decoded and fired - **Type:** control-flow (static decode + live measurement) - **Status:** **verified** for the trade half; the spy half is decoded but **not reached** and is labelled a hypothesis (rule 6) - **Confidence:** high on the trade half — the callees were entered live, the RNG word delta moved, and the state that moved it was reached by playing a stock game with no file edited - **Owner / date:** lane AC · 2026-09-08 · guest **VM141** (`sots-re-win10-b`, 192.168.10.143) - **Predicts / corrects:** lane W3's open risk (**not** retired — realised), lane L3's `trade-and-spy-workload.md` §3.5, lane V2's "closure 185 functions, draw-free" reading of the trade slots --- ## 0. Headline > **Yes. The strategic-turn tail draws RNG once its containers are *active*.** > `StrategyServer::OnAllCombatDone_Tail` consumes **1 word per turn** in the state this lane built, > against **0** on the same guest, same build and same config on the state lane L3 left. > `TradeManager::Slot13RngCalleeA` — entered **0** times in every measurement any lane had ever > taken — was entered **1×/turn on both instrumented turns**, and `Slot13RngCalleeB` on one of them. > > **Lane W3's open risk is realised, not retired. The RNG ledger and the standalone's generator > model need extending by one draw site.** And the condition that does it is **not** the one lane L3 named. Freighters in service do not do it and a deployed spy would not do it either. The gate is: > **a player-owned fleet parked exactly on a trade-sector node, whose owner's bit is set in that > sector's `tscr` mask — which is set by researching `CCC_ComRaid` ("Commerce Raiding").** That is the trade-raid roll. It had never fired in this campaign because no lane had ever researched Commerce Raiding, and without it the game refuses the order in as many words: **`Alpha Fleet cannot raid trade sector.`** --- ## 1. What was measured Instrument: `shim.cfg.l3probe` verbatim (lane L3's, = lane H's `hp11` + `watch.mode=cont`), shim build `ac-7e726b9-20260909T0017Z`, cross-built on the dev box. All eleven probes reported `create=MH_OK enable=MH_OK`; no `COVERAGE:` line was emitted; the watchpoint canary printed `SELFTEST canary writes=1 traps=1 dr7=0xdddd0055 PASS` on **every** End Turn. These are measured numbers, not MinHook failures. ### 1.1 Entry counts, active state (turns 21→22 and 22→23 of the AC lineage) The **baseline column is this lane's own control**, not a quotation: the same shim build, the same `shim.cfg.l3probe`, the same guest, one End Turn on lane L3's `human-turn15-spyprogram.sav`, run immediately after the active measurement. It reproduces lane H's and lane L3's published counts line for line. | probe | active, turn 1 | active, turn 2 | **AC control** (L3's turn 15) | |---|---|---|---| | `ServerSpyManager::vslot13` | 1 | 1 | 1 | | `ServerSpyManager::vslot14` | 1 | 1 | 1 | | `ServerTradeManagerImpl::vslot13` | 1 | 1 | 1 | | `ServerTradeManagerImpl::vslot15` | 1 | 1 | 1 | | `SpyManager::Slot13RngCallee` | 0 | 0 | 0 | | **`TradeManager::Slot13RngCalleeA`** | **1** | **1** | **0** | | **`TradeManager::Slot13RngCalleeB`** | **1** | **0** | **0** | | `ServerTradeManager::CreateRaidEncounter` | 0 | **1** | 0 | | `ServerTradeManager::GenerateTradeRaidEncounters` | 1 | 1 | 1 | | `ServerSpyManager::vslot15` [control] | 1 | 1 | 1 | | `ServerTradeManagerImpl::vslot14` [control] | 1 | 1 | 1 | | `EncounterDetect::Run` [control] | NOT INSTALLED | NOT INSTALLED | — | `Slot13RngCalleeB` firing on turn 1 and not on turn 2 is exactly what the decoded control flow predicts: `B` is called only when `A` returns true, i.e. only when the raid roll **succeeds**. Two turns, one success — the roll is doing what a roll does. ### 1.2 The RNG ledger `side.rng` word deltas. **Control first** (L3's turn 15, no raider, same instrument): ``` ProcessTurn 353 -> 355 delta 2 OnAllCombatDone_Tail 355 -> 355 delta 0 ``` **Active** (raider parked on sector 6's node), both turns: ``` ProcessTurn 448 -> 468 delta 20 OnAllCombatDone_Tail 468 -> 469 delta 1 ProcessTurn 469 -> 487 delta 18 OnAllCombatDone_Tail 487 -> 488 delta 1 ``` **One word per turn inside the tail**, on a turn where the tail had never drawn a word before. The draw is `FUN_0047d830(StrategyServer+0x16c + 4)` inside `Slot13RngCalleeA` — one uniform compared against the raid odds. `Slot13RngCalleeB` and `CreateRaidEncounter` each cost 0 words on the turns they ran, so the whole of the new consumption is `A`'s single roll. --- ## 2. The gates, decoded from the instruction stream Read off `sots.exe` (image base `0x00400000`), disassembling to the next function start rather than to Ghidra's reported size (rule 17). ### 2.1 `Slot13RngCalleeA` / `B` — called from `ServerTradeManagerImpl::vslot13` Both calls are **direct** `E8 rel32`, not vtable slots: | callee | called from | at | |---|---|---| | `TradeManager::Slot13RngCalleeA` `0x00820ca0` | `ServerTradeManagerImpl::vslot13` `0x0088ef80` | `0x0088f036` | | `TradeManager::Slot13RngCalleeB` `0x0088b440` | same function | `0x0088f042` | | `SpyManager::Slot13RngCallee` `0x008408e0` | `ServerSpyManager::vslot13` `0x008877b0` | `0x00887af2` | `ServerTradeManagerImpl::vslot15` (`0x0082cca0`) and `ServerSpyManager::vslot14` (`0x0088db80`) do **not** call any of the three. The only data references to the four outer callees are their vtable slots (`0xa30770`, `0xa30774`, `0xa31ba8`, `0xa31bb0`). **`vslot13` does not iterate trade routes or trade sectors.** It iterates `StrategyServer+0x64..+0x68` — the **fleet** vector — and per fleet requires, in order: ``` 0088ef95 test ecx,0xfffffffc ; G0 no fleets -> return 0088efb1 je 0x88f047 ; G1 null slot 0088efb9 call 0x6fe320 ; StarFleet::GetLocationAsTradeSector() 0088efc0 je 0x88f047 ; G2 location is not a trade-sector node 0088efc7 call 0x80ed50 ; the raid predicate 0088efd1 je 0x88f047 ; G3 0088efeb..0088f016 ; G4 fleet.Pos == sector.Pos, all three floats 0088f036 call 0x820ca0 ; <-- A 0088f03d je 0x88f047 ; G6 raid roll failed 0088f042 call 0x88b440 ; <-- B ``` **G2** is the one nobody had satisfied. `0x006fe320` reads `StarFleet+0xa0` (`LocID`, resolved to a pointer) and returns it only if `node+0x14 == 2`. That kind word is written by `StarMapNode::StarMapNode(int)` `0x00730900`, and enumerating **every** call to it gives exactly three: `StarSystem` ctor `0x00752ea0` passes **0**, `StarFleet` ctor `0x00706140` passes **1**, `TradeSector` ctor `0x00858020` passes **2**. So `vslot13` only ever acts on a fleet whose location is a **trade-sector node**, never a star. Every fleet in every corpus save before this lane was parked at a star, so G2 rejected all of them — which is why the "23-fleet Zuul save" experiment in `tail-probes.md` §3.1 could not have worked no matter how many fleets it had. **G3** is `FUN_0080ed50(fleet)`: ```c if (!fleet->GetLocationAsTradeSector()) return false; if (FUN_00813ab0(fleet, 0x80000, 0)) return false; // runtime flag pair +0xb8/+0xbc ServerPlayer *p = fleet->[0x58]; if (!p) return false; if (!(sector->[0x90] & (1u << p->[0x28]))) return false; // ** tscr ** if (FUN_0080e9c0(sector, p)) // ** tsct ** bit, or p->[0x5c]==4 if (!FUN_006fe1d0(fleet, 0x800)) return false; // FtFlg & 0x800 return true; ``` `FUN_0080eac0` masks six consecutive words with a low-N-players mask, which is what identifies them as per-player bitmasks and pins the tags: ``` 0080ead7 and [ecx+0x88],edx tssec 0080eae3 and [ecx+0x90],edx tscr 0080eadd and [ecx+0x8c],edx tsct 0080eae9 and [ecx+0x94],edx ptssec … ``` **G4** requires the fleet's `Pos` (`+0x18`) to be **bit-equal** to the sector's — arrived, not in transit. The `test ah,0x44 / jp` after `fucompp` is the MSVC float-not-equal idiom. ### 2.2 `SpyManager::Slot13RngCallee` — decoded, and much further away than "deployed" ``` 0088781d je 0x887e92 ; SpyCraft.deat (+0x10) == 0 -> next spy 00887856 je 0x887c5b ; SpyCraft.sdet (+0x40) == -1 -> DETECTION-ROLL branch, not P 00887867 jl 0x887e92 ; (turn - sdet) < 3 -> next spy 0088787a je 0x887c4f ; system unowned -> sdet = -1 00887891 je 0x887c4f ; system owner == spy's owner -> sdet = -1 00887af2 call 0x8408e0 ; <-- P ``` `P` itself is the **false-flag draw**: `0.25` (`0x009e5ac0`) for an ordinary owner, or `0.75` (`0x009e5ac4`) plus a uniform pick over the other players when `owner->[0x5c] == 6`; its result is the name that goes into `EVENT_SPY_DESTROYED`, posted to the *system* owner. So **deploying a spy is necessary but nowhere near sufficient for `P`**: the spy must be deployed, then **detected** on an earlier turn, then survive **three more turns** at a system still owned by someone else. Lane L3's "the next condition is `spyon = 0`" understates the distance by three turns and a detection roll. **But the `sdet == -1` arm at `0x00887c5b` is itself an RNG draw** — `FUN_008e6dd0(StrategyServer+0x16c, spy->sdo)`, gated on `FUN_00743f80(system) & 1` — and it sits **inline in `vslot13`, not inside `P`**. That is a second, independent way for the tail to draw that **no entry probe on `P` can see**. It is unreachable today only because `deat == 0` rejects the docked spy two gates earlier. Rule 20, pointing the other way: instrumenting the entry was necessary and was not sufficient — a probe on `P` reading 0 does **not** mean the spy half is draw-free. **This is a hypothesis, not a result** (rule 6): no save in the corpus has a deployed spy, and this lane did not manage to build one (§5). --- ## 3. `tscr` is the raid mask and `CCC_ComRaid` sets it — measured, before and after This is the part that turns the decode into a recipe, and it was **not** predicted: this lane's committed prediction P6 said a player fleet on a sector node would *not* fire the callees, on the reasoning that `tscr = 252 = 0b11111100` is exactly the six NPC player slots (2–7) and excludes both real players (0 = `re`, 1 = `The Eternal Empire`). That reading of the *value* was right and the inference from it was **wrong**, because the mask is not fixed. | save | `tscr`, all six sectors | player `re` `CnRad` | |---|---|---| | `human-turn15-spyprogram.sav` (L3) | **252** = `0b11111100` | absent/false | | AC turn 19, after `CCC_ComRaid` completes | **253** = `0b11111101` | **true** | Researching Commerce Raiding sets **bit 0 — the researching player's index — in every trade sector's `tscr`**, and sets the `ServerPlayer` flag serialised as **`CnRad`**. `CnRad` is to `CCC_ComRaid` exactly what `CnTrd` (`ServerPlayer+0xff`) is to `CCC_FTLEcon`. The AI, which never researched it, stays out of the mask: `CnRad` false, bit 1 clear, in the same save. So `tscr` reads: *the set of players permitted to raid this sector* — the six NPC slots by default (which is why `TRADE_RAID_ODDS_NPC` and `TRADE_RAID_ODDS_REFUGEE` exist), plus any empire that has bought its way in with the tech. Two further tags fall out of the same pair of saves: `tsct` is the set of players **trading through** the sector (bit 1 on sectors 1, 2 and 5 — the AI's; 0 on sector 6, which is mine), and it is `tsct` that switches on the extra `FtFlg & 0x800` requirement. Sector 6 has `tsct = 0`, so my raider needed no flag. --- ## 4. The recipe, end to end Stock game, stock data, no file edited, starting from lane L3's `human-turn15-spyprogram.sav`. About 45 minutes of clicking. 1. **Research `CCC_ComRaid`.** `MasterTechList.tech`: `CCC_FTLEcon -> CCC_ComRaid RP:12000 Human:100`. At this game's settings it is **one turn**. In the tech tree it is the node **directly above FTL Economics in the C3 branch**, and at the zoom the screen opens at it is drawn *off the top of the viewport*: zoom out two notches with the wheel, then zoom back in one notch **with the cursor low on the screen** (`wheel 365 560 120 1`), which shifts the camera down far enough to expose it. Vertical right-drag does **not** pan the tech tree at all — only horizontal, and only in ~600 px steps, and even then the response is not monotonic in distance. 2. **Toggle Trade View.** Bottom bar circle **(300,714)** opens a six-icon vertical strip; the fifth icon **(301,626)** is `Toggle Trade View`. Trade sectors then draw as large translucent wireframe cubes with a padlock/`$` marker at the sector node itself. **Nothing else in the UI shows a trade sector**, and there is no bar button for trade. 3. **Order a fleet to the sector node.** Select the system, select the fleet row, click **`Move` (155,464)**, hover the sector marker — the readout reads `Sector 6 / Range 5.0 / ETA 2 Turns` — then **plain `click`** it. This must be **one `cmd.txt`**; and note the jiggle-click variant (`jclick`) **silently failed to register the destination** where a plain `click` worked. Confirm from the fleet panel: it reads `Dest: Sector 6, 2 Turns`. Confirm again from the save — do not trust the panel: on the first attempt the panel showed nothing and the save showed `LocID 48` (unmoved). 4. **Two End Turns.** The fleet arrives: `LocID 832` = `TradeID 832` = sector 6, `Pos [0, 0, 8.0]` bit-identical to the sector's `Pos`. 5. **End Turn with the instrument on.** `Slot13RngCalleeA` fires. **The refusal is the oracle.** Before the tech, clicking the sector marker with a fleet selected pops `Alpha Fleet cannot raid trade sector.` (`MOVEWARNING_NO_RAID`; the server-side twin is `OnCommand: Fleet not able to raid.`). After the tech, the same click is accepted silently. That single dialog is the cheapest possible test of the whole gate chain. --- ## 5. What this lane could **not** reach: a deployed spy Reported as an absence, not inferred around. `ARes2` on `ServerSystem` is the **asteroid-belt** field — its non-zero values in this save (1703, 1948, 2061, 2172, 2531) sit inside `SYSTEM_MIN/MAX_ASTEROID_RESOURCES` 1500–3000, and it is 0 elsewhere. Deploying a spy needs a system that is **not mine**, has **no enemy fleet present**, has **no spy already**, and **has a belt**. In `human-turn15-spyprogram.sav` only five of 28 systems have one: | idx | id | name | `ARes2` | owner | |---|---|---|---|---| | 1 | 64 | Ka'Palum | 2061 | unowned | | 4 | 112 | Regulus | 1703 | unowned | | 10 | 208 | Kam'Tara | 1948 | unowned, AI fleet parked on it | | 12 | 240 | Downbelow | 2172 | **mine** | | 27 | 480 | Hitomi | 2531 | player index **7**, `Independent Colony` | **No system owned by the AI has an asteroid belt.** The textbook target — an enemy colony with a belt — does not exist in this game. The only non-own, player-owned belt system is **Hitomi**, held by the NPC `Independent Colony`; it is 10.1 ly from the tender's berth against a hull range of 9.0, so it needs a staging hop, and this lane ran out of session before establishing whether it is even discovered. The `Special` menu at the tender's own system offers only `Repair / Scuttle / Auto-repair / Flag As Guard` — no `Deploy Spy`, which is consistent with the gate but does not locate it. So: **the spy half of "active contents" remains unreached**, and §2.2's prediction that a deployed spy makes the tail draw through the inline detection roll is a hypothesis for the next lane. The save to start from is `verify/results/saves/ac-turn22-raider.sav` or L3's turn-15. **`spies2` is still 0 in all 28 systems** in every save this lane produced, including the turn-22 one. That is unchanged from L3 and is expected: no spy was ever deployed, so the experiment that distinguishes "`spies2` is not the spy list" from "`spies2` fills only for a deployed spy" was **not run**. The rule-6 flag on `spies2` / `SysMem` / `mts` stays up. What this lane can add is that the question is now cheap for whoever reaches a deploy, because `deat` (`SpyCraft+0x10`) is the field `vslot13` uses as the system handle, and `spies2` living on `ServerSystem` makes the deployed-spy reading the natural one. --- ## 6. Corrections to earlier findings (rule 11) **Lane L3, `trade-and-spy-workload.md` §3.5 — "every trade sector has `tsnumflt = 0`, no freighters in service".** Not true of the save L3 shipped. `human-turn15-spyprogram.sav`, sector `TradeID 816` (`tsgridID 5`): `tsnumflt 1`, `tsflt 2736` — and fleet 2736 is `Freighters`, `PID 32`, the **AI's**, with all six member systems AI-owned. The single serialised route record is the AI's too. So across L3's seven instrumented turns the game **already had a freighter in service on an active route**, and the trade callees were entered 0 times anyway. **"Freighters in service" was already falsified as the gate by L3's own data**, before this lane started, and §2.1 now says why: freighters are not in the predicate at all. By turn 20 of this lane's lineage the AI had built two more (sector 5 `tsnumflt 2`, sector 2 `tsnumflt 1`) with no effect on any probe. **Lane V2 — `ServerTradeManagerImpl` vftable slot 13 recorded as "closure 185 functions, draw-free".** It is not draw-free. It reaches a `NextFloat` at `0x00820ca0` on any turn a permitted raider is parked on a sector node. The closure was right; "draw-free" was a statement about the states that occurred (rule 23). **Lane W3's standing risk — "if either container ever fills, the ledger needs extending".** The risk was correctly identified and the trigger was wrong: filling the containers changes nothing, and the ledger needs extending anyway, for a reason that has nothing to do with either container's contents. **`tsflt` is not a freighter list.** At turn 20, sector 6 reads `tsnumflt 1`, `tsflt 3744` — and 3744 is **my raiding fleet's** id, not a freighter. Whatever the tag is named, it counts fleets present in the sector. --- ## 7. Controls and coverage (rules 15, 19, 26) **Guest adoption / instrument-removed control.** `hooks=off watch=off` on `ref-turn2.sav`, one End Turn, on VM141 with this lane's own shim build: ``` (Autosave EndTurn).sav BB4FD9AC89F41E3BC0DB2AF08B18CE83417521AC4BCEE695FC9FA6CE16E30948 (Autosave).sav 978041ACD168B56ED8EB3F5E42E78D5E70EAE6E6517D75E659A5EB7CA3D60921 ``` Both **identical to the published three-run oracle** in `verify/results/saves/determinism-hashes.txt`. That is agreement with a control already reproduced in three fresh processes by other lanes on another guest, which is the rule-26 bar; this lane ran it once here rather than twice, and says so. **Instrument armed.** All eleven probes `create=MH_OK enable=MH_OK`, no `COVERAGE:` line; watchpoint canary PASS on every End Turn; container watch read `trade routes count=46 -> 47`, `spy programs count=1` across the two measured turns. **Thin coverage, stated plainly.** - **Two instrumented turns, one raiding fleet, one sector, one ship in the fleet.** The word cost is 1 on both, but 1 fleet × 1 sector is the smallest possible workload and the per-fleet loop means the cost should scale with *permitted raiders parked on sector nodes*, which this lane did not vary. Do not fit a constant to two observations (rule 20). - `Slot13RngCalleeA`'s own body has a **short-circuit that skips the draw entirely**: any ship whose `design+0x12c > 1` returns true without rolling. My fleet is one `CR Repair and Salvage`, so the short-circuit was not exercised, and a raid by a different hull could cost **0** words while still firing `B`. Untested. - The odds arithmetic (`0.20` vs `0.05` base, `+0.01·nShips`, doubled when a freighter shares the sector, scaled by a per-ship float) was read statically and **not** validated against measured success rates: two turns, one success. - `probes=11` is **not** determinism-neutral (lane H bisected the detour on probe index 8). These entry counts and word deltas are comparable line-for-line with lane H's and L3's tables, which is what they are for; they are not a byte-identity claim. `probes=8` still installs indices 0–7, i.e. all four outer and all three inner callees, and is the configuration to use if a future lane needs both at once. - `EncounterDetect::Run [control]` is index 11 and `probes=11` installs 0–10, so it reports **NOT INSTALLED**, never 0. --- ## 8. Artifacts | what | where | |---|---| | turn-22 save, raider parked on a trade sector, both callees having fired | `verify/results/saves/ac-turn22-raider.sav` | | turn-20 save, the moment the fleet arrives on the node (pre-measurement) | `verify/results/saves/ac-turn20-raider.sav` | | probe + ledger trace, two instrumented End Turns | `verify/traces/ac-probe-turn21-turn23.jsonl` | | shim log and watch hits | `verify/results/shim/ac/ac-probe-run-{shim.log,watch.txt}` | | predictions, committed before the workload and again after the decode | `sots-engine` `docs/AC-predictions.md` | | instrument | `sots-engine` `src/shim/shim.cfg.l3probe`, unchanged | **New content these saves carry** (rule 27 — expect the coverage ratchet to break, and type the content rather than moving the bar): a `ServerPlayer` with **`CnRad` true**; trade sectors with **`tscr` = 253** rather than the corpus-universal 252; a `trdmgr` with **three** `rt` route records rather than one; sectors with `tsnumflt` up to 2 and a `tsflt` entry that is a **warship** fleet id rather than a freighter; and a `StarFleet` whose **`LocID` is a `TradeSector` id (832)** rather than a star system id — the first fleet in the corpus located anywhere but a star, which is precisely the state that makes the tail draw. --- ## 9. VM141 as left, and two things that cost this lane time **Guest state.** Game stopped. `C:\SOTS\shim.cfg` is a copy of `shim.cfg.l3cont` (`hooks=off`, `watch=on`, `watch.mode=cont` — the cheap config); the lane's dist is `C:\SOTS\shimdist-ac` (`BUILD_ID ac-7e726b9-20260909T0017Z`) and `C:\SOTS\binkw32.dll` is that build's proxy, with the original still at `binkw32_real.dll`. `SavedGames` has been restored from `C:\SOTS\SavedGames-acstash` and additionally holds **`ac-turn20-raider.sav`** and L3's three saves, so **every Load-dialog row position recorded by an earlier lane has moved on this guest** — screenshot the dialog, do not reuse a remembered row. Also left, all harmless: `C:\SOTS\acdata\` (config text extracted from `sots.gob`) and `C:\SOTS\ui\ac-*.ps1`. **`click_helper.ps1` gained six verbs**, purely additive, every existing verb byte-for-byte unchanged; pre-lane backup at `click_helper.ps1.preAC`: ``` drag x1 y1 x2 y2 left-button drag (ported from VM144, lane L3) rdrag x1 y1 x2 y2 RIGHT-button drag, 30 steps (the only thing that pans the tech tree) sdrag x1 y1 x2 y2 slow left drag, 40 steps wheel x y delta [n] n wheel notches jmove x y move with a real relative mouse_event jiggle (new; ported from lane L2's ui.ps1) jclick x y click with the same jiggle (new) ``` **The jiggle is needed to *read* the star map and harmful when *committing* to it.** `jmove` is what makes the map's hover readout update — without it the `Sector 6 / Range 5.0 / ETA 2 Turns` line never appears and you are clicking blind. But `jclick` on the sector marker **did not register the destination**, twice, silently; a plain `click` at the same coordinate did, first time. So: `jmove` to read, plain `click` to commit. Lane L2's note that the map "needs real mouse motion" is right about motion and wrong if read as "use the jiggle for everything". **Verify a fleet order from the save, never from the panel.** The first move order left the fleet panel showing no destination *and* the save showing `LocID 48` — unmoved — through two End Turns, with no error anywhere. The second attempt showed `Dest: Sector 6, 2 Turns` in the panel and moved. There is no failure signal; the only reliable check is `Flt.LocID` in the autosave. **Dev-box build note (not a repo change).** `cmake/toolchain-mingw-i686.cmake` links libgcc and libstdc++ statically but not **libwinpthread**. On the WSL dev box the i686 mingw is the *posix* threads model, so `binkw32.dll` comes out importing `libwinpthread-1.dll` and the game dies at load with `0xC0000135 STATUS_DLL_NOT_FOUND` — no shim log, no banner, just an exit code in `dxvklog\run.txt`. Adding `-DCMAKE_SHARED_LINKER_FLAGS=-static` fixes it. CT111 does not have this problem (its mingw uses the win32 model), which is why no lane has hit it before; the toolchain file was deliberately **not** changed, because that is a shared-infrastructure decision for the integrator rather than a lane's.