Replace the C++ collector with a C17 implementation using the existing
accessibility protocol and VM viewer bridge. Separate UI Automation
capture/actions, event handling, and Windows JSON serialization.
Translate native control patterns and text/table relationships generically,
preserve element identity across snapshots, and align request deadlines
and refresh scheduling with the macOS collector.
Expose guest accessibility trees through a host AppKit helper and forward attributes, actions, text operations, and input through shared transport.
Package macOS and Windows guest collectors and integrate viewer lifecycle, refresh scheduling, and geometry handling.
App Sandbox 0.1.8
### Added
- Choose a specific GPU when creating or editing a VM on Windows, with automatic fallback if that GPU becomes unavailable.
Thanks to @TejasPersonal, @Mungr3ss and @JasonSTX for requesting this ([#109](https://github.com/jamesstringer90/appsandbox/issues/109)), and @trevmlt for documenting the multi-GPU problem and a workaround ([#110](https://github.com/jamesstringer90/appsandbox/issues/110)).
### Fixed
- Preserve VM MAC addresses across restarts on Windows and macOS, allowing router address reservations to keep working.
Thanks to @kurokawaikki for identifying the changing MAC addresses ([#92](https://github.com/jamesstringer90/appsandbox/issues/92)).
- Keep automatic login enabled and prevent password expiry for newly created Windows VMs on Windows and macOS hosts.
Thanks to @macg4dave for reporting unexpected login prompts ([#133](https://github.com/jamesstringer90/appsandbox/issues/133)).
- Fix network setup failures when starting multiple VMs at the same time on Windows.
- Reduce unexpected SSH port changes on Windows by retrying the saved port, with clearer failure messages.
- Fix missing network drivers in newly created Windows VMs on macOS.
Thanks to @YiwenLu-yiwen for reporting the failed download and confirming the workaround ([#107](https://github.com/jamesstringer90/appsandbox/issues/107#issuecomment-5689676123)).
On Windows hosts, choose a GPU by name when creating or editing a VM through the UI or API. Identically named GPUs can be distinguished, and unavailable GPUs fall back to Default GPU.
Keep VM MAC addresses stable across restarts on Windows and macOS hosts, including existing VMs.
Fix shared-network creation races when starting multiple VMs at once on Windows.
Keep automatic login enabled and prevent account passwords expiring for newly created Windows VMs on Windows and macOS hosts.
Retry the saved SSH proxy port before choosing a replacement, and log bind failures on Windows.
Update Windows VM creation on macOS to download the ARM64 network driver from main.
App Sandbox 0.1.7
### Added
- NVIDIA DLSS support in compatible Vulkan games running in Windows VMs on x64 Windows hosts.
Thanks to @darkjezza for reporting this ([#139](https://github.com/jamesstringer90/appsandbox/issues/139)).
- A dedicated VM settings dialog on Windows and macOS, and a clearer snapshot and branch manager on Windows.
### Fixed
- Corrected GPU and network information on macOS and removed unsupported network options.
VM settings and snapshots move out of inline table controls into dedicated dialogs, using the existing app styling and snapshot behavior.
Changed
Edit CPU and memory in a dedicated dialog on Windows and macOS hosts, with Save and Cancel. Windows hosts also support editing GPU and network settings.
Manage snapshots and branches in a tree dialog on Windows hosts, with creation, rename, and delete actions. The previous choice and new selection are marked with (current) and (selected).
Keep settings changes disabled while a VM is running or its disk is being built, and show an error if an edit fails.
Correctly show software rendering for Windows VMs on macOS hosts.
Show the actual NAT networking used on macOS hosts and hide unsupported network choices during VM creation.
App Sandbox 0.1.6
### Added
- Native NVIDIA OpenGL and Vulkan support in Windows VMs on x64 Windows hosts, including 32-bit games and applications.
**Special thanks to @Poldino95 for figuring out why NVIDIA's native graphics drivers weren't working inside VMs and demonstrating working solutions. Their detailed research provided the foundation for these improvements.** ([#130](https://github.com/jamesstringer90/appsandbox/pull/130), [#131](https://github.com/jamesstringer90/appsandbox/pull/131))
Thanks also to @N1qro for reporting Vulkan game launch failures ([#73](https://github.com/jamesstringer90/appsandbox/issues/73)).
- NVIDIA DLSS support in compatible 64-bit games running in Windows VMs on x64 Windows hosts.
Thanks again to @Poldino95 for identifying what prevented DLSS from working and demonstrating the solution ([#129](https://github.com/jamesstringer90/appsandbox/pull/129)), and @Giraffe886 for raising this ([#98](https://github.com/jamesstringer90/appsandbox/issues/98)).
### Fixed
- Improved OpenGL and Vulkan support for Intel and AMD GPUs in Windows VMs by using their native graphics drivers, including supplying missing AMD driver files.
- Fixed Ubuntu 26.04.1 VMs getting stuck during installation.
Thanks to @EzYDark for diagnosing the package compatibility problem and proposing a fix ([#120](https://github.com/jamesstringer90/appsandbox/pull/120)).
- Fixed Firefox failing to launch in newly created Ubuntu VMs.
Thanks to @EzYDark for identifying the cause and proposing a fix ([#120](https://github.com/jamesstringer90/appsandbox/pull/120)).
- Fixed package update errors in newly created Ubuntu VMs caused by leftover installation-disc sources.
Improves OpenGL and Vulkan support for Windows VMs on x64 Windows hosts.
NVIDIA GPUs now support native OpenGL and Vulkan, including 32-bit applications.
Fixed missing AMD OpenGL and Vulkan driver files in Windows VMs.
Intel and AMD VMs now use their native graphics runtimes by default instead of Mesa.
The NVIDIA components build, sign, and bundle through the existing release process and install through the existing guest-agent file transfer. Native runtime setup requires the updated guest agent; older agents retain their existing graphics setup.
Fixed Ubuntu 26.04.1 VMs getting stuck during installation.
Fixed Firefox failing to launch in newly created Ubuntu VMs.
Fixed apt update errors caused by leftover installation-media sources.
Verified installation, Firefox launch, and apt update on fresh Ubuntu 26.04 and 26.04.1 VMs on Windows hosts.
Build and stage x64 and x86 NVIDIA shims through the existing solution and deploy them through P9 and the guest agent. Include active AMD runtime packages and prefer native OpenGL and Vulkan on NVIDIA, AMD, and Intel guests.
Correct the Xcode file reference and CoreGraphics API call. Keep creation actions disabled for invalid configuration and use the v0.1.5 ARM64 guest resource ZIP.
App Sandbox 0.1.4
- **Windows 11 (ARM64) VMs on macOS.** On an Apple Silicon Mac, App Sandbox can
now create and run Windows 11 ARM guests -- previously a macOS host could only
run macOS guests. The Windows guest gets its own display window, keyboard and
mouse, sound, clipboard (including copying files to and from your Mac),
one-click SSH, and networking, and is built from a Windows 11 ARM64 ISO you
provide. It runs on a self-contained virtual-machine engine bundled with the
app, and the guest agent and drivers are downloaded (code-signed) when you
create the VM, so no test-signed components ship inside App Sandbox.
- **Non-ASCII usernames and passwords now work when creating a VM through the
scriptable API.** Characters outside plain ASCII (for example Chinese) arrive
from the API JSON-escaped; App Sandbox stored the escape sequences literally
instead of decoding them, so a VM created via the API with such a credential
would reject the login. They are now decoded correctly. (The desktop app was
unaffected.)
- **The virtual display now recovers if it gets disabled in the guest.** The
guest agent kept trying to restart the App Sandbox display driver -- which
can't re-enable a disabled device -- so the picture never came back; it is now
re-enabled and recovers.
- Various stability and bug fixes across the Windows and macOS components.
- **Windows VMs on macOS are not GPU-accelerated.**
- **x64 (emulated) apps in ARM Windows VMs don't get the OpenGL fix** -- the Mesa
driver shipped on ARM is ARM64-only; native ARM64 apps get full GPU OpenGL.
(carried over from 0.1.2)
- **ARM Linux (Ubuntu 26.04 LTS) guests do not work -- on ARM, Windows is the
only working guest** (Ubuntu 26.04's arm64 kernel churns BPF JIT memory and
never reaches the desktop). (carried over from 0.1.2)
## Summary
Adds support for running **Windows 11 ARM64 guests on macOS (Apple Silicon) hosts**.
Until now a macOS host ran only macOS guests (Virtualization.framework); this branch boots
Windows guests on a bundled **QEMU + Hypervisor.framework (HVF)** VMM, with an **ivshmem
shared-memory transport** carrying every guest channel — agent control, display (VDD), input,
audio, clipboard, SSH, and 9P — so **no guest networking is required**. The same headless
HTTP/JSON API and GUI now create Windows guests on a Mac, and Windows-on-Windows behaviour
is unchanged.
## How it works
- **Transport** (`tools/transport`): a single guest transport API with two backends — PC
`AF_HYPERV` (unchanged) and Mac **ivshmem** — over an SPSC ring. `src/backend_mac` maps the
ivshmem BAR and runs the host side of each channel; the launcher publishes the region
directory and the guest reads its geometry at boot.
- **Guest driver** (`tools/ivshmem`): an in-house KMDF ivshmem BAR-mapping driver
(**AppSandboxSHM**, `PCI\VEN_1AF4&DEV_1110`) — no third party — built through the same VS
pipeline as VDD/VAD and MS-attestation-signed.
- **VMM**: a vendored **QEMU 11.0.1 fork** with `ivshmem-plain` (`vendor/qemu-ivshmem`),
embedded self-contained in the app bundle (codesigned with the Hypervisor entitlement), with
the LGPL source mirror for compliance. This is the bulk of the diff (vendored upstream).
- **Disk build / provisioning**: a from-scratch ISO→NTFS disk builder (`tools/iso-patch-mac`)
applies the install image and stages the payload + answer file. `unattend.xml` / `setup.cmd`
/ `SetupComplete.cmd` are generated by the **shared** `tools/provision/win_provision.c` used
by both the Windows backend and the Mac host — one generator, no platform fork.
## Guest payload
The Mac host **JIT-downloads** the signed Windows release zip (EV-signed agent EXEs +
**MS-attestation-signed** drivers, incl. AppSandboxSHM), caches it, and pulls the WHQL-signed
**NetKVM** virtio-net driver from a vendored zip (`vendor/virtio-win`). No test-signed Windows
binaries ship in the app bundle.
## Credentials
- The account credential is **obfuscated/hashed in the daemon** for all configs — the
disk-applier child only ever receives the non-plaintext result, so the plaintext never
crosses the process boundary. Win-on-Mac generates the base64 `unattend.xml` in-process;
macOS guests get a salted PBKDF2-SHA512 ShadowHash + kcpassword computed in-process
(`tools/provision/mac_account_hash.{h,m}`).
- **Non-ASCII (incl. CJK) credentials** are handled correctly: the unattend `<Password>` is
encoded as true UTF-16LE and the headless SDK's JSON `\uXXXX` escapes are decoded. Verified
with a 12-character mixed Chinese/English password (`ValidateCredentials` on Windows,
`dscl -authonly` on macOS).
## Testing
- Full **2× Windows-11 concurrent lifecycle suite green** (4 GB / 4 cores / 64 GB each):
create → disk build → boot-to-online → SSH key auto-deploy → display open/close →
edit-while-stopped → shutdown/restart → delete; snapshots correctly return `501` on macOS.
- Guests reach agent-online with the attestation-signed drivers under Secure Boot.
- CJK password authenticated inside both Windows and macOS guests.
## Deploy note
The signed-payload URL points at the **v0.1.4 release** — that release must be published, or a
Windows-on-Mac create fails with "Signed Windows guest payload download failed".
win2ntfs.c was the standalone harness that validated the WIM->NTFS apply;
that logic now lives (with real per-file SIDs) in win_disk.c. AppSandboxSHM_producer.c
was the ivshmem bring-up bandwidth POC whose host-side reader (shm-test) is gone;
the production data path is asb_transport over the AppSandboxSHM driver. Neither
file was compiled by any target or included anywhere.
build-arm64.cmd and deploy-arm64.cmd were manual dev-VM helpers (cl build
of the guest binaries + hand-copy to C:\Windows\AppSandbox); the production
pipeline builds via msbuild on AppSandbox.sln and never referenced them.
- Delete the TODO/ planning + runbook docs, and fix the four code/README comments
that pointed at them (asb_transport.c/.h; the tools/ivshmem and vendor/qemu-ivshmem
READMEs now point at the vendored QEMU directly).
- THIRD-PARTY-NOTICES.md: add the bundled QEMU stack (QEMU GPL-2.0; GLib +
gettext/libintl LGPL-2.1; PCRE2 BSD; EDK2/TianoCore BSD-2-Clause-Patent) and
NetKVM (BSD-3) -- shipped/staged by the app but previously absent from the
top-level notices. The QEMU entry cross-references the bundled
vendor/qemu-ivshmem/LICENSES/NOTICE.md + WRITTEN_OFFER.txt. A usage audit
confirmed every listed dependency is still in use, so nothing was removed.
Post-review fixes and release prep for the win-on-mac feature.
* asb_shm_layout.h: fix a region-sizing bug -- the AGENT (ch1) slot stride
(0x20070) exceeded ASB_AGENT_REGION_SIZE (0x20000) by 112 bytes, so the agent
host->guest ring overran into the adjacent SSH (ch7) region and corrupted its
slot state under sustained traffic. Enlarge the AGENT region to 0x21000
(downstream offsets cascade) and add per-region compile-time guards
(n_slots*stride <= region_size) so this class of overlap fails the build.
Host/publisher-side only -- the guest reads geometry from the published directory.
* headless.m: GET /display readiness now includes idd_ready for a Windows guest,
matching the open precondition (asb_core_mac.m) and the Windows host
(asb_vm_idd_ready). Before, the Mac readiness was running && agent_online only,
so it could report ready before the VDD was up and a poll-then-open would
spuriously 409 display_not_ready. macOS guests are unchanged.
* iso-patch-mac.m (stage): wipe the plaintext password buffer on the
--shadowhash-file read-failure path, matching the sibling --kcpassword-file path.
* iso_patch_mac.m: point the signed Windows guest payload at the v0.1.4 release.
* vm_lifecycle.py: raise the Windows build-stall budget to 3600 s for the
signal-less first-boot window under concurrent multi-VM load.
* tools/headless-api/README.md: document Windows guests on macOS hosts (platform
matrix, host-fixed line, requirements heading, osType field).
Update ensureSignedWinPayloadZipCached to the new GitHub attachment URL and embed
the attachment id in the cached filename, so changing the URL at the same app
version auto-invalidates the cache instead of serving the stale cached zip.
ensure_vdd_running() detected a disabled AppSandboxVDD and ran `devcon restart`,
which reports success but cannot clear CONFIGFLAG_DISABLED on a device in
CM_PROB_DISABLED -- so the device snapped straight back to disabled and the agent
looped forever (detect disabled -> restart -> still disabled, every 20s). Only
`devcon enable` (DICS_ENABLE) clears the explicit-disable bit.
Now: ENABLE a disabled device; keep RESTART for a stuck-but-enabled ("problem") one.
All three guest configs now obfuscate/hash the account credential in the daemon
and hand the disk-applier child only the non-plaintext result -- the plaintext
never crosses the process boundary, mirroring the Windows-on-Windows model.
* Win-on-Mac: the daemon generates unattend.xml / setup.cmd / SetupComplete.cmd
in-process via the shared asb_provision_* (base64 of UTF-16LE(pass+"Password"),
the same encoder the Windows backend uses) and passes build-windows only
--prov-dir; the plaintext --pass argv is gone. The child still detects the
install.wim language and reports LANG:, and the daemon re-generates unattend.xml
in-process with the detected tag -- the exact mirror of vhdx_create_thread.
* Mac-on-Mac: the salted PBKDF2-SHA512 ShadowHash + kcpassword are computed in
the daemon via the new shared tools/provision/mac_account_hash.{h,m}; the stage
child takes --shadowhash-file / --kcpassword-file. --user-password-file remains
a direct-CLI fallback.
* Verified end-to-end on live Windows + macOS guests with a 12-character mixed
Chinese/English password (ValidateCredentials / dscl -authonly), exercising the
UTF-16 surrogate path.
Also in this checkpoint of accumulated win-on-mac work:
* agent: report_idd_status re-runs on the device-check loop (force-on-connect +
on-change) so display readiness tracks the live, self-healed VDD state instead
of a single one-shot sample.
* disk builder (tools/iso-patch-mac/engine): WIM reader gains the install-image
default-language reader behind the language auto-detect; win_disk locale/apply
refinements.
* display + transport: idd_display Metal render + clipboard-reader paths;
asb_ivshmem_transport slot-reclaim hardening.
* housekeeping: remove the dev-only transport test harness (tools/transport/test/*);
update headless-api test scripts; drop changelog-style comments.
James Stringer