Windows Subsystem for Windows

[ohault]

Here is how ChatGPT-5 can define what would be a “Windows Subsystem for Windows” (WSW).

I would be interested in exploring this with others folks.

WSW would leverage existing key concepts and patterns of WSL2 (lightweight utility VM, distro images, tight host integration) but is designed to host alternate/isolated Windows userlands (for app compatibility testing, sandboxes, different Windows builds, developer workflows, secure execution, etc.).

The goal is not to replace the host Windows kernel but to provide isolated Windows user-mode environments running inside a lightweight VM with strong host/VM integration (fast startup, file sharing, interop). The spec covers components, data flows, APIs, security, performance, and operations.

1 — High-level goals
• Provide lightweight, fast, well-integrated Windows user-mode environments (guest Windows userland) on top of a Windows host.
• Reuse WSL2 design patterns: a small optimized utility VM per environment family, distribution-style installable images, host-side management service, fast host ↔ guest integration.
• Enable running Win32/Win64 user-mode apps in isolation with minimal UX friction (start menu integration, file access, networking), while keeping strong isolation and secure defaults.
• Provide developer and admin controls: launch/stop/checkpoint/export/import, resource limits, debugging hooks.

2 — Key design patterns borrowed from WSL2
• Utility VM model: every WSW distribution runs inside a minimal Hyper-V utility VM (lightweight, configured for fast boot). The VM contains a small Windows kernel plus user-mode environment.
• Distro images: environments are packaged as distributable images (VHDX or compressed container image) that can be installed/uninstalled by the host tooling.
• Host-side manager: a persistent privileged service on the host manages images, VMs, lifecycle, mounts, and integration points (analogous to LxssManager/wslservice).
• Filesystem passthrough + sharing: a fast host↔guest filesystem protocol (similar role to 9P in WSL2) to share host files with guest and expose guest files to the host.
• Inter-process and network interop: transparent, low-latency networking and IPC plumbing to let host and guest apps communicate smoothly.
• CLI + API: single command-line tool + PowerShell module to manage environments (start, exec, config, export).

3 — Components

3.1 Host components
• WSW Host Service (wswhostsvc) — privileged Windows service (runs in SYSTEM). Responsibilities:
• Manage registered WSW distributions (images metadata, versioning).
• Create and manage utility VMs (Hyper-V Lightweight VMs).
• Provide IPC endpoints into the VM (vSockets / Hyper-V sockets).
• Manage filesystem sharing, resource controls, and startup arguments.
• Expose control APIs (COM/WMI/PowerShell/HTTP over loopback for local tools).
• Maintain security policy (signed images, capability mapping).
• WSW Command-line Tool (wsw.exe) — user CLI: install, run, exec, mount, export, set-default, configure-resources. Also a small GUI integration helper.
• WSW PowerShell Module / Management API — for automation and enterprise management.
• Integration Agent (host-side) — small helper that handles Start Menu / shell integration, file association handlers, and UX integration (e.g., right-click “Open in WSW distro”).

3.2 VM / Guest components
• Utility VM — Hyper-V based VM optimized for minimal footprint:
• Minimal Windows kernel + user-mode support.
• Lightweight device drivers required for VMBus/vSocket/virtio-like devices.
• VHDX/overlay disks for distro rootfs and writable layer.
• WSW Guest Agent (inside VM) — runs in the guest to:
• Handle incoming exec requests (spawn processes inside guest).
• Expose a filesystem server for host↔guest sharing (over a fast protocol).
• Provide an authentication endpoint for seamless credential passing.
• Provide a RemoteApp-like window sharing service so guest GUI apps can be shown on host desktop (or use RDP/RemoteApp).
• Monitor resource usage and report health/status to host service.
• Distro Root Image — read-only base image containing Windows user-mode binaries and runtime (one or more variants like “Windows 10 compat userland”, “Windows 11 trimmed userland”, developer images).
• Writable Layer — per-distro writable VHDX overlay for user changes, installed apps, registry hives.

3.3 Integration protocols
• Control channel — host ↔ guest control via Hyper-V sockets (Vsock) for commands, health, logs, exec requests.
• Filesystem share protocol — fast remote filesystem protocol (conceptually like 9P or SMB but optimized for small RPCs and metadata; we’ll call it WSWFS). It supports:
• Host-mounted paths inside the guest (e.g., C:\host\Users\me\project).
• Guest-exposed VHDX accessible from host (for tools that need raw access).
• Caching and metadata sync options (write-through, write-back).
• Network bridging / NAT — options: NAT mode (default) for isolation, or bridged/shared network to let guest apps appear on same subnet. Support for port-forwarding from host to guest.
• GUI transport — RDP / RemoteApp style protocol or a custom XRDP-like transport that supports individual windows exported to host shell (so guest GUI apps can appear alongside native apps).
• IPC bridging — named pipes bridging via vsock proxy; a policy-controlled relay of Windows named-pipes between host and guest when requested.

4 — Basic lifecycle and flows

4.1 Install a WSW distro
1. User downloads a WSW distro bundle (VHDX root + metadata).
2. wsw.exe --import mydistro .\mydistro.bundle registers distro with host service and stores images under %LOCALAPPDATA%\WSW.
3. Host service sets up a VM configuration (hardware profile, memory, CPU, devices).
4. VM remains stopped until user starts it (lazy start).

4.2 Launch an application from host into the distro
1. User runs wsw.exe -d mydistro -- run "C:\Program Files\App\app.exe" args… or double-click file association associated to distro.
2. Host service ensures distro VM is running; if not, starts it quickly (fast resume, via checkpointing, memory preallocation).
3. Host sends exec request over control channel to Guest Agent.
4. Guest Agent spawns process in guest, with pipes for stdin/stdout/stderr tunneled back to the host if requested.
5. If GUI, the Guest Agent exposes the window through the GUI transport to the host shell (seamless window / remoteapp).
6. File system mounts are made available to guest per user config (e.g., host project folder mounted inside guest).
7. Networking is available as configured.

4.3 Accessing host files from guest
• Host’s user directories can be mounted into guest via WSWFS. The default is mount of %USERPROFILE% read/write with permission mapping.
• Optionally expose additional host drives or network shares.

5 — Security & sandboxing

5.1 Isolation boundary
• The VM acts as the principal isolation boundary. No code running in the WSW guest can directly access host kernel memory or kernel-mode devices.
• Hyper-V virtualization features enforce separation; device access is mediated.

5.2 Minimal privileges by default
• VMs run without admin privileges mapped to the host; by default, host-side file mounts are presented with least privileges necessary.
• Named-pipe or registry bridging are opt-in and audited.

5.3 Signed image and integrity
• Distro images can be signed and validated by host service before import.
• Support for image attestation and SHA256 manifests.
• Optionally enforce Secure Boot for utility VM (if host supports and policy requires).

5.4 Capability model / policy
• Each distro has a capability manifest: allowed host mounts, allowed device passthrough (USB, GPU), network policy, allowed host IPC bridges.
• Admins and enterprise policies can lock down capabilities.

5.5 Device access
• Default: no direct hardware passthrough.
• Optional: controlled passthrough for GPU (vGPU, DDA), USB (through a proxy driver), or audio with explicit consent.

6 — Compatibility & limitations
• Designed to run user-mode Windows applications built for the guest Windows version. Kernel-mode drivers from guest are unsupported unless explicitly provided through approved passthrough mechanisms (drivers in guest do not get host kernel access).
• Some hardware-dependent features, licensing restrictions, DRM/anti-cheat or kernel-mode anti-cheat will be limited or unavailable.
• Performance-sensitive workloads may experience overhead from virtualization (I/O heavy apps need tuned file-share modes or host-native access).

7 — Filesystem design details

7.1 Root image + writable overlay
• Read-only root image (VHDX) with OS binaries; writable overlay per registered distro.
• Allows multiple copies to share the same base image (efficient storage).

7.2 Host filesystem mounts
• WSWFS presents host directories inside guest. Modes:
• Passthrough (direct) — low-level mapping exposing host NTFS semantics; best for performance but requires security mapping.
• Cached — metadata caching in guest for faster access; write-back or write-through configurable.
• Mirrored — two-way sync (for cases where guest and host tools both need local filesystem semantics).

7.3 Special paths
• Windows host paths should be visible in a canonical location inside the guest (e.g., C:\host<user>\…) with transparent path translation tools.

8 — Networking & IPC

8.1 Network modes
• Isolated NAT (default): VM sits on an internal NAT network. Easy but NATs host/guest IPs.
• Bridged: VM gets an IP on host network (requires admin).
• Port forwarding: host can forward specific ports into guest to expose services.

8.2 Host<>Guest IPC
• Vsock control channel: control commands, health checks.
• Pipe relays: host-side proxy exposes named pipes to guest as required.
• Loopback transports for localhost-style interop: optionally map guest localhost:port to host localhost:port for simple development workflows.

9 — GUI support (seamless apps)
• GUI apps in the guest can be displayed on host via:
• RemoteApp-like protocol: Guest Agent captures per-window content and communicates via an RDP/RemoteApp session; host integrates windows into local shell.
• RDP server inside guest: host uses virtual channel to render windows and redirect input.
• Support clipboard sharing, drag-and-drop (policy-controlled), and audio redirection.

10 — Resource management & performance optimizations

10.1 Resource control
• Per-distro CPU shares, memory limits and caps, disk IOPS caps.
• Memory ballooning (host can reclaim unused VM RAM).
• Quick resume via hypervisor checkpoints / saved state (fast startup like WSL2).

10.2 I/O tuning
• For small metadata operations (lots of small file operations), use cached mount mode inside guest or keep source files in guest overlay to avoid cross-VM round-trips.
• Option to keep project folders inside the guest overlay for heavy-build workloads; provide “sync to host” command.

10.3 Latency & startup
• Keep utility VM minimal to reduce boot time.
• Use a suspended checkpoint to resume quickly on first exec.
• Keep small resident helper processes to avoid full cold boots.

11 — Developer & admin UX

11.1 CLI
• wsw.exe commands:
• wsw --install image wsw --import wsw --uninstall
• wsw -d name --exec cmdline
• wsw -d name --run-gui "C:\path\app.exe"
• wsw --export name path
• wsw --snapshot name snapshotname / --restore snapshotname
• wsw --set-resources name --memory 4GB --cpus 2
• wsw --mount-host C:\dev --to C:\host\dev --mode passthrough

11.2 PowerShell module
• Full automation for enterprise: create/destroy, configure policies, bulk install.

11.3 Integration points
• Host shell extension: context menu “Open in WSW ”.
• Installer hooks to register app shortcuts so guest apps show in host Start Menu (managed entries with provenance info).
• Integrated debugging: host debugger proxies into guest processes.

12 — Update, images, and lifecycle management
• Image distribution: signed compressed bundles (manifest + VHDX).
• OS updates inside guest: handled by the guest agent or Windows Update in guest. Host admin can set policies to auto-update or freeze distro versions.
• Image versioning: host may keep multiple image versions for test/rollback.
• Snapshot & checkpoint: quick checkpointing for fast rollback/testing.
• Export/import: full distro export (VHDX + overlay) for backups or sharing.

13 — Monitoring, diagnostics, telemetry
• Host service collects health metrics (VM uptime, resource use) and exposes logs for debugging.
• Guest agent exposes process lists, logs, and performance counters via control channel.
• Admins can turn on extended logging on demand.

14 — Extensibility and enterprise features
• Policy-based governance: Group Policy / MDM integration to restrict installs, mounts, hardware passthrough.
• Attestation: image attestation and signed manifests for approved enterprise distributions.
• Integration with containers and Hyper-V: ability to convert a WSW distro image into a VM template or container image; support for exporting to cloud VMs.
• Checkpoint-as-service: schedule snapshots for developer workflows.

15 — Example sequence diagrams (textual)

Starting an app (sequence)

Host shell → Host Service: launch request
Host Service → Hyper-V: ensure VM running (resume checkpoint)
Host Service → Guest Agent (vsock): exec request + mount config
Guest Agent → Process: spawn
Guest Agent → Host Service: process started, window handle info
Host Service → Host Shell: create host window host-side and stream window content via GUI transport

File access (heavy-build optimization)

Option A (default mount): Build touches many files → many cross-VM operations → slower.
Option B (fast path): Developer runs build inside guest overlay (files local in guest), then uses host wsw sync to publish artifacts to host folder.

16 — Risks and constraints
• Licensing: distributing Windows binaries requires proper licensing; enterprise and OEM agreements required.
• Kernel APIs: any driver-level functionality or kernel-mode integration cannot be provided seamlessly unless using specialized passthrough — may break anti-cheat/DRM expectations.
• Performance: some workloads (real-time, driver-heavy) will not match native performance.
• Complexity: mapping Win32 semantics and file semantics across host/guest can be subtle (file locking, ACL semantics).

17 — Roadmap (recommended phases)
1. MVP: minimal utility VM + guest agent, CLI to install and exec, host filesystem mounts, NAT networking, basic GUI via RDP.
2. Integration: Start Menu integration, Start/Stop, resource controls, snapshot/restore.
3. Optimization: performance tuning (file caching, fast resume), vsock improvements.
4. Enterprise: signed image support, Group Policy, attestation.
5. Advanced: GPU passthrough, advanced device proxies, named-pipe bridging, debugger integration.

18 — APIs & CLI (proposed interface sketch)
• wsw.exe import --name MyWinDistro --file mydistro.vhdx --memory 4GB --cpus 2
• wsw.exe run --name MyWinDistro --exe "C:\Tools\hello.exe" --gui
• wsw.exe mount --name MyWinDistro --host "C:\Users\alice\proj" --guest "C:\host\proj" --mode passthrough
• wsw.exe snapshot create --name MyWinDistro --out snap1
• PowerShell module with functions: Import-WSWDistro, Start-WSWDistro, Invoke-WSWCommand, Export-WSWDistro

19 — Non-functional requirements & success metrics
• Startup latency: cold start ≤ 5s, resume ≤ 200ms (target; depends on host hardware).
• Exec latency: host->guest spawn latency ≤ 20ms (for simple commands).
• File throughput: parity within 10–30% of native for large sequential reads (with optimized path).
• Isolation: no escalation paths from guest to host kernel; pass a security audit.
• Usability: guest GUI apps appear and integrate with host shell seamlessly; file system semantics are predictable.

20 — Closing notes / tradeoffs
• This design prioritizes developer experience and secure isolation over allowing kernel-mode features inside guest. That choice keeps host protected and enables safe multi-distro workflows but limits cases needing kernel drivers or low-level hardware access.
• Reusing WSL2 concepts (utility VM, image overlays, fast host↔guest protocols, host-side control service) gives a pragmatic path to an integrated Windows sandbox that feels native to users while remaining robust for enterprise scenarios.