WindoWriter

Create bootable Windows USB installers on macOS, Linux, and Windows — fast, verified, and scriptable.

WindoWriter takes a Windows 10/11 (or older) ISO and turns a USB stick into a UEFI-bootable installer. It is a modern, clean-room Swift rewrite of the idea behind tools like WinDiskWriter, built to fix the problems that plague them: apps that break on every new macOS release, silent write corruption discovered only at boot time, no ESD image support, no CLI, and multi-hour writes.

Platform	CLI	GUI	Backend
macOS 13+	✅	✅ SwiftUI	diskutil / hdiutil
Linux	✅ (needs root)	—	lsblk / parted / mkfs.vfat / loop mounts
Windows 10+	✅ (needs admin)	— (use the CLI)	PowerShell storage cmdlets / DISM

Highlights

• One engine, three platforms. The core (inspection, copying, splitting, verification, driver provisioning) is shared; only disk plumbing is per-OS, behind a small PlatformOperations protocol.
• Native Swift, current macOS. Swift + SwiftUI targeting macOS 13+, built for Apple Silicon and Intel. No ancient deployment targets, no AppKit archaeology — nothing to break when the next macOS ships.
• GUI and CLI. A clean one-window app on macOS, and a windowriter command for scripts, automation, and people who live in the terminal — on every platform.
• Post-write verification. After copying, every file is size-checked and boot-critical files (efi/, bootmgr, boot.wim) are SHA-256 verified against the ISO — optionally every file with --full-verify. A stick that passes will not silently fail to boot because of a corrupt EFI loader.
• ESD and pre-split images supported. install.esd ISOs (the common consumer download flavor) are re-exported and split automatically via wimlib; install.swm pre-split media passes straight through. install.wim over 4 GiB is split into FAT32-sized parts.
• Fail before formatting, not after. Every precondition — Windows layout, oversized files, wimlib availability, capacity — is checked before the drive is erased. WindoWriter will not leave you with a wiped stick and a half-written installer.
• Fast, buffered I/O. Files stream in 8 MiB chunks with live speed and ETA reporting.
• Hard safety rails. The engine refuses the boot disk unconditionally, refuses internal disks unless explicitly allowed, refuses partitions (whole disks only), and the CLI makes you type the disk name to confirm.
• ARM64 media aware. Detects x64 / x86 / ARM64 boot files and reports what the stick will boot.
• Fixes the "no drives found" installer problem. One toggle (--intel-rst) downloads Intel's RST/VMD storage driver and provisions it on the stick — both in $WinPEDriver$/ (WinPE loads it automatically at boot, no clicks needed) and in a visible folder for the manual Load driver → Browse flow. Custom .inf driver folders can be added the same way with --driver.

Requirements

• macOS: 13 Ventura or newer. For ISOs whose install image exceeds 4 GiB (most Windows 10/11 ISOs): wimlib — brew install wimlib
• Linux: a Swift 6 toolchain to build; parted, dosfstools and (for large images) wimtools at run time — apt install parted dosfstools wimtools. Writing needs sudo.
• Windows: a Swift for Windows toolchain to build. WIM splitting uses the built-in DISM — no extra installs. Writing needs an elevated prompt. (ESD-based ISOs additionally need wimlib.)

Install

Build from source

git clone https://github.com/<you>/WindoWriter.git
cd WindoWriter
swift build -c release            # CLI on any platform: .build/release/windowriter
make app                          # macOS only: builds dist/WindoWriter.app
make cli                          # macOS/Linux: installs /usr/local/bin/windowriter

Or grab the artifacts from the latest CI run / release (built for macOS, Linux, and Windows).

Usage

GUI

Open WindoWriter.app, drop in an ISO, pick the target drive, hit Write. The app shows the stage, live speed/ETA, and a log; it asks for confirmation before erasing anything.

CLI

# See candidate drives (external whole disks; the boot disk is never listed)
windowriter list

# Check what an ISO contains before writing
windowriter inspect ~/Downloads/Win11_24H2_English_x64.iso

# Write it — target naming is platform-native:
windowriter write Win11.iso disk4          # macOS
sudo windowriter write Win11.iso sdb       # Linux
windowriter write Win11.iso 2              # Windows (disk number; elevated prompt)

Write options:

Option	Effect
--scheme mbr|gpt	Partition scheme (default mbr, boots the widest range of machines)
--label NAME	FAT32 volume label (default WINUSB)
--no-verify / --full-verify	Skip verification, or checksum every file
--allow-internal	Permit internal (non-boot) disks
--no-eject	Keep the volume mounted afterwards
--intel-rst	Add Intel RST/VMD storage drivers (see below)
--driver PATH	Add a custom driver folder (.inf-based); repeatable
-y, --yes	Skip the confirmation prompt

The drive doesn't show up during Windows Setup?

On most Intel machines since 11th-gen Core, the NVMe SSD sits behind Intel VMD (Volume Management Device). Windows Setup has no in-box driver for it, so it shows an empty disk list ("We couldn't find any drives"). The usual advice — hunt down the Intel RST driver, extract it onto the USB, click Load driver during setup — is exactly what WindoWriter automates:

windowriter write Win11.iso disk4 --intel-rst

What happens under the hood:

1. Intel's official driver installers (SetupRST.exe, one per platform generation: 20.x for 12th–15th gen, 18.x for 10th–11th gen VMD, 17.x for 8th–9th gen SATA-RAID) are downloaded from intel.com at write time. Nothing is redistributed by this project — Intel's license forbids bundling but this download-at-run-time pattern is the established one (it is what Chocolatey's intel-rst-driver package does). The Intel Software License Agreement applies to the downloaded files.
2. The WHQL-signed driver files (iaStorVD.inf/.sys/.cat, …) are extracted — on Windows via Intel's documented SetupRST.exe -extractdrivers switch, on macOS/Linux by carving the embedded ZIP records out of the installer byte-exactly (CRC32-verified, signatures intact).
3. They land in $WinPEDriver$/<pack>/ on the USB root. Windows Setup scans that folder on every readable volume before the drive-selection screen, loads matching drivers automatically, and — unlike drivers loaded by hand — schedules them for injection into the installed OS too. Packages that don't match the machine's hardware are ignored harmlessly.
4. A visible copy goes to WindoWriterDrivers/<pack>/ for the manual Load driver → Browse route, in case you prefer it.

The alternative fix — switching the BIOS storage mode from VMD/RAID to AHCI — makes the drive appear too, but can break an existing Windows install on the same machine; carrying the driver on the USB is the safe route. For other exotic storage/RAID controllers, extract the vendor's .inf driver package and pass it with --driver /path/to/folder.

How a write works

1. Mount the ISO read-only and inspect it (layout, architectures, install image format/size).
2. Check every precondition — before touching the drive.
3. Erase the drive as a single FAT32 volume (MBR or GPT).
4. Stream-copy all files (excluding an oversized install image).
5. If needed: re-export install.esd → wim, then split into install.swm parts under 4 GiB.
6. Verify the result against the ISO.
7. Eject.

The result boots on any UEFI machine (that is, essentially everything since ~2012), including with Secure Boot, because it uses Microsoft's own boot files — no third-party bootloader is written.

Why not just dd the ISO?

Windows ISOs are not hybrid images the way Linux ISOs are — raw-writing one to USB does not produce a bootable stick. The files have to be laid onto a FAT32 filesystem that UEFI firmware can read, and the >4 GiB install.wim has to be split. That is exactly what WindoWriter automates.

Comparison with WinDiskWriter

WindoWriter shares zero code with WinDiskWriter (this is a clean-room implementation), but it exists because of real gaps reported by that project's users:

	WinDiskWriter	WindoWriter
Language	Objective-C, macOS 10.6 target	Swift / SwiftUI, macOS 13+
Breaks on new macOS releases	Frequently (top issue category)	Modern APIs, CI-built on latest macOS
CLI / scriptable	No	Yes
Post-write verification	No	Size + SHA-256, optional full
install.esd ISOs	Rejected	Converted & split automatically
Pre-split .swm media	Rejected	Supported
Fails after erasing your drive	Common failure mode	All checks run before formatting
ARM64 Windows media	No	Detected and written
Intel VMD/RST "no drives found" fix	No	One toggle, automatic
Runs on Linux / Windows	No (macOS only)	CLI on both
Legacy BIOS (pre-UEFI) boot	Yes (grub4dos)	Not yet (roadmap)
Win11 TPM/RAM bypass patching	Yes	Not yet (roadmap)

Roadmap

• Native GUIs for Linux and Windows (the CLI covers both today)
• Legacy BIOS boot support for pre-2012 machines
• Optional Windows 11 requirement-bypass patching (TPM / Secure Boot / RAM checks)
• Bundled wimlib so no Homebrew dependency is needed
• Signed & notarized releases and a Homebrew cask
• exFAT + UEFI:NTFS path to avoid splitting entirely

Contributing

Issues and PRs welcome. Run the test suite with swift test; the core engine (Sources/WindoWriterCore) is a plain library with no UI dependencies, so most logic is unit-testable.

Disclaimer

WindoWriter erases disks. It has multiple safety rails, but you are the last one: double-check the target drive before confirming. The authors are not responsible for data loss.

License

MIT