James Stringer
4e08453b4a
Why this is needed AppSandbox Windows GPU-PV guests had no working hardware OpenGL. The previous approach — Microsoft's OpenGLOn12 ICD selected via the appsandbox_gl_shim.dll AppInit_DLLs shim — cannot work in the shipping configuration: AppInit_DLLs is disabled when Secure Boot is on (Microsoft-documented, Windows 8+), and release VMs run with Secure Boot on. So the shim never loads, the UMOPENGLINFO ICD rewrite never happens, and OpenGL silently falls back to GDI Generic 1.1 — on x64 as well as ARM64. (Any "it worked on x64" was a test_mode/Secure-Boot-off build.) Even when the shim does load, Microsoft's opengl32 refuses to bring up a hardware ICD across the GPU-PV render-only / display-only adapter split: it loads OpenGLOn12, validates it, hands it the callbacks, then abandons it before enumerating pixel formats — so apps still land on GDI Generic. (Proven with an interposing ICD that logs every Drv* call; it fails on both the IddCx desktop and the Hyper-V Video display, so it is the render/display split, not an "indirect display" quirk.) Vulkan (Dozen) and OpenCL (OpenCLOn12) were unaffected because they are registered as registry ICDs — no AppInit, no opengl32 gate. Net effect: OpenGL was broken for guest apps (e.g. Blender refused to start: "A driver with support for OpenGL 4.3 or higher is required."). The fix Ship Mesa's standalone opengl32.dll (gallium d3d12 driver + WGL frontend) system-wide into the guest's System32, so Microsoft's broken opengl32 is out of the path entirely. Mesa's WGL frontend creates its own D3D12 device (first DXGI adapter = the projected render GPU, or WARP if none) and presents via a windowed flip-model swapchain that DWM composites cross-adapter — the same bridge Vulkan/D3D12 already use. Result: Hardware OpenGL 4.6 via D3D12 when a GPU is present (GL_RENDERER: D3D12 (<gpu>), GL_VERSION: 4.6). WARP software GL 4.6 with no GPU — far better than the old GDI-Generic 1.1 fallback, and it means replacing the system opengl32 never makes an app worse. Works with Secure Boot ON — plain DLL loading, not AppInit_DLLs. Not a performance regression: OpenGLOn12 is the same Mesa gallium d3d12 driver. This is the identical renderer with a working entry path (a full gl*/wgl* DLL instead of the Drv* ICD Microsoft's opengl32 won't drive). What this PR does tools/win-mesa-gl/ — vendors the prebuilt Mesa trio (opengl32.dll + gallium_wgl.dll + z-1.dll) for x64 and arm64 (Mesa 26.1.2, static CRT, EV-signed), plus build-mesa.cmd, aarch64-cross.txt, sign-mesa.ps1, and a README. Mirrors tools/linux/wsl-mesa/ (same upstream Mesa; only the build target/options differ). AppSandbox.vcxproj — stages the build's-arch trio into resources\win-mesa-gl\ per-config (alongside the existing WebView2Loader copy). src/backend_win/asb_core.c — prepare_gl_layers_share() stages the trio into the AppSandbox.GlLayers Plan 9 share. tools/agent/agent.c — gl_provision() deploys the trio into the guest's System32 (take ownership, rename the in-use opengl32 aside, copy ours in; re-applied every boot so it self-heals if servicing/SFC restores Microsoft's), and keeps the dxil.dll staging + Khronos OpenCL/Vulkan ICD registrations. Removes the appsandbox_gl_shim project (AppSandbox.sln, tools/gl-shim/). .gitignore un-ignores the vendored binaries; SIGNING.md notes the trio is pre-signed (the build skips re-signing already-EV-signed files). OpenCL, Vulkan, and dxil.dll are unchanged. Verification Builds clean on Release|x64 and Release|ARM64. In-guest: GL_RENDERER: D3D12 (<gpu>), GL_VERSION: 4.6 (hardware), or D3D12 (Microsoft Basic Render Driver) 4.6 (WARP, no GPU) — including on a Secure-Boot-ON VM, which the old shim could never satisfy. Known limitation On ARM64 the deployed opengl32 is pure-ARM64, so x64 apps emulated on ARM64 (which load opengl32 from System32 via ARM64X) are not served — that would need an ARM64X Mesa build (future work). Native ARM64 apps and all x64-on-x64 apps are covered.
App Sandbox
App Sandbox is a virtual machine app for Windows and macOS that's focused on performance and ease of use.
Windows features:
- Works on Windows 11 Home or Pro, without Hyper-V
- Windows 11 or Ubuntu 26.04 LTS VM Support
- Zero touch install
- Copy and Paste
- 2 Channel Audio
- GPU Acceleration via Paravirtualization (GPU-PV) with support for DirectX 12 (Windows only), OpenGL, Vulkan, CUDA, OpenCL
- GPU Hardware Video Decoder/Encoder support
- SSH via Hyper-V socket proxy (no network required)
- Snapshots
- Fixed 1080P60 display
- Host to client hot-key support
- Provision and boot with / without internet
- Supports running Claude Cowork and Docker inside the VM thanks to Nested Virtualization Support
Mac features:
- macOS VM support
- Skips most of the install setup process
- Copy and Paste
- 2 Channel Audio
- GPU Acceleration via Paravirtualization with support for Metal
- SSH via virtio-vsock (no network required)
- Dynamic display sizing
- Provision and boot with / without internet
Requirements: Windows 11 with an x64 Processor or macOS Tahoe (M Series)
About App Sandbox
App Sandbox creates and runs full desktop virtual machines — Windows 11, Ubuntu, and macOS. It is free, open-source (MIT), and distributed as prebuilt, signed releases on its Releases page. It is operated from a graphical UI: pick an OS, point it at an installer image, and App Sandbox provisions the disk, runs an unattended install, and boots the guest. You supply a Windows or Ubuntu ISO; macOS guests download their restore image automatically. It runs on a Windows 11 (x64) PC or an Apple Silicon Mac, including laptops.
Runs on Windows 11 Home, without Hyper-V. On Windows, App Sandbox does not use Hyper-V or Hyper-V Manager; it creates and runs VMs through the Windows Host Compute System (HCS) and Host Compute Network (HCN) APIs, which require only the Virtual Machine Platform feature. Hyper-V is limited to Windows 11 Pro and Enterprise, while Virtual Machine Platform is available on Windows 11 Home, so a Windows 11 Pro license is not required. Virtual Machine Platform is the same Windows feature WSL2 uses.
What you can use it for:
- A fresh Windows or Ubuntu VM for building and testing your own software on a clean OS install.
- Running a program in a VM, kept separate from your main OS and files.
- Developing and testing Windows drivers: a built-in Test Mode enables test-signing inside the guest, so the host's Secure Boot and boot configuration are left unchanged.
- Running a computer-use AI agent (such as Claude's computer use model) in its own VM, so it has a desktop to work in without taking over your own. Several agents can run at once, each in its own VM, on a single laptop or desktop.
- Creating GPU-accelerated (GPU-PV) VMs from a native-app GUI.
How it works: this repo also aims to be a working example of creating full desktop VMs
programmatically with the Windows HCS/HCN APIs and Apple's Virtualization.framework. On
Windows, App Sandbox submits a hand-built HCS machine document to computecore.dll /
computenetwork.dll — the HCS/HCN layer that also underlies WSL2 and Windows Sandbox —
rather than going through Hyper-V Manager. GPU acceleration uses GPU paravirtualization
(GPU-PV) to share the host GPU with the guest, with DirectX 12, OpenGL, Vulkan, CUDA, and
OpenCL on Windows and Metal on macOS. A custom IddCx indirect display driver and a
virtual audio device carry the screen and sound, and guest↔host clipboard, audio, input,
and SSH run over Hyper-V sockets. Guest disks are built by an in-repo tool with support
for ext4, squashfs, qcow2, and VHDX. On macOS, App Sandbox uses Apple's
Virtualization.framework (VZVirtualMachine, VZMacOSInstaller) over
virtio-vsock. On Windows, Linux (Ubuntu) guests reach the GPU through a custom DRM/KMS
kernel module (asb_drm), Microsoft's WSL2 dxgkrnl, and a custom Mesa build. The apps
are native C / Objective-C with an HTML/JS UI (WebView2 on Windows, WKWebView on macOS).
Tips:
[Windows] Enable hotkeys or mute the VM audio: connect to the VM and right-click the connection title bar
[Windows] Need a high performance remote desktop to remotely access your VM? Phaze works well
[Windows] You can check if the GPU-PV driver setup is working by running gpu-test.exe inside your App Sandbox Windows VM, gpu-test.exe will show a box with 6 rotating cubes, each using a different rendering engine (D3D9, D3D10, D3D11, D3D12, OpenGL and Vulkan). If one or more fail, they will not correctly show a rotating cube for that rendering API. gpu-test.zip. Note: The rendering API succeeding means that the GPU-PV worked, but sometimes games or apps are coded in such a way that they will not detect the GPU-PV system correctly and still show an error.
License
AppSandbox is licensed under the MIT License — Copyright (c) 2026 James Stringer.
It bundles third-party components that are not covered by the MIT license and
retain their own terms — most notably the Microsoft WSL2 dxgkrnl GPU driver
(GPL-2.0) and the embedded XZ decoder (0BSD). See
THIRD-PARTY-NOTICES.md for the full list. AppSandbox's
own Linux DRM kernel module (tools/linux/asb_drm/) is dual-licensed MIT OR
GPL-2.0 so it can resolve the kernel's GPL-only symbols.
Acknowledgements
Beyond my own experience building Easy-GPU-PV, I found NanaBox to be a really helpful resource for understanding HCS.
Author
James Stringer — author of Easy-GPU-PV.