jamesstringer90/appsandboxCrea facilmente macchine virtuali complete, in sandbox, per lo sviluppo o per modelli di utilizzo del computer.
App Sandbox è un'app per macchine virtuali per Windows e macOS, focalizzata su prestazioni e facilità d'uso.
Funzionalità Windows:
asb.py) per creare e gestire VM con accelerazione GPU a livello di codiceFunzionalità Mac:
asb.py) di Windows, per gestire VM macOS e Windows 11 a livello di codiceRequisiti: Windows 11 con processore x64 o macOS Tahoe (serie M)
App Sandbox crea ed esegue macchine virtuali desktop complete — Windows 11, Ubuntu e
macOS. È gratuito e open-source (MIT), distribuito come binari precompilati (firmati EV su
Windows, firmati Apple Developer su macOS) nella sua
pagina delle Release. Può essere guidato in due
modi: da un'interfaccia grafica, oppure a livello di codice tramite un daemon headless con un
SDK Python senza dipendenze (asb.py). In entrambi i casi si sceglie un sistema operativo, lo si punta a un'immagine
di installazione e App Sandbox esegue il provisioning del disco, avvia un'installazione non presidiata e avvia il
guest. Si fornisce un ISO di Windows o Ubuntu; i guest macOS scaricano automaticamente la loro immagine di
ripristino. Funziona su un PC Windows 11 (x64) o su un Mac Apple Silicon, inclusi i laptop.
Funziona su Windows 11 Home, senza Hyper-V. Su Windows, App Sandbox non usa Hyper-V né Hyper-V Manager; crea ed esegue VM tramite le API Windows Host Compute System (HCS) e Host Compute Network (HCN), che richiedono solo la funzionalità Virtual Machine Platform. Hyper-V è limitato a Windows 11 Pro ed Enterprise, mentre Virtual Machine Platform è disponibile su Windows 11 Home, quindi non è richiesta una licenza Windows 11 Pro. Virtual Machine Platform è la stessa funzionalità di Windows usata da WSL2.
A cosa puoi usarlo:
API headless.
appsandbox.exe --headless
(oppure sudo /Appsandbox.app/Contents/MacOS/AppSandbox --headless su macOS) avvia un
daemon a proprietario singolo che ospita lo stesso core della GUI e lo espone come API
HTTP/JSON locale in stile Docker su 127.0.0.1, identica su entrambe le piattaforme. L'SDK Python
di sola stdlib (asb.py) lo avvolge: crea VM con accelerazione GPU (GPU-PV è un'opzione di creazione gpuMode), SSH
tramite una chiave distribuita automaticamente (guest Windows, Ubuntu o macOS), crea snapshot e rami,
apre il display live ed esegue più VM contemporaneamente — quante ne girano in parallelo è limitato da CPU,
RAM e memoria GPU dell'host, non da un limite fisso. Il daemon è single-host — gestisce VM sulla
macchina su cui è in esecuzione e non esegue il provisioning di VM cloud; per la CI, eseguilo su un runner
self-hosted. Il provisioning di una VM esegue un'installazione non presidiata completa; snapshot, rami e modelli
(solo Windows) avviano una nuova VM da uno stato provisionato invece di reinstallare. Una VM persiste
finché non viene eliminata. Uno snapshot è un checkpoint dello stato del disco acquisito a VM spenta; un ramo
crea da esso un disco scrivibile per eseguire azioni divergenti. Il riferimento completo all'API e gli esempi
eseguibili sono in tools/headless-api/.
Come funziona: questa repo vuole anche essere un esempio funzionante di creazione di VM desktop complete
a livello di codice con le API Windows HCS/HCN e il Virtualization.framework di Apple. Su
Windows, App Sandbox invia un documento macchina HCS costruito a mano a computecore.dll /
computenetwork.dll — il livello HCS/HCN che è alla base anche di WSL2 e Windows Sandbox —
invece di passare da Hyper-V Manager. L'accelerazione GPU usa la paravirtualizzazione GPU
(GPU-PV) per condividere la GPU installata sull'host con il guest — lo stesso percorso di WSL2, non un
passthrough dedicato (niente VFIO/IOMMU, niente seconda GPU). I guest Windows ricevono DirectX 12, OpenGL,
Vulkan, CUDA e OpenCL; i guest Ubuntu gli stessi meno DirectX; i guest macOS Metal. Un driver
IddCx display indiretto personalizzato e un dispositivo audio virtuale trasportano schermo e suono, e
clipboard guest↔host, audio, input e SSH viaggiano su Hyper-V sockets. I dischi guest sono
creati da uno strumento nella repo con supporto per ext4, squashfs, qcow2 e VHDX. Su macOS, App
Sandbox usa il Virtualization.framework di Apple (VZVirtualMachine, VZMacOSInstaller)
su virtio-vsock. Su Windows, i guest Linux (Ubuntu) raggiungono la GPU tramite un modulo
kernel DRM/KMS personalizzato (asb_drm), il dxgkrnl WSL2 di Microsoft e una build Mesa personalizzata. Le
app sono C / Objective-C native con UI HTML/JS (WebView2 su Windows, WKWebView su macOS).
[Windows] Abilita le hotkey o silenzia l'audio della VM: connettiti alla VM e fai clic con il tasto destro sulla barra del titolo della connessione
[Windows] Ti serve un desktop remoto ad alte prestazioni per accedere da remoto alla tua VM? Phaze funziona bene
[Windows] Puoi verificare se la configurazione del driver GPU-PV funziona eseguendo gpu-test.exe all'interno della tua VM Windows di App Sandbox; gpu-test.exe mostrerà una finestra con 6 cubi rotanti, ciascuno usando un motore di rendering diverso (D3D9, D3D10, D3D11, D3D12, OpenGL e Vulkan). Se uno o più falliscono, non mostreranno correttamente un cubo rotante per quell'API di rendering. gpu-test.zip. Nota: il successo dell'API di rendering significa che GPU-PV ha funzionato, ma a volte giochi o app sono codificati in modo tale da non rilevare correttamente il sistema GPU-PV e mostrano comunque un errore.
AppSandbox è concesso in licenza sotto la Licenza MIT — Copyright (c) 2026 James Stringer.
Include componenti di terze parti che non sono coperti dalla licenza MIT e
mantengono i propri termini — in particolare il driver GPU dxgkrnl WSL2 di Microsoft
(GPL-2.0) e il decoder XZ integrato (0BSD). Consulta
THIRD-PARTY-NOTICES.md per l'elenco completo. Il modulo
kernel Linux DRM di AppSandbox (tools/linux/asb_drm/) è con doppia licenza MIT OR
GPL-2.0, così può risolvere i simboli GPL-only del kernel.
Oltre alla mia esperienza nella creazione di Easy-GPU-PV, ho trovato NanaBox una risorsa davvero utile per comprendere HCS.
James Stringer — autore di Easy-GPU-PV.