Real Windows, without the VM ceremony

Instant disposable
Windows environments.

Run real Windows commands, builds, tests and desktop apps locally. Every run starts clean. No VM to manage. No remote Windows machine. No waiting for a desktop to boot.

Get WinQuick View source

~/project

$ winquick run -- cmd /c ver

Microsoft Windows [Version 10.0.26100.8972]

real Windows kernel~280 msdiscarded after run

~280 mstrivial Windows command

~350 msWindows desktop session

< 1 GBminimal base runtime

0VMs to babysit

CMDPowerShell 7.NET 10WPFWinFormsUI AutomationArtifactsDisposableOffline by default

Windows as a development target

It should feel like running a process.
Not operating another computer.

WinQuick hides the virtualization layer and gives developers and coding agents a simple primitive: run this inside real Windows and return the result.

Real Windows

Not Wine. Not mocked APIs. Your command executes against a genuine Windows ARM64 kernel with native Windows filesystem, registry, process and API behaviour.

winquick run -- your-command.exe

Disposable by default

Files, registry changes and environment mutations disappear after every run. The base environment stays pristine.

Built for iteration speed

A prepared Windows state restores in milliseconds. Fast enough to sit inside edit → test → fix loops without feeling like a VM.

Capabilities, not bloated images

Add only what a workload needs: PowerShell, .NET runtime, .NET SDK, desktop support and dependency caches remain modular.

Agent-native, CLI-first

Claude Code, Codex and other agents can use the same CLI humans use. No special VM API and no remote desktop orchestration required.

Build & test

Develop Windows software from your Mac.

Cross-build when it makes sense. Build inside Windows when it matters. Either way, WinQuick gives your tests the Windows kernel they actually need.

$ winquick run -w . -- dotnet test
Passed! 9 tests · 0 failed

$ winquick run -- pwsh -Command '$PSVersionTable.PSVersion'
7.6.5

$ winquick run -w . -a "bin/Release/**" -- dotnet publish -c Release
Artifacts → ./winquick-artifacts/

$ winquick run -w . -- dotnet test --filter Category=WindowsOnly
Failed! 1 test · the fix is verified before you push

$ winquick ui-test MyApp.csproj --script smoke.uitest --out ./shots
14 steps passed · screenshots → ./shots

Windows desktop, headless

Build it. Launch it. See it. Use it.

Automated testing of a Windows GUI normally needs a Windows machine with a logged-in desktop. WinQuick builds a WPF or WinForms application, runs it in a real Windows desktop and drives it through Microsoft UI Automation — the interface Windows' own accessibility tools use. Controls are addressed by AutomationId, so a test does not depend on pixel positions or window layout, and a selector matching two elements is an error rather than a guess. Nothing appears on your screen: no QEMU window, no RDP, no VNC.

A session is ready in about 350 ms. Launching an application takes a further ~27 ms and its first window appears about 660 ms later; UI Automation reads and clicks are ~20 ms, and a window screenshot ~59 ms. Preparing the desktop environment is a one-time ~17 seconds.

WQ Device Configuration

—□×

Device name

PLC-01

Mode

Standard ⌄

✓ Enable logging

Saved: PLC-01

SCREENSHOT winquick desktop screenshot app.png

SEMANTIC UI TREE winquick desktop tree --title "Device Configuration"

INTERACT winquick desktop click --automation-id SaveButton

VERIFY winquick desktop get --automation-id StatusText Saved: PLC-01

Real output

Every image below is a real run.

Captured by scripts/capture-screenshots.sh in the repository. The timings were measured while the image was being made, and the Windows pictures come from the guest's own framebuffer.

A WPF application in WinQuick with its text box, combo box and checkbox filled in by UI automation — A real WPF app, driven through Windows UI Automation — typed, selected, toggled, clicked.

Terminal showing five consecutive WinQuick runs at 365, 378, 341, 359 and 363 milliseconds — Five consecutive disposable environments, measured during capture.

Terminal showing a project copied into Windows and the host file SHA-256 unchanged afterwards — Your project is copied in. The guest writes to its copy; the original hash is unchanged.

Terminal showing the Windows guest has zero IPv4 adapters and cannot ping — Offline by default — the guest has no network adapter at all.

Terminal showing PowerShell 7 running inside a disposable Windows environment — PowerShell 7, as a capability you add when you want it.

A full Windows desktop running inside WinQuick with the demo application open — A real Windows desktop session, ready in about 350 ms once prepared.

Quick means quick

Windows in the loop.
Without breaking your flow.

WinQuick restores a prepared Windows environment instead of cold-booting a full workstation for every command. The result feels closer to a local tool than a virtual machine.

CMD ~280ms trivial warm command

.NET ~600ms dotnet --version, SDK capability

POWERSHELL ~920ms PowerShell 7 expression

BASE 763MiB minimal Windows runtime

Current measured Apple Silicon development results. Exact timings vary by machine, command and enabled capabilities.

For coding agents

Give your agent an actual Windows machine. For milliseconds.

An agent can often reason about a Windows bug from source. WinQuick lets it verify the fix against real Windows — including WPF and WinForms UI.

WinQuick is a native MCP server, so agents get structured tools rather than shell syntax: build and test on real Windows, launch a WPF or WinForms application, read and drive it through Microsoft UI Automation, and capture real Windows screenshots. Verified with Claude Code.

$ claude mcp add winquick -- winquick mcp

Edit→Run in Windows→Inspect→Fix→Verify

Claude Code

I'll verify this in Windows.

$ winquick run -w . -- dotnet test

Failed: PathTests.NormalizePath

The implementation assumes POSIX separators. Fixing it.

$ winquick run -w . -- dotnet test

Passed! 9 tests · 0 failed

One CLI. Any host.

Cross-platform by design.

Apple Silicon macOS is where WinQuick is developed, and where every figure on this page was measured. Linux and Windows run the same CLI on their own native accelerator. A Windows host boots the guest from scratch on every run, which costs about 17 seconds and is deliberate — a resumed guest there stalls on timers. On Linux the host side is verified, in that it builds, the tests pass and the diagnostics are correct, but a guest has not yet been booted on real Linux hardware.

macOSApple Silicon · HVF

◇Linuxx86_64 / arm64 · KVM

⊞Windowsx86_64 · WHPX · cold boot

Get started

From zero to real Windows
in two commands.

WinQuick handles the runtime setup and verifies it with a real Windows command before declaring it ready. Install it with Homebrew on any Apple Silicon Mac. The build is not signed or notarized, but Homebrew fetches the archive itself, so there is no Gatekeeper step.

Terminal

$ brew install carlbomsdata/tap/winquick

$ winquick setup

Windows runtime installed.
Testing the runtime...
Microsoft Windows [Version 10.0.26100.8972]

Ready.

WQ WinQuick

Real Windows.
Ready in milliseconds.

Get WinQuick on GitHub Open source · Apache-2.0

Instant disposableWindows environments.

It should feel like running a process.Not operating another computer.