🥃 Dram

Whisky is dead. Pour yourself a Dram.

A terminal-based Windows-games-on-Mac manager for Apple Silicon, built to replace Whisky after it was discontinued. One Python file, no dependencies, runs on the Python that ships with macOS.

A dram is a small pour — and on an entry-level Mac, small pours are exactly what you want.

Not affiliated with Whisky, CrossOver, GOG, or Valve. Dram is a launcher and a wrapper around Wine; it does not ship or circumvent any game, and it assumes you own what you point it at.

Requirements

• Apple Silicon Mac (Intel works, minus the Rosetta layer), macOS 13+
• Homebrew — used to install Wine, winetricks, innoextract
• Xcode Command Line Tools, only for the optional controller mapper
• ~15 GB free for a prefix plus a few games

The stack (what Whisky actually was)

Whisky was a GUI over three things, and Dram manages the same three:

Layer	What it does	Dram's source for it
Rosetta 2	Runs x86_64 code on Apple Silicon	Built into macOS (dram setup installs it)
Wine engine	Runs Windows programs on macOS	In order of preference: WineHQ builds (wine 10/11 — best audio & controllers) → Gcenx Wine-Crossover if present → leftover WhiskyWine → anything on PATH
Graphics translation	DirectX → Metal	D3DMetal if your engine has it (WhiskyWine/GPTK does), otherwise Wine's WineD3D + MoltenVK — fine for DX9/OpenGL-era 2D games

Together the first two are what people half-remember as "RosettaWine". dram engine shows every engine found on your machine and which one is active; dram engine --set pins a specific one.

If you had Whisky installed before: its engine (WhiskyWine, with D3DMetal) usually survives in ~/Library/Application Support/com.isaacmarovitz.Whisky/ and Dram adopts it automatically. Old Whisky bottles keep working too — dram doctor finds them, and dram scan reads the GOG manifests inside them so previously-installed games can be re-registered in one step.

Install

./install.sh        # symlinks `dram` onto your PATH
dram setup          # installs anything missing: Rosetta 2, Wine, winetricks, prefix
dram doctor         # verify everything (add --fix to auto-repair the safe stuff)

dram setup is idempotent — run it any time; it skips what's already done.

Use

dram                          # interactive menu: pick a number, play
dram add                      # add a game (interactive, tab-completes paths)
dram add ~/Games/MyGame/game.exe --yes
dram scan ~/Downloads         # hunt a folder for game .exes, add in bulk
dram search <name>            # fuzzy search (typos fine)
dram play <name>              # fuzzy launch; `dram play 1` works too
dram install ~/Downloads/setup_game.exe    # unpack a GOG installer and
                              # auto-register what it contains

Everything lives in ~/.dram (library, config, prefixes, logs). Override with DRAM_HOME.

Full documentation: Command reference — every command and flag, generated from the parser itself · Configuration — every setting, per-game fields, and what lives where.

The rest of the toolbox

Command	What
dram doctor [--fix]	Full health check: CPU/RAM/disk, Rosetta, Homebrew, engines, quarantine flags, D3DMetal, audio output & controllers, prefix, dead library entries, old Whisky bottles
dram list / remove / edit	Library management; playtime + last-played tracked automatically
dram engine [--set NAME|auto] [--install stable|staging|devel|gptk]	List/pin/install Wine engines; per-game pin via dram add --engine or dram edit
dram joy	Open Wine's joystick panel to test a controller inside Wine
dram pad [--list] [--game <game>]	Controller→keyboard/mouse mapper for games with no pad support; per-game profiles
dram prefix list|new|delete|path	Multiple prefixes ("bottles")
dram prefix snapshot/rollback [label]	APFS copy-on-write prefix snapshots — instant, near-free; take one before winetricks or an installer
dram config	Toggles: msync, esync, retina, metal_hud, avx, locale, eco, turbo, pad
dram tricks <verbs>	winetricks passthrough (DLLs, fonts, runtimes)
dram cfg / dram open	winecfg / open the prefix's C: drive in Finder
dram run foo.exe / dram wine …	One-off exe / raw wine passthrough
dram steam [appid]	Windows Steam inside the prefix, for Windows-only titles
dram steamcmd <appid> --user <you>	Pull a Windows build with Valve's CLI — no Steam client
dram saves backup/restore <game>	Save-game snapshots — auto-finds saves in prefixes (AppData, Documents, Saved Games) and ~/Library/Application Support, zips them, keeps the last 10
dram mod list/backup/install/restore <game>	Mod manager with a safety net — APFS-clones the game folder first, unpacks .zip/.7z/.rar/.tar.* or folders, runs .exe patchers inside the game dir, rolls back with one command
dram shortcut <game>	Generates a tiny .app in ~/Applications — launch from Spotlight/the Dock
dram warm [game]	Pre-warm wine + RAM-cache game files for a hot start
dram play --turbo / --eco	No display sleep + resident wineserver / efficiency-core clamp
dram why [game] [--deep]	Crash triage: scans the last log for known failure signatures and names the fix. On a frozen game it reads the thread table to tell a spin from rendering; --deep names the module the spinning thread is stuck in
dram kill / dram logs [game]	Shut down wineserver everywhere / tail the latest log
dram completion / dram update	zsh tab-completion; self-update via git pull

Getting games in

• GOG installers — dram install <setup.exe or its folder>. Dram does not run GOG's wizard: GOG wraps Inno Setup in a custom skinned UI (botva2.dll) that crashes under Wine on Apple Silicon — it dies silently right after the language dialog, and no combination of /VERYSILENT flags avoids it. Instead Dram unpacks the installer natively with innoextract (auto-installed via Homebrew): no Wine, no wizard, headless and deterministic. It then reads GOG's own goggame-<id>.info manifest for the real title and primary executable — so DOSBox/ScummVM-wrapped classics register correctly instead of you guessing which exe to pick — and drops the game in ~/Games/<Title>. Multi-part downloads (-1.bin, -2.bin) are handled. --wine forces the run-the-installer path if you need it.
• itch.io / standalone exes — unzip anywhere, dram add.
• Steam, Windows-only titles. The Mac Steam client refuses to install Windows-only depots. Two options:
  • dram steamcmd <appid> --user <account> uses Valve's official CLI to download the Windows build directly — no client, no GUI, less RAM. Dram never handles your password; SteamCMD prompts you itself.
  • dram steam installs and launches the Windows client in the prefix, then dram steam <appid> --name "Game" registers a one-command launcher. The client costs ~1 GB of RAM, so prefer the CLI. If store pages render black, add -cef-in-process-gpu; --no-browser skips the web helper entirely and fixes the classic hang at "Update complete, launching Steam…".
• Check for a native Mac build first. Many games ship one, and native always beats Wine on speed, RAM and battery. dram add any .app bundle or Mac binary and it runs with zero translation layers — Dram is a unified launcher, not a Wine-only one. It nudges you when you add a Windows exe of a title known to have a Mac version.

Low-RAM survival guide

Written for entry-level Apple Silicon Macs, useful on any of them.

• Close the browser before playing; it's the other thing holding a gig.
• msync is on by default (fastest sync on macOS). Leave esync off unless you know why you want it.
• One shared prefix beats a prefix per game — each booted prefix costs RAM and disk. Exception: pinned old engines need their own (below).
• After playing, dram kill frees whatever wineserver still holds.
• 2D and DX9-era games are the sweet spot. DX12 AAA is not happening on an entry-level machine — that's the hardware, not the tool.

Beyond the Whisky formula: efficiency

Dram keeps Whisky's core — Rosetta 2 + Wine is still the most efficient Windows-runner on macOS; a Windows-ARM VM eats half a low-memory Mac before the game boots — but deviates where it pays:

1. Native Mac builds beat Wine. Always. See above: .app bundles are first-class library entries with no prefix and no translation.

2. Eco mode — dram play <game> --eco (or dram config eco on) clamps the game to the efficiency cores via taskpolicy. 2D games don't need performance cores; on battery this is a real power and heat win. Turn it off when frames matter. (On "CPU offloading": x86 translation can't be pushed to the GPU. The real levers on Apple Silicon are E/P-core steering, keeping the GPU path modern, and pre-warming.)

3. Warm starts — dram warm <game> boots wine's services, holds wineserver resident, and streams the game's files into the RAM page cache (capped at 1 GB; macOS evicts it freely under pressure), so the next dram play skips cold-start seconds and first-minute disk stutter. dram play --turbo adds: no display sleep while the game runs (essential for controller play, where you never touch the keyboard), other prefixes quiesced, and your prefix's server pre-attached. Engine version probes are disk-cached, so the menu and doctor open instantly instead of re-running wine --version through Rosetta.

4. Engine choice per job — this is a real trade, know it. Modern WineHQ (wine 11) has the good audio stack and the modern controller stack, but no D3DMetal: DirectX goes WineD3D→Vulkan→MoltenVK→Metal. Apple's D3DMetal (in WhiskyWine/GPTK) translates DirectX→Metal directly and is markedly faster for GPU-heavy scenes — think heavy particle load — at the cost of an ancient wine 7.7 core with crackly audio and weak pad support. So keep wine 11 as the default and pin GPU-heavy games to D3DMetal:

   dram prefix new retro                      # old engines need their own prefix
   dram add "<game.exe>" --engine d3dmetal --prefix retro
   dram edit <game>                           # or set engine: d3dmetal

   --engine accepts a fuzzy name (whisky, d3dmetal, gptk, stable), a number from dram engine, or a full path. Give pinned games their own prefix — wine generations rewrite a prefix's registry and system DLLs, so pointing wine 7.7 at a prefix wine 11 has upgraded breaks in confusing ways. Dram warns you if you forget.

5. The future, when it lands: ARM64EC Wine (native ARM Wine that emulates only the game's x86 code, how Windows-on-ARM does it) isn't available for macOS yet. The day a build ships it drops into Dram as just another engine. Nothing to rewrite.

DXVK: measured, and mostly a dead end on Apple Silicon

dram dxvk install|remove|status is there, and DXVK's persistent shader cache is genuinely the right cure for "stutters the first time each effect appears". But on Apple Silicon it currently doesn't work, and Dram says so before touching anything. Measured on Apple Silicon with MoltenVK and wine 11:

DXVK	Result
3.x (latest)	No adapters found — needs Vulkan 1.3 features MoltenVK doesn't implement. Game won't start.
1.10.3 (default)	DxvkAdapter: Failed to create device — game runs, audio plays, black screen.

So dram dxvk install defaults to 1.10.3 rather than latest, warns on Apple Silicon, and asks before proceeding. Installing preserves wine's own PE builtins as *.dll.dram-builtin and dram dxvk remove puts them back — important, because wine 10/11 ship builtins as real .dll files, so a naive uninstall would delete your DirectX.

For GPU-heavy games on Apple Silicon, pin D3DMetal instead (see engine choice above) — that's the path that actually works today.

Audio & controllers (Whisky's two famous sins)

Both problems mostly live in Whisky's engine — WhiskyWine is wine 7.7 (a 2022 Game Porting Toolkit fork) with a crackly CoreAudio path and a mostly-broken gamepad stack. The fix is a modern engine:

• dram engine --install stable installs WineHQ's current build: reworked audio timing and the modern controller stack (Xbox, DualShock, DualSense, Switch Pro). Auto-detect prefers it once installed.
• dram doctor checks your default audio output (Bluetooth warning, sample-rate hint) and whether macOS sees a controller at all.
• dram joy opens Wine's joystick panel to confirm the pad inside Wine.

Still choppy on the new engine?

• Audio MIDI Setup (/Applications/Utilities) → your output device → 44100.0 Hz. Many 2D engines output 44.1 kHz, and resampling to 48 kHz under Rosetta is a classic crackle source.
• Wired beats Bluetooth while gaming — for both audio and pads.
• Close the browser; under memory pressure the audio thread starves.

Mods that bring their own audio engine are a known hazard. Wine reimplements XAudio2 as xaudio2_9.dll (FAudio), and a mod audio backend built against real XAudio2 can wedge it outright — the game freezes rather than crackles, at full CPU. dram why --deep names the DLL. The documented case is FINAL FANTASY IX + Memoria (see Worked examples); the fix is to point the mod at a different backend rather than to touch Wine.

When the game is the problem: dram pad

Plenty of PC games simply have no gamepad code — Wine's joy.cpl sees the pad, the game never asks for it. On Windows people fix this with Steam Input or JoyToKey; Dram ships its own native equivalent, built on Apple's GameController framework:

dram pad --list          # can macOS see the pad? (wake it with a button press)
dram play <game> --pad   # run the mapper alongside the game
dram pad --game <game>   # create a per-game profile
dram config pad on       # …or run it with every game

Default layout: left stick = mouse cursor, A = click & drag, RT = click, LT = right-click, dpad = arrow keys, B/X = X/Z keys, right stick = scroll, Menu = Enter, View = Esc. Edit ~/.dram/padmap.json to remap ("key:<name>", "click", "rclick", "none"; left_stick can be "mouse" or "arrows"). Per-game profiles live in ~/.dram/padmaps/.

First run: macOS prompts for Accessibility permission for your terminal (System Settings → Privacy & Security → Accessibility) — that's what lets the mapper send keys and clicks.

Controller seen by dram joy but a pad-supporting game still ignores it? Unplug other HID gadgets; some games only read slot 0.

Mods

Mods overwrite game files in place, so Dram snapshots first — an APFS clone of the whole game folder, effectively instant and costing no disk until files diverge. Nothing is ever a one-way door.

dram mod list <game>                      # installed mods, backups, drift
dram mod backup <game> --name clean       # snapshot before you tinker
dram mod install <game> --mod ~/Downloads/SomeMod.zip
dram mod restore <game> --name clean      # undo everything
dram mod diff <game>                      # exactly which files changed
dram mod prune <game> --keep clean        # reclaim space from old backups

Drift detection. Every backup also records a fingerprint of the game folder (relative path → size, mtime), so dram mod list reports anything that changed since the last one:

⚠ drifted since 20260731-110110-base:
   2 added, 1 modified  (+2.9 MB on disk)

This matters because in-game mod managers write straight into the game folder and never touch Dram's snapshot layer — without drift detection you'd think you were covered when you weren't. Take a fresh backup to capture a state you like, or dram mod diff <game> to see exactly which files were added, modified and removed, with sizes.

Pruning. Backups are APFS clones, so they cost almost nothing at first and slowly turn into real disk as mods overwrite files. dram mod prune keeps the 2 newest by default, plus anything matching --keep, and reports what was actually reclaimed rather than the misleading logical size — deleting a 247.7 MB clone of an untouched folder frees about 144 KB.

--mod accepts an archive (.zip, .7z, .rar, .tar.*), a folder (contents merged in), or a .exe patcher — patchers are staged into the game directory and run there, because that's how they find the assemblies they rewrite. Every install auto-backs-up first unless you pass --no-backup. Dram detects common frameworks (Memoria, Moguri, BepInEx) and carries per-game setup notes in a GAME_TIPS table, surfaced by dram add and dram mod list so the advice arrives when it's useful.

Worked examples

Concrete end-to-end runs. Everything above is game-agnostic; this section is where specific titles are the point.

A GOG installer, start to finish

dram install ~/Downloads/setup_garou_mark_of_the_wolves_*.exe
dram play garou

Verified on Garou: Mark of the Wolves (GOG, 2020-era installer): innoextract unpacked 247.7 MB to ~/Games/GAROU - MARK OF THE WOLVES, Dram read goggame-1830215906.info for the title and primary exe, registered it automatically, and it launched and ran under wine 11. Note this vintage of GOG installer puts the game at the extraction root rather than under app/; Dram handles both layouts.

A Windows-only Steam game, without the Steam client

dram steamcmd 1856900 --user <your-account> --name "Andro Dunos II"
dram play andro

Verified on Andro Dunos II: SteamCMD pulled the Windows depot to ~/.dram/steamapps/1856900 with no client running. That title ships xinput1_3.dll and no steam_api.dll, so it has native controller support and no DRM check — it runs standalone.

A modded Unity RPG

FINAL FANTASY IX is Windows-only, Unity-based, and mods cleanly under Wine. After buying it on GOG:

dram install ~/Downloads/setup_final_fantasy_ix_*.exe
dram mod backup "final fantasy" --name vanilla
dram mod install "final fantasy" --mod ~/Downloads/Memoria.Patcher.exe

The patcher runs on Wine's bundled Mono — don't install dotnet48 first; it's slow, failure-prone, and unnecessary here. dram mod install stages the patcher inside the game folder and runs it there, which is how it locates the launcher it rewrites.

Install Memoria first — it's the engine patcher and it ships the Mod Manager that downloads Moguri, 30 FPS videos, PSX sounds and the alternate soundtrack. Pull Moguri through that manager rather than hand-installing it, which is where most Wine/Proton guides report trouble. Budget ~5 GB. If a mod misbehaves, dram mod restore "final fantasy" --name vanilla puts you back exactly.

Known issue — set Memoria's audio backend. Memoria defaults to its own SaXAudio engine (Backend = 1, under [Audio] in Memoria.ini), which drives XAudio2. There's no Microsoft XAudio2 here — Wine substitutes its own reimplementation, xaudio2_9.dll, built on FAudio — and SaXAudio wedges it. The symptom is precise: the title screen draws normally, then the game freezes about a second later while pegging a core. It isn't a crash and it leaves nothing useful in the log; the audio thread has entered a loop it never leaves, and every Unity thread is left blocked on wineserver waiting for a callback that never comes.

[Audio]
Backend = 0        ; SdLib — was 1 (SaXAudio)

The "not recommended" label on 0 in that file is written for Windows players, where SaXAudio genuinely is better. Under Wine the recommendation inverts. Backend = 2 (Soloud) is the middle option if you hit audio quirks. If you specifically want SaXAudio back, the other route is forcing Wine to use the real XAudio2 the game already ships in x64/: dram edit → env WINEDLLOVERRIDES=xaudio2_9=n,b.

Troubleshooting

• "Engine found but won't run" → usually Rosetta missing (dram doctor --fix) or Gatekeeper quarantine (also --fix).
• Game exits instantly → dram why <game> reads the log and names the fix. Missing DirectX helpers are the usual culprit: dram tricks d3dx9 corefonts; .NET games want dram tricks dotnet48.
• Freezes seconds in but still burns ~100% CPU → that's not a crash, it's one thread spinning. dram why reads the thread table — a rendering game spreads work across its render and worker threads, a wedged one pegs a single thread and parks the rest — and dram why --deep attaches lldb to name the DLL it's stuck in. A mod's audio backend wedging Wine's XAudio2/FAudio is the classic case (see the FINAL FANTASY IX example above).
• Blurry or tiny window → dram config retina on (crisp, small UI) or off (default).
• First launch is slow → Rosetta translates the engine once, then caches; later runs are much faster. dram warm front-loads it.
• Wine got stuck → dram kill.

Uninstall

rm -rf ~/.dram              # library, prefixes (installed games!), logs
rm -f /opt/homebrew/bin/dram ~/.local/bin/dram
brew uninstall --cask wine-stable      # only if setup installed it

Contributing

See CONTRIBUTING.md. Short version: one file, no dependencies, must run on the Python macOS ships with, and anything that writes into a prefix or game folder needs an undo path.

python3 -m unittest discover -s tests -v

The suite is hermetic and mostly regression tests for bugs that actually shipped — each one names the failure it prevents.

License

Dram Personal Use License — see LICENSE.

Use it, install it, modify it for yourself, all freely and without asking. Redistributing, republishing, forking publicly, bundling it into another product, or selling it requires written permission — open an issue if you'd like it.

Dram is a launcher: it doesn't include Wine, DXVK, innoextract, SteamCMD or any game, and this licence says nothing about those. Releases up to and including v0.8.0 were published under MIT and remain available under those terms; every release after that is under the licence above.