AppleBridge 0.8d33 — guest kit 2: the install log lands where the docs say it does

Daemon 0.8d33, unchanged. Replaces v0.8d33-kit1, which has a real defect —
use this one.

What was wrong with kit 1

The install log it writes went to the volume the installer was launched from, not to the
boot volume that every document promised. FSMakeFSSpec(0, …) takes the default volume,
and those two are the same thing only when the installer is run from the hard disk — which
is how it was tested and is not how it is used. Running it from the mounted kit, which is
the documented route, put the log on the kit: the volume you are told to drag to the Trash
straight afterwards.

The record disappeared with the medium it documented, inside the feature built to stop
exactly that from happening.

Found within two hours of publishing kit 1, by installing it on a second machine — a 2013
MacBook running German System 7.5.3. Nothing about a clean run on one machine could have
shown it.

Fixed

The boot volume is now resolved through FindFolder(kOnSystemDisk, kSystemFolderType) — the
call the installer already makes twice — so AppleBridge Install Log lands at the root of
your hard disk wherever the installer itself was started from.

Verified from the kit volume on the machine that found it: the new log appeared on the boot
volume while the kit's earlier one stayed byte- and timestamp-identical.

Also new

The installer draws its own version beside the title — AppleBridge Installer 0.8d33.
It was already stamped into the log, but a log is read after the fact; a screenshot in a bug
report could not say which build it was.

Everything else, unchanged from kit 1

Six items including ABJournalDRVR; prefs ship IP=10.0.2.2, the slirp constant that means
whichever host runs the emulator, so there is no address to set and no seeding step.
Download, add the disk line, run AppleBridgeInstaller, restart.

Item
AppleBridge	the daemon, 0.8d33
AppleBridgeWatchdog	autostart owner
AppleBridgeConfig	control panel
AppleBridgeInstaller	preflight, fork-aware copy, autostart, and the log
ABJournalDRVR	journaling driver
AppleBridge Prefs	IP=10.0.2.2, NET=OT

sha256: adeee667000df3ca90db23893f563735d75524ce5f3b8127eacd1b7bda7ff595

Built from a powered-off image and verified by mounting the result.

AppleBridge 0.8d33 — guest kit (SUPERSEDED by v0.8d33-kit2)

⚠️ Superseded — do not use this kit. The install log it writes lands on the volume
the installer was launched from, not the boot volume the documentation promises. Run from
the mounted kit — the documented route — the log ends up on the kit itself, which you are
then told to unmount. Fixed in
v0.8d33-kit2.

---

Daemon 0.8d33. This kit exists because the published one had fallen a
generation behind the code it installs — it carried five items and a 31 July
installer, so neither of the two things merged since reached anybody who
downloaded it.

Six items, not five

ABJournalDRVR now ships. The daemon opens that driver by name from eight call
sites, so a kit without it answered every journaling verb with fnfErr — an
install that looked complete and quietly could not do one of the things it
advertises. The driver is optional on purpose: a payload that has none still
builds and installs, and only a real copy failure is reported.

An install that leaves evidence

Installing is the one phase where this project's diagnostics do not reach: the
bridge does not exist yet, so bridge_doctor, mac_verbose_log and every MCP
tool are blind. Until now neither installer kept anything — the guest drew its
preflight table, its four status lines and the error code of whichever copy
failed, and forgot them. What reached anybody trying to help was, at best, a
photograph of a screen.

This installer writes AppleBridge Install Log to the root of your boot
volume: the preflight table, the transports it detected, the destination, one
line per copied binary with its error code, the prefs actually written, and
whatever the window said. It is written when the installer opens, before you
press anything — so a run whose Install button is disabled by a failed check
leaves a record too. On the screens where something went wrong, the window names
the path.

If you hit trouble, that file is the whole answer. Attach it to an issue.

The host installer does the same into
~/Library/Logs/AppleBridge/install-<timestamp>.log, carrying the readable
report and the JSON probe bundle in one file.

It still asks for no address

The prefs ship IP=10.0.2.2 — not the address of the machine that built this
kit, which a published kit must never carry, but the slirp constant that means
whichever host runs the emulator. Download, run AppleBridgeInstaller,
restart, and the bridge is up.

Change it only if the bridge server runs on a different machine than the
emulator: AppleBridgeConfig on the guest, or
install_bridge.py --seed-guest-prefs <kit.dmg> before you mount it.

Contents

Item
AppleBridge	the daemon, 0.8d33
AppleBridgeWatchdog	autostart owner
AppleBridgeConfig	control panel
AppleBridgeInstaller	preflight, fork-aware copy, autostart — and the log
ABJournalDRVR	journaling driver
AppleBridge Prefs	IP=10.0.2.2, NET=OT

sha256: 1ada797ce714e25df94d8ef53b481fb50af42c8fa0502fe29635990070fb73b2

Built from a powered-off image and verified by mounting the result, not by
trusting the builder's own success message.

AppleBridge 0.8d32 — guest kit, third build

Same daemon (0.8d32, unchanged). This kit exists to make the install ask
nothing and stop one step short of done.

It no longer asks for an address

The prefs ship IP=10.0.2.2. That is not a guess and not the address of the
machine that built the kit: under slirp it is a constant of the branch, the
same on every machine, and it reaches whichever host runs the emulator — slirp
forwards it to that host's loopback, where the server hears it because it binds
every address. Measured 2026-07-31 on two hosts and two guests; the server logs
the peer as 127.0.0.1.

Earlier kits shipped IP= empty, on a documented rule that 10.0.2.2 was
refused. That rule was true while the host server bound one specific address
and quietly stopped being true when the bind became a wildcard — nothing
re-measured it until now. Download, run AppleBridgeInstaller, restart, and
the bridge is up.

Change it only if the bridge server runs on a different machine than the
emulator — then the loopback is the wrong host, and only that machine's own
address can say so. AppleBridgeConfig on the guest edits it, or
install_bridge.py --seed-guest-prefs <kit.dmg> writes it before you mount.

A published kit still refuses to carry any other address: baked into a release
it would point every downloader's guest at the machine that built it, and on a
LAN where that number answers it connects and reports full health.

The installer answers Return

Install is now the default button, and after a successful install the ring
moves to Restart — the same switch that already takes Quit away, because
the bridge does not run until the machine comes back up. Both the button and
the key go through one code path.

This matters for anything set up remotely: a guest driven from another machine
receives key events but not synthetic clicks, so a button with no key
equivalent is where an unattended install stopped. No ring is drawn when the
preflight refuses — a default action that cannot fire is a promise the key does
not keep.

Also

• AppleBridgeConfig can set the host address (from v0.8d32-kit2), with the
  value selected on open and Return/Cmd-S committing.
• The installer's credit line no longer carries a personal name.

Install exactly as before — see docs/SETUP.md.

---

The earlier kits were withdrawn

v0.8d32 and v0.8d32-kit2 are gone from the releases page. Their installer
binary carried a personal name in its credit line, which is not something a
published artifact should distribute; the line now reads the Loetluemmel — and
Claude, his friend. The tags remain as markers of when those builds existed.

Neither was withdrawn for a defect: everything they did, this kit does, and it
also installs without a click and without an address.