# PyroSoft public software and writing # Bourbon 26 > Play Windows games on Mac, plus Steam and Android apps, on Apple Silicon. Canonical page: https://pyrosoft.pro/software/bourbon-26 Status: active Platforms: macOS Bourbon 26 is a native Mac app for playing Windows games on Apple Silicon. One Set Up Everything button installs and configures Wine Staging, DXVK, MoltenVK and Steam, and Apple's Game Porting Toolkit 3 is one more click away. There's no Terminal and no Windows licence to buy. You sign in to your own Steam account and download your own library. Smart Play keeps a verified profile for each title and matches it to a ready-made runtime on the Bottle Shelf (DXVK, WineD3D, VKD3D, DXMT, GPTK or native macOS), and you can always pick a different one. Games that ship a real Mac version run natively instead. Beyond Steam, Bourbon reaches Epic, GOG, Amazon and Ubisoft through Heroic and runs any .exe or .msi you download. Recent builds also put Windows games into the native Mac Steam library, add a Smart Play Analyzer that checks a game's files to work out which technology it needs, and add a controller-friendly Couch Mode. The same app runs Android with the Google Play Store on seven device types (still marked experimental), installs console emulators that show your own ROMs with their proper titles and box art, and opens cloud and remote play: Xbox Cloud, GeForce NOW, Amazon Luna, Boosteroid, Moonlight and PlayStation Remote Play. Bourbon 26 is $29.99 once, with a 24-hour trial. Not every game runs; titles with kernel-level anti-cheat generally won't, so check the compatibility list first. It needs an Apple Silicon Mac (M1 or newer) and macOS 14 Sonoma or later. Price: $29.99. ## Requirements Apple Silicon Mac (M1 or newer), macOS 14 Sonoma or later, an administrator account and internet for first-time setup, and disk space for Steam and your games ## Features - Set Up Everything installs Wine, DXVK, MoltenVK and Steam; GPTK 3 is one more click - Smart Play: a verified profile per game picks the bottle, renderer and fixes - Steam, plus Epic, GOG, Amazon and Ubisoft via Heroic - Windows games in the native Mac Steam library, with a controller Couch Mode - Run any Windows .exe or .msi, or choose Open With → Bourbon in Finder - Android with Google Play on seven device types (experimental) - Console emulators with your own ROMs, proper titles and box art - Xbox Cloud, GeForce NOW, Luna, Boosteroid, Moonlight and PlayStation Remote Play ## How to get it - [itch.io]() License: Buy once, yours for life · no subscription ## Recorded details - Version: 26.10.2.5 - License: Proprietary · its open layer, Bourbon-OSS, is MIT - Updated: 2026-10-02 - First release: On itch.io by Jul 2, 2026 - Tech: SwiftUI; Wine Staging 11, DXVK, DXMT, VKD3D, MoltenVK and D3DMetal ## Screenshots ![Bourbon 26 Home screen](https://pyrosoft.pro/store-assets/media/35c6bdf77f-960.webp) ![Bourbon 26 Games screen](https://pyrosoft.pro/store-assets/media/11d0185207-960.webp) ![Bourbon 26 Stores screen](https://pyrosoft.pro/store-assets/media/5b69848af7-960.webp) ![Bourbon 26 Remote Play screen](https://pyrosoft.pro/store-assets/media/ab19b10b63-960.webp) ![Bourbon 26 Windows Apps screen](https://pyrosoft.pro/store-assets/media/acbaa61058-960.webp) ![Bourbon 26 Advanced screen](https://pyrosoft.pro/store-assets/media/c3593e38d5-960.webp) ![Bourbon 26 Settings screen](https://pyrosoft.pro/store-assets/media/9013391edc-960.webp) ![Bourbon 26 Licensing screen](https://pyrosoft.pro/store-assets/media/7f82ec5c9d-960.webp) ![Bourbon 26 Android screen with tablet, phone, foldable, flip phone, Google TV, Automotive and desktop devices](https://pyrosoft.pro/store-assets/media/6245926f04-960.webp) ![Bourbon 26 Emulators screen listing the RetroArch, OpenEmu and ares front-ends](https://pyrosoft.pro/store-assets/media/8097e41e15-960.webp) ## Questions ### Do I need to buy Windows or own a PC? No. Bourbon is not a virtual machine and does not require a Windows licence. It runs Windows games through compatibility and graphics translation layers directly on macOS. ### Do I keep my Steam games? Yes. You sign into your own Steam account and download your own library. Bourbon never touches your ownership. ### Will my games actually work? Many modern 64-bit single-player and Steamworks games run well. Anything with kernel-level anti-cheat generally will not. Look up a specific title on the compatibility page before you buy. ### Is this a subscription? No. You buy Bourbon 26 once and nothing expires. It stays fully supported and keeps getting maintenance updates — fixes for macOS and Steam changes, and compatibility work. New features land in the next major version, which is a separate optional purchase. You are never forced to upgrade to keep what you already paid for. ### What do I need to run it? An Apple Silicon Mac (M1 or newer) running macOS 14 Sonoma or later, an administrator account for first-time setup, and enough disk space for Steam and your games. ### Is there a free trial? Yes. Download the trial build and sign in with itch.io for a 24-hour unlock, so you can test your own games and settings before you buy. ### Which stores can I play from besides Steam? Steam is the main library. Epic, GOG, Amazon and Ubisoft go through Heroic on the Stores page. You can also run any Windows .exe or .msi. ### Does Bourbon update itself? Yes. Every build is Developer ID signed and notarized by Apple, and updates itself in the app. Verified game fixes also arrive over the wire, so a fix reaches you the day it is confirmed. ### Can I see Windows games in the Mac Steam client? Yes. Recent builds put Windows games into the native Mac Steam library, where you can pick Bourbon's automatic Smart Play compatibility tool or a specific bottle. ## Related guides and journals - [Moving Bourbon safely, then making the verification faster](https://pyrosoft.pro/blog/moving-bourbon-safely-then-making-the-verification-faster.md) - [The audit that put saves and reset safety first](https://pyrosoft.pro/blog/the-audit-that-put-saves-and-reset-safety-first.md) - [Native Steam integration and a library you can use from the couch](https://pyrosoft.pro/blog/native-steam-integration-and-a-library-you-can-use-from-the-couch.md) - [Keeping older tools and newer Steam clients in their own lanes](https://pyrosoft.pro/blog/keeping-older-tools-and-newer-steam-clients-in-their-own-lanes.md) - [Giving SteamOS its own place in Bourbon](https://pyrosoft.pro/blog/giving-steamos-its-own-place-in-bourbon.md) - [Activation, installers and knowing which program we launched](https://pyrosoft.pro/blog/activation-installers-and-knowing-which-program-we-launched.md) - [Smart Play starts figuring out unfamiliar games](https://pyrosoft.pro/blog/smart-play-starts-figuring-out-unfamiliar-games.md) - [Making setup and repair less disruptive](https://pyrosoft.pro/blog/making-setup-and-repair-less-disruptive.md) - [When the menus work but the game world is black](https://pyrosoft.pro/blog/when-the-menus-work-but-the-game-world-is-black.md) - [Bourbon 26: choosing the right way to play](https://pyrosoft.pro/blog/bourbon-26-choosing-the-right-way-to-play.md) - [Free manual Windows gaming setup on Apple Silicon: step by step](https://pyrosoft.pro/blog/manual-windows-gaming-apple-silicon-free-2026.md) - [Windows games on Mac](https://pyrosoft.pro/blog/windows-games-on-mac.md) - [Steam on Mac](https://pyrosoft.pro/blog/steam-on-mac.md) - [Anti-cheat on Mac](https://pyrosoft.pro/blog/anti-cheat-on-mac.md) - [Boot Camp on Apple Silicon](https://pyrosoft.pro/blog/boot-camp-apple-silicon.md) - [Play Windows games on Mac for free](https://pyrosoft.pro/blog/free-windows-games-on-mac.md) - [Bourbon 26 system requirements](https://pyrosoft.pro/blog/bourbon-26-system-requirements.md) - [DXVK vs D3DMetal](https://pyrosoft.pro/blog/dxvk-vs-d3dmetal.md) - [Wine bottles on Mac](https://pyrosoft.pro/blog/wine-bottles-on-mac.md) - [AIL eAPP on Mac](https://pyrosoft.pro/blog/ail-eapp-on-mac.md) - [Run .exe files on Mac](https://pyrosoft.pro/blog/run-exe-on-mac.md) - [Notepad++ on Mac](https://pyrosoft.pro/blog/notepad-plus-plus-on-mac.md) - [Whisky alternative](https://pyrosoft.pro/blog/whisky-alternative.md) - [CrossOver alternative](https://pyrosoft.pro/blog/crossover-alternative.md) - [Parallels alternative](https://pyrosoft.pro/blog/parallels-alternative.md) - [Game Porting Toolkit](https://pyrosoft.pro/blog/game-porting-toolkit.md) - [Windows on Apple Silicon](https://pyrosoft.pro/blog/windows-on-apple-silicon.md) - [What Wine can't run](https://pyrosoft.pro/blog/what-wine-cant-run.md) --- # Virtual Drivers for macOS > Seven virtual-device tools. One Mac app. Canonical page: https://pyrosoft.pro/software/virtual-drivers-macos Status: beta Platforms: macOS Virtual Drivers for macOS creates real virtual devices from one native Mac workspace: displays, audio loopback cables with a live mixer, cameras, MIDI endpoints, keyboards, mice and gamepads, a private encrypted packet interface, and disk images. It comes from the developers of the Windows Virtual Display Driver and Virtual Audio Driver and the Linux Virtual Display Driver. Each driver has its own Advanced section, and 28 workflow profiles set up common jobs such as streaming, remote work, meetings, presentations, music, game controls, private networking and portable storage. Cameras use a real source you choose (a display, window, app, physical camera, image or video), MIDI supports both 1.0 and 2.0/UMP with a built-in MIDI Lab, and storage images can be AES-256 encrypted. A bundled vdd command exposes everything to scripts as JSON. It is in Early Access for $14.99, on itch.io, as a Developer ID signed and notarized download for Apple Silicon Macs on macOS 14 or later (virtual HID devices need macOS 15). No SIP changes or reduced-security mode are required. The virtual display relies on an undocumented CoreGraphics interface, so behaviour can change with macOS updates, and HDR and display rotation aren't offered. Price: $14.99. ## Requirements Apple Silicon, macOS 14 or later; HID devices need macOS 15+; no SIP changes or reduced-security mode ## Features - Virtual displays: up to 16 modes, 23–240 Hz, HiDPI, sRGB or Display P3 - Up to eight stereo Core Audio loopback cables with a live mixer - Virtual cameras from a display, window, app, camera, image or video - CoreMIDI 1.0 and MIDI 2.0/UMP endpoints, plus an 88-key MIDI Lab - Virtual keyboard, mouse, gamepad and media controls (macOS 15+) - Encrypted private packet tunnel to a companion peer you run - AES-256 encrypted APFS, Mac OS Extended or ExFAT disk images - 28 workflow profiles and a JSON CLI (vdd) with 49 methods ## How to get it - [itch.io]() ## Recorded details - Version: 26.10.5.6 (build 41) - License: Proprietary (source not public) - First release: Oct 5, 2026, on itch.io (Early Access) - Tech: CoreGraphics, Core Audio, CoreMIDI, CoreHID ## Screenshots ![Virtual Drivers for macOS dashboard: a sidebar listing Display, Audio, Camera, MIDI, Network and Storage, a flagship virtual display card set to 2560 × 1440 at 60 Hz with HiDPI, and a suite status panel showing 6 drivers available on release 26.9.6.1](https://pyrosoft.pro/store-assets/media/469c79ffd9-960.webp) ![Virtual Display configuration page with a 2560 × 1440, 60 Hz HiDPI preview, four presets, resolution, refresh-rate and pixel-density fields, and placement buttons for right, left, above and below](https://pyrosoft.pro/store-assets/media/783ea92fe4-960.webp) ![Virtual Audio page showing the Core Audio HAL loopback cable, an authorized audio helper, and a Mixer and Loopback Matrix route from Virtual Audio Cable 1 to Virtual Audio Cable 2 with gain, mute, channel and latency controls](https://pyrosoft.pro/store-assets/media/a317556a7c-960.webp) ![MIDI Lab with a Grand Piano voice, volume, tone, drive, delay and reverb knobs, octave, velocity and channel controls, an on-screen piano keyboard and a Run Round-Trip Test button](https://pyrosoft.pro/store-assets/media/40b2e3729d-960.webp) ![Virtual Network page with an isolated packet-tunnel interface at the default address 10.42.0.2, MTU 1280, IPv4 and IPv6 addressing fields and an included route of 10.42.0.0/24](https://pyrosoft.pro/store-assets/media/525b39c2c3-960.webp) ![Virtual Storage page with a 16 GB APFS sparse-bundle volume named Virtual Workspace, capacity presets, and filesystem and image-type pickers](https://pyrosoft.pro/store-assets/media/cdf035a00d-960.webp) ## Questions ### Do I have to turn off System Integrity Protection? No. No SIP changes or reduced-security mode are required. macOS asks you to approve the audio helper and the camera and network extensions. ### Does a virtual display survive quitting the app? No. Displays last while the app is running. ### Is Virtual Network a VPN service? No. It's an encrypted private packet tunnel to a companion peer you configure and run yourself. No public VPN service is supplied, and public or default routes are blocked. ### Is it open source like the Windows driver? No. The Windows Virtual Display Driver is MIT-licensed, but Virtual Drivers for macOS is a separate app and its source isn't public. ### How do I know the download is genuine? Release 26.10.5.6 (build 41) is Developer ID signed, notarized by Apple and stapled, and PyroSoft checked that the files in the itch.io download match the signed release. The itch page lists its SHA-256: 3cea6a41c206aba41876699c7b778407ae66173d4352fc48952ca19be5616b79. ## Related guides and journals - [Advanced controls, shared workflows and the bundled CLI](https://pyrosoft.pro/blog/advanced-controls-shared-workflows-and-the-bundled-cli.md) - [Real camera sources, HID reports and a private peer tunnel](https://pyrosoft.pro/blog/real-camera-sources-hid-reports-and-a-private-peer-tunnel.md) - [Teaching the suite to recover its own devices](https://pyrosoft.pro/blog/teaching-the-suite-to-recover-its-own-devices.md) - [Testing what the Mac devices actually deliver](https://pyrosoft.pro/blog/testing-what-the-mac-devices-actually-deliver.md) - [From a Mac virtual display to a driver suite](https://pyrosoft.pro/blog/from-a-mac-virtual-display-to-a-driver-suite.md) --- # InfinitePIP > Keep any screen, window or region in view, always on top. Canonical page: https://pyrosoft.pro/software/infinitepip Status: active Platforms: Windows, macOS, Linux InfinitePIP puts any screen, app window or custom region of your desktop into a borderless, always-on-top picture-in-picture window. Keep a tutorial beside your editor, a second monitor in view on your main one, or several sources open at once without switching apps. Version 26.8.30 is a cross-platform preview with one shared interface for Windows, macOS and Linux, in light and dark themes. You pick a Screen, Window or Region source with search, thumbnails and crop presets, then set each PiP's opacity, zoom, pan, aspect ratio and frame rate (15, 30 or 60 fps). Click-through lets mouse clicks pass to the window underneath. A Windows-only 26.10.17 test build adds a live mirror mode that shows a window directly through the Windows compositor. Capture stays on your machine: there's no account, analytics, telemetry or cloud relay, and captured frames are never uploaded or recorded. InfinitePIP works with virtual monitors from PyroSoft's Virtual Display Driver, and older Windows releases stay available for anyone who relies on their command-line workflow. Price: $4.99. ## Requirements macOS 13 or later with Screen Recording permission; Windows 10/11 x64 or Windows 11 ARM64; Linux x86_64 or ARM64 (Wayland needs PipeWire and xdg-desktop-portal) ## Features - Screen, Window and Region sources with search, grid/list views and crop presets - Multiple borderless, always-on-top PiPs, each managed from Active PiPs - Opacity, zoom, pan, aspect ratio and 15/30/60 fps controls for every PiP - Click-through passes mouse clicks to the window underneath - One interface for Windows, macOS and Linux, with light and dark themes - Windows live mirror mode in the 26.10.17 test build - No account, analytics, telemetry or cloud relay; captured frames stay local - Works with Virtual Display Driver monitors as sources ## How to get it - [itch.io]() - [Project website]() ## Recorded details - Version: 26.8.30 (cross-platform preview); 26.10.17 Windows x64 unsigned test build - License: MIT (repository not public) - Updated: 2026-10-19 - First release: 25.7.16 on itch.io, Jul 16, 2025 (Windows) - Tech: Electron 44 ## Screenshots ![InfinitePIP 26.8.30 dashboard in the dark theme: a Create a PiP page offering Screens, Windows and Regions, with a sidebar listing sources, Active PiPs and About & Help](https://pyrosoft.pro/store-assets/media/95cc2c4a10-960.webp) ![InfinitePIP 26.8.30 dashboard in the light theme, showing Screens, Windows and Regions cards and a Ready status in the sidebar](https://pyrosoft.pro/store-assets/media/9c862f44ee-960.webp) ![An earlier InfinitePIP release on a Windows desktop: the main window listing three screens, with several floating PiP windows open, one showing its zoom, opacity and always-on-top controls](https://pyrosoft.pro/store-assets/media/2ee7a264f7-960.webp) ![The original InfinitePIP Windows app with three monitors listed and a PiP context menu](https://pyrosoft.pro/store-assets/media/76e6934507-960.webp) ## Questions ### Which platforms does InfinitePIP run on? Windows (x64 and ARM64, installer or portable), macOS (one universal build for Apple silicon and Intel Macs) and Linux (x86_64/amd64 and ARM64, as an AppImage or .deb). Version 26.8.30 is labelled a preview on every platform. ### Why does macOS ask for Screen Recording permission? macOS won't show screen or window previews until you allow it. Turn InfinitePIP on under System Settings > Privacy & Security > Screen Recording, then relaunch the app if macOS asks. ### Does InfinitePIP upload or record my screen? No. Captured frames are drawn into local PiP windows and are never uploaded, recorded or kept. There's no account, analytics, telemetry, cloud sync or update checker. ### What does click-through do? It lets mouse clicks pass through a PiP to the window underneath, not to the captured source. Use Restore clicks or Show in the main app to get the PiP's controls back. ### Can I keep a virtual monitor in a PiP? Yes, as long as the operating system exposes the virtual display as a normal capture source. On Windows, pair InfinitePIP with PyroSoft's Virtual Display Driver. ### Are the downloads signed? The macOS builds are notarized by Apple. The Windows builds, including the 26.10.17 test build, are unsigned, and the itch.io page labels them that way. ## Related guides and journals - [Click-through controls and the cross-platform download set](https://pyrosoft.pro/blog/click-through-controls-and-the-cross-platform-download-set.md) - [A better workspace for all your PiPs](https://pyrosoft.pro/blog/a-better-workspace-for-all-your-pips.md) - [Giving InfinitePIP a clearer front door](https://pyrosoft.pro/blog/giving-infinitepip-a-clearer-front-door.md) - [Rebuilding InfinitePIP around independent floating windows](https://pyrosoft.pro/blog/rebuilding-infinitepip-around-independent-floating-windows.md) - [InfinitePIP begins with a simple desktop idea](https://pyrosoft.pro/blog/infinitepip-begins-with-a-simple-desktop-idea.md) --- # FreeSpark > Free AI that runs on your own device. Canonical page: https://pyrosoft.pro/software/freespark Status: active Platforms: Web FreeSpark is an AI assistant that lives in a browser tab. It picks an open language model your device can handle and runs it on your own GPU through WebGPU, so there is no account to create, no subscription and no daily message cap. Your chats, notes and settings stay in the browser's own storage. Around the model, FreeSpark does the legwork in ordinary code: it routes each request, gathers the date, your notes, files and any web results before the model starts, then checks figures and links after it answers. PyroSoft calls this Model + Spark. FreeSpark can search the web and cite up to three pages, read PDFs, Word files, spreadsheets and images without uploading them, run Python with numpy, pandas and matplotlib, make pictures with Janus-Pro-1B, and talk with on-device Whisper and Kokoro voices. You need a browser with WebGPU, such as a current Chrome, Edge or Safari. The first start downloads a model that can be a few gigabytes; after that it loads from the browser's cache. Web lookups are on by default and can be switched off, after which nothing about your requests leaves the device. Price: Free. ## Requirements A browser with WebGPU, such as a current Chrome, Edge or Safari; opening a workspace folder also needs the File System Access API. Speed, model size and answer quality vary by device. ## Features - Runs open language models on your own GPU via WebGPU; Auto picks one that fits - 53 switchable tools, each with its own switch in Settings - Web research that reads up to three pages and cites them; one switch turns it off - Reads PDFs, Word, spreadsheets, CSV, code and images in the browser, never uploaded - On-device Python with numpy, pandas, matplotlib and scipy; charts appear in chat - Pictures with Janus-Pro-1B; voice with Whisper and Kokoro, all on your device - Workspace folder edits are shown first with Apply and Reject - Notes every chat can see, plus automations that run every N minutes or daily ## How to get it - [Open web app]() - [Project website]() ## Recorded details - First release: September 2026 - Tech: WebGPU, WebLLM, Transformers.js, Pyodide ## Screenshots ![The FreeSpark app at freespark.app: a model picker set to Auto · Qwen3.5 (9B) with a Start button, a card reading “Your device. Your AI.”, and suggestion chips under “What can I help with?”](https://pyrosoft.pro/store-assets/media/24a5b4c233-960.webp) ![FreeSpark Settings: the model memory estimate, a “Things to remember” notes box, Whisper speech-recognition choice and the realistic voice option](https://pyrosoft.pro/store-assets/media/f3b9416a8b-960.webp) ![FreeSpark Settings: switches for web lookups, file-change approval and planning, then the Compute tool list with calculator, run_javascript, run_python, make_chart and more, each with its own switch](https://pyrosoft.pro/store-assets/media/eaca73542b-960.webp) ![FreeSpark Automation dialog with name, prompt, a repeat choice of every N minutes, a minutes field and a desktop-notification switch](https://pyrosoft.pro/store-assets/media/c63c6a22cc-960.webp) ![FreeSpark About dialog: how it works, a table of what runs on your device versus optionally over the internet, and what the server keeps](https://pyrosoft.pro/store-assets/media/22a9dd6a87-960.webp) ## Questions ### Is it really free? Yes. There's no account, subscription or daily message cap, because the model runs on your hardware rather than a paid server. FreeSpark shows no ads; the only thing in it that asks for money is an optional link to buy the creator a coffee. ### Why is the first start slow? The first time, FreeSpark downloads the model, which can be several gigabytes. After that it is cached and starts in seconds. If you'd rather press Start yourself, switch off "Start the AI when the page opens" in Settings. ### Will it run on my phone? If the browser supports WebGPU, FreeSpark offers the models that fit. Phones get smaller ones: on a phone or tablet the browser tends to close a WebGPU tab past roughly 1.5 GB, so FreeSpark keeps the model well under that, and if the browser ever closes the page it switches on Low-memory mode by itself. ### Can it work offline? Turn off "Look things up on the web" and your requests stay on the device. FreeSpark still downloads models and runtimes the first time it needs them, and the page itself loads from freespark.app. ### Can it change my files? Only inside a folder you choose to open. By default every change is shown first with Apply and Reject, and earlier versions are kept. ### Which models can it run? Open models built for the browser, from 30 families in the picker, including Llama, Qwen, Gemma, Phi, Mistral, DeepSeek R1 Distill and SmolLM2. Auto picks one that fits your device, and MLC builds from Hugging Face can be added in advanced settings. ## Related guides and journals - [Route, gather, then write the answer once](https://pyrosoft.pro/blog/route-gather-then-write-the-answer-once.md) - [Checking whether Spark actually helps the model](https://pyrosoft.pro/blog/checking-whether-spark-actually-helps-the-model.md) - [Making local work survive the next conversation](https://pyrosoft.pro/blog/making-local-work-survive-the-next-conversation.md) - [FreeSpark: useful AI on the hardware you already have](https://pyrosoft.pro/blog/freespark-useful-ai-on-the-hardware-you-already-have.md) --- # Battle Bot Arena Engine > Unity 6 (URP) template for robot-combat and arena-brawler games. Canonical page: https://pyrosoft.pro/software/battle-bot-arena-engine Status: active Battle Bot Arena Engine is a Unity template for robot-combat, arena-brawler and physics-destruction games. It gives developers a working foundation for building modular combat robots from the inside out: draw a polygon chassis, set its armor and weight class, pack the interior with batteries, motors, wheels and weapons, paint it, then drive and fight it in a physics-driven garage. Combat goes beyond a health bar. Armor dents and gashes where it is struck, wheels lose grip and tear off, spinners go unbalanced and shake the bot, failing batteries and motors smoke and catch fire, and a two-axis piercing and concussion model plays armor hardness against weapon type. Hand a bot to the AI and watch two machines fight from a broadcast camera, or build opponents from reusable AI profiles. Parts, damage values, power behavior, weight classes, AI profiles and arena rules are data-driven, and a Bake Asset Library tool turns the procedural content into standard Unity prefabs, materials, meshes and sounds. The package targets Unity 6 with the Universal Render Pipeline and the new Input System, ships with a developer handbook and more than 130 EditMode tests, and you can try it first in the free WebGL demo or a Windows demo. On pyrosoft.pro it also appears as BuildBattle. Price: $99.99. ## Requirements Unity 6 (6000.4.0f1 or newer) · Universal Render Pipeline · new Input System ## Features - Inside-out robot builder wizard, or start from a complete pre-made bot - Spinners, saws, egg-beaters, flippers, hammers, axes, wedges and spikes - Localized damage: wheels tear off, spinners unbalance, parts break away - Two-axis piercing/concussion damage with visible dents and battle scars - Battery and motor power budget, including motor overvolting - Reusable AI profiles and a one-key AI-vs-AI spectator mode - Bake Asset Library turns procedural content into standard Unity assets - 130+ EditMode tests, a developer handbook and WebGL and Windows demos ## How to get it - [itch.io]() - [Project website]() - [Documentation]() - [Play the WebGL demo]() - [Unity Asset Store]() - [Developer handbook]() ## Recorded details - Version: v26.6.15 (latest itch package); live web demo is labelled 2.0.0 - First release: Public by Jun 17, 2026 (YouTube announcement) - Tech: Unity 6, Universal Render Pipeline, new Input System ## Screenshots ![BuildBattle Design Lab in the WebGL demo at step 01/08 Base Shape, with a list of pre-made bots](https://pyrosoft.pro/store-assets/media/3390dea491-960.webp) ![Unity editor, BuildBattle Workshop step 7 (Validate & Test): a finished bot beside its mass budget and performance stats](https://pyrosoft.pro/store-assets/media/732e4d0ed9-960.webp) ![Unity editor, BuildBattle Workshop step 5 (Components): placing motors, a battery and wheels inside a see-through chassis](https://pyrosoft.pro/store-assets/media/c03c432709-960.webp) ![Unity editor, BuildBattle Combat Arena: a small wheeled bot beside the arena wall, with the controls and status panel](https://pyrosoft.pro/store-assets/media/f701d1c002-960.webp) ![Unity editor, BuildBattle Workshop step 1 (Base Shape): a custom six-corner base plate drawn on the grid](https://pyrosoft.pro/store-assets/media/3e206cfbad-960.webp) ![BuildBattle combat arena with two robots and live HUD](https://pyrosoft.pro/store-assets/media/6781066004-960.webp) ![A bar-spinner robot closing on a rammer in a walled arena](https://pyrosoft.pro/store-assets/media/eec4e44e81-960.webp) ![A battle-damaged combat robot with dented armor and smoke rising from a part](https://pyrosoft.pro/store-assets/media/cf3846ab70-960.webp) ![Unity editor, BuildBattle Workshop step 2 (Body Height & Slopes): shaping the chassis with corner handles and move arrows](https://pyrosoft.pro/store-assets/media/0a43d470b3-960.webp) ## Questions ### Which Unity version do I need? Unity 6000.4.0f1 (Unity 6) or newer, with the Universal Render Pipeline active and the new Input System enabled. ### Can I try it before buying? Yes. A playable WebGL demo runs at bbae.pyrosoft.pro, and the itch.io page links a Windows demo. ### Can I add my own parts and arenas? Yes. Parts, damage values, power behavior, weight classes, AI profiles and arena rules are data-driven, and the kit is designed to be extended with your own models, materials, sounds, UI, arenas and rules. ## Related guides and journals - [Delivering the tested arena build without changing the server around it](https://pyrosoft.pro/blog/delivering-the-tested-arena-build-without-changing-the-server-around-it.md) - [Battle Bot Arena Engine 2.0 reaches the browser](https://pyrosoft.pro/blog/battle-bot-arena-engine-2-0-reaches-the-browser.md) --- # Display Preview App > View your virtual displays in application windows. Canonical page: https://pyrosoft.pro/software/display-preview-app Status: active Platforms: Windows Display Preview App shows any monitor connected to your PC, including the virtual monitors created by the Virtual Display Driver, inside an ordinary window. You can watch and use a virtual screen without plugging in another physical display. Pick the monitor from a menu that lists each one's resolution, choose a frame rate between 1 and 60 FPS, show or hide the cursor, and press Escape or Alt+Enter for fullscreen. The preview resizes with the window. It runs on Windows and costs $2.50 on itch.io; Patreon supporters get it free. It is a beta release and is still being developed. Price: $2.50. ## Requirements Windows; designed to be used with the Virtual Display Driver ## Features - Shows any connected monitor, including virtual ones, in a window - Monitor menu lists each display with its resolution - Frame rates of 1, 10, 15, 30, 40 and 60 FPS - Show or hide the cursor in the preview - Fullscreen with Escape or Alt+Enter - Preview resizes with the window ## How to get it - [itch.io]() ## Recorded details - Updated: 2026-10-05 - First release: January 2025 ## Screenshots ![Display Preview App window showing a virtual monitor](https://pyrosoft.pro/store-assets/media/4e0c93c75c-960.webp) ## Questions ### How do I run it? Download it, extract DisplayPreview.zip and run DisplayPreview.exe. ### Is it free for Patreon supporters? Yes. It is a paid app on itch.io, with free access for Patreon supporters. ### How do I leave fullscreen? Press Escape or Alt+Enter, or use the menu. --- # Bourbon-OSS > What Bourbon learned, in the open. Canonical page: https://pyrosoft.pro/software/bourbon-oss Status: active Platforms: macOS Bourbon-OSS is the open, reusable layer of Bourbon 26, published on GitLab under the MIT licence. It carries the Smart Play recipes, community compatibility catalogs and small fixes Bourbon relies on, so anyone running Windows games through Wine on a Mac can use them in their own setup. The Bourbon 26 app itself, with its SwiftUI interface, orchestration and Smart Play launch engine, stays private. Inside are managed recipes graded verified, recipe or known_failure, plus Smart Play launch plans; a mined catalog of Mac-safe per-game fixes; an Apple Gaming Wiki and Are We Anti-Cheat Yet snapshot; a DXVK-macOS Direct3D 9 patch for MoltenVK; a shim that fixes Steam's black window under Wine on Apple Silicon; and minimal Direct3D 11 probes for checking GPTK, DXVK and DXMT. The Python tools use only the standard library: compat_sources.py looks up a community verdict offline and refreshes the data, mine_fixes.py re-mines protonfixes, Whisky and Lutris notes, and rom_metadata.py matches console ROMs to the Libretro database. The project thanks Wine, Whisky, CrossOver, Apple Gaming Wiki and the wider Windows-on-Mac community; publishing what Bourbon verifies is how PyroSoft gives back. Price: Free. ## Features - Managed Smart Play recipes graded verified, recipe or known_failure - Per-game fixes for 528 Steam games (236 concrete), mined from protonfixes, Whisky, Lutris - Apple Gaming Wiki and Are We Anti-Cheat Yet community snapshot - MoltenVK-friendly DXVK-macOS Direct3D 9 patch - Steam CEF shim that fixes the black Steam window under Wine on Apple Silicon - Minimal D3D11 clear and cube probes for GPTK, DXVK and DXMT - ROM titles, box art and clear logos from the Libretro database - Standard-library Python tools with offline compatibility lookups ## How to get it - [Source code]() ## Recorded details - License: MIT - Updated: 2026-08-04 - First release: Repository created Jul 20, 2026 - Tech: Python 3 (standard library); mingw-w64 for the shim and probes ## Screenshots ![The PyroSoftPro/Bourbon-OSS repository on GitHub: data, patches, probes, recipes and tools folders, an MIT licence and 40 stars](https://pyrosoft.pro/store-assets/media/1ac6172b2d-960.webp) ![The README's What's included table listing recipes, data, the DXVK patch, the Steam shim, three Python tools, the DXVK build script and the probes](https://pyrosoft.pro/store-assets/media/c1e90387e5-960.webp) ![The data folder on GitHub with eight JSON catalogs, from anticheat_blocklist.json to save_sync_rules.json](https://pyrosoft.pro/store-assets/media/df958eeee5-960.webp) ![The tools README: the Steam CEF shim build line and install steps, and the community refresh commands](https://pyrosoft.pro/store-assets/media/53ee6949dc-960.webp) ![The DXVK bourbon-d3d9 patch README explaining the three fixes: device creation, the MSL sampler matrix and an obsolete MinGW stub](https://pyrosoft.pro/store-assets/media/5d5825dcc4-960.webp) ![Bourbon 26's compatibility page: titles tracked, native macOS and Wine counts, bottle filters, and game cards marked Homegrown or Not Compatible](https://pyrosoft.pro/store-assets/media/32b992e56b-960.webp) ## Questions ### Is this Bourbon 26 for free? No. Bourbon-OSS is data, patches and small tools, not the app. Bourbon 26's orchestration, SwiftUI interface and Smart Play launch engine stay private. ### Can I use the catalogs in my own launcher? Yes. Bourbon-authored data is MIT. For the community-derived files, keep the attribution described in NOTICE and respect each upstream project's terms. ### What do I need to run the tools? Python 3 and nothing else for the Python tools. Building the Steam shim and the probes needs mingw-w64. ### Does anything here download games, ROMs or BIOS files? No. rom_metadata.py fetches only catalogue text and cover images from the Libretro projects. --- # BurnBin > Share a file. Get a link. Let it burn away. Canonical page: https://pyrosoft.pro/software/burnbin Status: active Platforms: macOS, Windows BurnBin turns your own Mac or Windows PC into a temporary file host. Add a file, pick a link and send it: recipients get a clean public download page, while the file is served straight from your computer and never moved into a cloud drive. Every share offers up to three routes, each with a green, yellow or red status light: a managed BurnBin link that rotates (every six hours by default) and drops the old route, a Cloudflare Tunnel fallback that needs no router changes, and Direct IP for the fastest path when you can open your router. The host dashboard tracks access and downloads per file, shows image thumbnails and plays video, and visitor uploads stay off until you allow them. BurnBin began as a small Python tool that shared files through a Cloudflare Tunnel. Today it is a notarized Apple-silicon Mac app (26.8.31.1) and a portable Windows x64 build (26.8.30.13) that share one backend and interface. The source is MIT-licensed, but its repository isn't public. Price: Free. ## Requirements macOS on Apple silicon; Windows 10/11 x64. Packaged builds bundle their runtimes and a pinned cloudflared ## Features - Managed BurnBin link that rotates and removes the old route - Cloudflare Tunnel fallback that needs no router changes - Direct IP route, with router setup attempted when possible - Green, yellow and red status light on every link - Access and download tracking per file - Optional return uploads, off by default - Image thumbnails, previews and in-app video playback - Notarized Apple-silicon Mac app and portable Windows x64 build ## How to get it No download is available right now: the itch.io page that hosted BurnBin is offline. - [Project website]() - [Visit burnb.in]() ## Recorded details - Version: macOS 26.8.31.1; Windows 26.8.30.13 - License: Source MIT (repository not public) · official builds: PyroSoft Productions Commercial License - First release: Earliest build listed: Windows 25.12.9 - Tech: Electron, Python and Flask, Cloudflare Tunnel ## Screenshots ![BurnBin host dashboard in grid view: four hosted files with image and video previews, Download and Unshare buttons, a Links panel showing Cloudflared, BurnBin and Direct IP status, and Share a file and Visitor uploads panels](https://pyrosoft.pro/store-assets/media/7c2bb20061-960.webp) ![BurnBin public share page titled Available downloads: four shared files in grid view with Download buttons, a Send a file back upload form, and a DMCA takedown contact in the sidebar](https://pyrosoft.pro/store-assets/media/ff7ea04db3-960.webp) ![BurnBin host dashboard in a macOS window, showing one hosted file in list view and the Links panel](https://pyrosoft.pro/store-assets/media/b686c0be62-960.webp) ![BurnBin host dashboard with hosted files, share controls, and link status](https://pyrosoft.pro/store-assets/media/403c79aca8-960.webp) ![BurnBin viewer page with return upload controls enabled](https://pyrosoft.pro/store-assets/media/2eda792d86-960.webp) ![A shared video named BurnBin-demo.mp4 playing in BurnBin's built-in preview player](https://pyrosoft.pro/store-assets/media/03ed3a5ee3-960.webp) ## Questions ### Where are my files stored? On your own computer. BurnBin serves them straight from your Mac or PC while it's running and doesn't move them into a cloud drive. ### What happens when a link burns? The managed BurnBin URL rotates (every six hours by default) and the old route is removed, so the previous link stops working. Unsharing a file, or closing BurnBin, stops it being served at all. ### Do I need to change my router settings? Not for the managed BurnBin link or the Cloudflared fallback. Only Direct IP may need router or firewall access, and BurnBin shows it in yellow until it's ready. ### Can people send files back to me? Only if you allow it. Visitor uploads are off by default; switch on Allow uploads from viewers and the public page shows a Send a file back form. ### Which platforms does BurnBin support? macOS on Apple silicon (a notarized build) and Windows 10/11 x64 (a portable build). There's no packaged Linux build. --- # FriendlyIP > Turn IPv4 addresses into six-character codes you can read aloud. Canonical page: https://pyrosoft.pro/software/friendlyip Status: active Platforms: Web FriendlyIP turns an IPv4 address into a six-character code you can read aloud, type on a TV remote or show on a setup screen: 42.13.37.67 becomes 3BqaAL. The code is the address itself, encoded with a human-safe Base57 alphabet that leaves out easily confused characters, so it decodes anywhere, offline, with no lookup table. It's made for the moments where addresses get fumbled, like a support call or a LAN party. Around the IPv4 converter sit three beta tools: QR codes made locally in your browser, temporary FriendlyPINs for IPv4 or IPv6 addresses that expire after 5 minutes to an hour (up to five active at once per address), and short online lookup codes for long IPv6 addresses. Developers can call the hosted JSON API or bundle the small friendly-ip.js module. FriendlyIP is free for indie apps, games, tools and any product earning under $100,000 a year; bigger commercial products need a licence from PyroSoft, and teams that need their own PIN pool can add a dedicated FriendlyPIN endpoint. Price: Free. ## Features - Encodes any IPv4 address as a six-character code that decodes offline - Human-safe Base57 alphabet with no 0, 1, I, O or l - QR beta: SVG QR codes of IPv4 or IPv6 addresses, made in your browser - FriendlyPIN beta: temporary PINs for IPv4 or IPv6 that expire in 5 minutes to 1 hour - Up to 5 active FriendlyPINs per IP; each new PIN lists the ones still active - IPv6 beta: short online lookup codes; the same address always gets the same code - Hosted JSON API (GET or POST) and a downloadable friendly-ip.js browser module - Free for products earning under $100,000 a year ## How to get it - [Open web app]() - [Project website]() ## Recorded details - License: FriendlyIP licence: free under $100,000 a year in revenue - First release: July 2026 - Tech: HTML, CSS and JavaScript; PHP API ## Screenshots ![FriendlyIP home page converting 42.13.37.67 into the code 3BqaAL](https://pyrosoft.pro/store-assets/media/68c34216fa-960.webp) ![FriendlyIP QR page with a generated QR code and a Download SVG button](https://pyrosoft.pro/store-assets/media/39a61ab7d4-960.webp) ![FriendlyPIN page with Create PIN and Resolve PIN tabs and a 1-hour expiry picker](https://pyrosoft.pro/store-assets/media/66c1c2ca50-960.webp) ![FriendlyIP on a phone-width screen with the tool menu above the intro](https://pyrosoft.pro/store-assets/media/e5aaf9cecc-960.webp) ## Questions ### What is a FriendlyIP code? A six-character code that encodes an IPv4 address with an unambiguous alphabet, so you can read it over the phone instead of dictating twelve digits and three dots. ### Are codes reversible? Yes. Encoding is deterministic and decoding recovers the exact address. The same IP always produces the same code, and no server is needed to decode it. ### Does it work offline? Yes. IPv4 encoding is pure math, and the free API can run offline inside your own tools. (The IPv6 lookup codes and FriendlyPINs are online beta services.) ### Is FriendlyIP free? Yes. The web tool and the API are free, including for indie developers. Products selling over $100,000 a year need a commercial licence, and teams that want their own FriendlyPIN endpoint can buy one as an add-on. ### Does it work on a LAN with no internet? Yes. Codes are deterministic and decoding needs no server round-trip, so it works even when the game room's internet doesn't, for private LAN addresses and public ones alike. ### Can my team get its own FriendlyPIN endpoint? Yes, as a paid add-on from PyroSoft: a dedicated endpoint under your own URL slug, your choice of default PIN length, PINs that stay valid from 5 minutes up to 7 days, and a PIN pool of your own. The public API stays free for indie use. ## Related guides and journals - [Connecting FriendlyIP to the rest of PyroSoft](https://pyrosoft.pro/blog/connecting-friendlyip-to-the-rest-of-pyrosoft.md) - [FriendlyIP: an address you can read over the phone](https://pyrosoft.pro/blog/friendlyip-an-address-you-can-read-over-the-phone.md) --- # Linux Virtual Display Driver > Add a monitor that isn't there. Canonical page: https://pyrosoft.pro/software/linux-virtual-display-driver Status: active Platforms: Linux Linux Virtual Display Driver adds virtual monitors to Linux desktops running X11. It is a small native GTK3 app, written in Python, that finds an output your graphics driver exposes but isn't using and switches it on at the resolution and refresh rate you choose, so VR apps, OBS, Sunshine and screen-sharing tools see one more monitor. It works through xrandr with its own VESA CVT modeline code, so there is no kernel module to build. AMD and Intel GPUs work straight away; NVIDIA needs a guided one-time setup that writes a small Xorg config and a virtual EDID, followed by a fresh login. Each display can sit left, right, above or below an existing screen or mirror it, and your displays are remembered between sessions. Version 1.0.0 runs straight from source or installs system-wide with the included script, which supports apt, pacman, dnf and zypper. It is free under GPLv3 for personal and non-commercial use; commercial use needs a separate licence. Price: Free. ## Requirements An X11 (Xorg) session, Python 3.10 or newer, PyGObject (GTK3) and xrandr. Your password (pkexec) is asked for only when it writes system files. ## Features - Create virtual displays at any resolution and refresh rate - Ten resolution presets from 1280 x 720 to 5120 x 1440; 30-240 Hz presets - Optional CVT reduced blanking for lower bandwidth - Place displays left, right, above or below a monitor, or mirror it - AMD and Intel need no setup; NVIDIA gets a guided one-time setup - Remembers your displays between sessions - On GDM systems, keeps the login screen on your physical display - Optional system-wide install with a linux-vdd command and app-menu entry ## How to get it - [Source code]() ## Recorded details - Version: 1.0.0 - License: Personal use · commercial licence separate - Updated: 2026-03-30 - First release: December 2024 (as a script); GTK3 app from March 2026 - Tech: Python, GTK3 (PyGObject) and xrandr ## Screenshots ![The public GitHub repository VirtualDrivers/Linux-Virtual-Display-Driver: a linux_vdd folder, LICENSE, README.md, install.sh, uninstall.sh and vdd.py, with an About panel that reads: Add virtual monitors to your Linux device! Works with VR, OBS, Sunshine, and/or any desktop sharing software.](https://pyrosoft.pro/store-assets/media/e13a07e7c3-960.webp) ![GitHub source view of linux_vdd/modeline.py: a CVT modeline generator that implements the VESA CVT v1.2 standard and produces modeline strings compatible with xrandr --newmode](https://pyrosoft.pro/store-assets/media/084519143d-960.webp) ![GitHub source view of the _nvidia_generate_conf function: an xorg.conf.d Device section for the nvidia driver with ConnectedMonitor, CustomEDID, ModeValidation and AllowEmptyInitialConfiguration options](https://pyrosoft.pro/linux-vdd/assets/source-nvidia-conf.jpg) ## Questions ### Does it work on Wayland? No. It needs an X11 (Xorg) session because every step goes through xrandr. ### Why does NVIDIA need a restart? NVIDIA's proprietary driver won't add modes to disconnected outputs while X is running, so the app writes /etc/X11/xorg.conf.d/99-linux-vdd.conf and a virtual EDID; log out and back in once, then new displays appear instantly. ### The app says there are no available outputs. On NVIDIA run the Setup Virtual Outputs flow; on Intel look for VIRTUAL1/VIRTUAL2; on any GPU you can install xf86-video-dummy or load the evdi kernel module. ### Is it free? Yes for personal, educational and non-commercial use under GPLv3. Commercial use needs a separate licence from VirtualDrivers. ### How do I remove it? Use Menu > Remove NVIDIA Config (then restart your session) if you ran the NVIDIA setup, and sudo ./uninstall.sh for a system-wide install. The uninstaller keeps your saved displays in ~/.config/linux-vdd/ until you delete that folder. ### Which Python version do I need? Python 3.10 or newer. The README still lists 3.8+, but the current code does not run on 3.8 or 3.9. ### Will my login screen end up on the virtual display? On systems with GDM the app writes the login screen's monitors.xml so the greeter stays on your physical display. Other display managers are not changed. --- # Pixoo 64 Tools > Python scripts for the Divoom Pixoo 64 LED display. Canonical page: https://pyrosoft.pro/software/pixoo-64-tools Status: active Pixoo 64 Tools is a free collection of Python scripts for the Divoom Pixoo 64, the 64x64-pixel LED display. The main script captures your screen and streams it to the Pixoo, with a live preview window so you can see exactly what the panel is showing. You choose how the picture is shrunk to 64x64 (nearest, bilinear, bicubic, Lanczos, box or Hamming), can add a Pillow filter such as sharpen or edge enhance, crop to a square, overlay a pixel grid, switch between light and dark themes, or send a still image from disk instead of the screen. Two smaller scripts send a line of text or a single screenshot to the display. The scripts talk to the Pixoo over your local network through the open-source pixoo library. Install Pillow, pixoo and screeninfo with pip, enter the IP address shown in the Divoom app, and run the script. Mike published the tools on GitHub in February 2025 and walked through them on the MikeTheTech YouTube channel. Price: Free. ## Requirements Python with Pillow, pixoo and screeninfo (pip install pillow pixoo screeninfo); a Divoom Pixoo 64 and its IP address from the Divoom app ## Features - Streams your screen to the Pixoo 64 as a 64x64 image, with a live preview - Six scaling methods: Nearest, Bilinear, Bicubic, Lanczos, Box and Hamming - Optional Pillow filters, including Sharpen, Detail, Emboss and Edge Enhance - Send a still image (PNG, JPG, BMP or GIF) instead of the live screen - Crop to 1:1, toggle a pixel grid and switch between light and dark themes - Extra scripts send a line of text or a single screenshot to the display ## How to get it - [Source code]() ## Recorded details - License: No licence file - Updated: 2025-02-26 - First release: Feb 26, 2025 - Tech: Python, Tkinter, Pillow, pixoo ## Screenshots ![Pixoo 64 streaming window with a smoothed 64 by 64 preview](https://pyrosoft.pro/store-assets/media/pixoo-64-tools/pixoo-64-tools-r2.png) ![Pixoo 64 streaming window with a hard-edged preview](https://pyrosoft.pro/store-assets/media/pixoo-64-tools/pixoo-64-tools-r3.png) ## Questions ### How do I find my Pixoo 64's IP address? Open the Divoom app, go to Device Settings and copy the IP address, then enter it in the script (the streaming window has a Pixoo IP field). ### What do I need to install? Python and three libraries: run pip install pillow pixoo screeninfo. --- # Polygone > A low-poly zombie-horde FPS: hold off endless waves solo or in co-op. Canonical page: https://pyrosoft.pro/software/polygone Status: beta Platforms: Windows Polygone is a low-poly, highly visual take on the classic "Zombie Modes" of modern first-person shooters. Team up with friends to hold off endless hordes on a massive map, boarding up windows, buying new weapons and unlocking new areas as the waves get tougher. More than 50 types of zombies and bosses will test your skills, and the arsenal runs from traditional rifles and launchers to futuristic lasers and plasma weapons. Early Access updates added maps such as The Church, The Data District and Trailer Park, new playable characters, six perks, perk machines you switch on by finding fuses, buy zones for ammo and health, traps, doors you open with points, a day/night cycle and the Overseer, who taunts players over loudspeakers. Polygone is built in Unreal Engine and has been in Early Access on Steam for Windows since March 21, 2023, with single-player, online co-op and LAN co-op. It started on itch.io as Poly-gone, with pre-orders and a free single-player demo, before moving to Steam. Price: $9.99. ## Requirements Windows 10 64-bit (1909+), quad-core 2.5 GHz, 8 GB RAM, GeForce GTX 1060 or Radeon RX 590, DirectX 11, 2 GB storage (minimum) ## Features - Co-op online or over LAN, plus single-player - Over 50 types of zombies and bosses - Weapons from rifles and launchers to futuristic lasers and plasma guns - Board up windows, buy new weapons and unlock new areas of the map - Six perks, from perk machines you power up by finding two fuses - Maps include Construction Yard, The Church, Motel, The Data District and Trailer Park - Traps, doors you open with points, and buy zones for ammo and health - Day/night cycle, with the Overseer taunting players over loudspeakers ## How to get it - [Steam]() ## Recorded details - Version: 24.1.16 - First release: Early Access on Steam, Mar 21, 2023 (earlier on itch.io) - Tech: Unreal Engine ## Screenshots ![Low-poly zombies advancing through green fog toward the player](https://pyrosoft.pro/store-assets/media/326b579e81-960.webp) ![Third-person view at night: the player by a picnic table and a tally-mark chalkboard in a scaffolded yard, wave 1](https://pyrosoft.pro/store-assets/media/bb01d47d22-960.webp) ![A red zombie lit by a blue laser blast among stacked tyres, wave 4, with the laser gun equipped](https://pyrosoft.pro/store-assets/media/bdd44b4cfe-960.webp) ![First-person view of a boarded-up window with a zombie's hand reaching through, wave 1](https://pyrosoft.pro/store-assets/media/f358d5a379-960.webp) ![Polygone v0.2 main menu with survivors around a burning barrel](https://pyrosoft.pro/store-assets/media/c8aed304d9-960.webp) ![Three low-poly zombies, one in a football uniform, walk up a dark hillside path toward the player, wave 1](https://pyrosoft.pro/store-assets/media/173e7d3704-960.webp) ![A laser gun on a wall buy point between shipping containers, with a “Press F to take weapon” prompt, wave 2](https://pyrosoft.pro/store-assets/media/4b4e95edef-960.webp) ![Laser fire at night under a “Judgement Day is here” banner, with a green glow beyond the scaffolding, wave 2](https://pyrosoft.pro/store-assets/media/aef32a1fa6-960.webp) ![Red downed screen with a bleed-out timer on wave 8](https://pyrosoft.pro/store-assets/media/766a60802a-960.webp) ![Low-poly city overview with a burning tower block and mountains](https://pyrosoft.pro/store-assets/media/1d7f9d1a0d-960.webp) ## Questions ### Is Polygone finished? No. It is in Early Access on Steam. The developer's Early Access notes list fuller map access, more game modes, more weapons and more zombie types for the full version. ### Can I play on my own? Yes. Steam lists single-player as well as online and LAN co-op. --- # PSN Account ID Finder > Find your PSN Account ID. Canonical page: https://pyrosoft.pro/software/psn-account-id-finder Status: active Platforms: Web Chiaki and other PlayStation Remote Play clients ask for your PSN Account ID when you register a console, and it isn't your online name. It's your numeric PSN user ID packed into eight little-endian bytes and written in base64. The PSN Account ID Finder works it out for you in two steps, in a web page, with nothing to install. You sign in on Sony's own login page, copy the address you land on and paste it back. The finder trades the single-use code inside it for a short-lived token, reads your ID once and shows the base64 Account ID and the numeric user ID, each with a Copy button. Your password stays with Sony, and the code, the token and your account details are held in memory for that one request, never written to disk or a log. It's free, with no sign-up. To keep it available, lookups are limited to ten an hour per network; for that, the finder keeps only a hash of your IP address and the times of your recent attempts, cleared after an hour. The finder is a PHP port of the psn-account-id.py script from Chiaki, the open-source Remote Play client by thestr4ng3r; PyroSoft is not affiliated with Sony. Price: Free. ## Requirements A PlayStation Network account to sign in with on Sony's page, and a web browser ## Features - Two steps: sign in on Sony's page, then paste the redirect address back - Shows the base64 Account ID and numeric user ID, each with a Copy button - Shows which online ID you signed in as, when Sony includes it - Password stays with Sony; the single-use code is used once and discarded - No database, account, cookies or logs of codes, tokens or IDs - Accepts the full redirect address or just the code, and passes on Sony's error reason - PHP port of the psn-account-id.py script from Chiaki - Free, no sign-up; ten lookups an hour per network, tracked by a hashed IP ## How to get it - [Open web app]() - [Project website]() ## Recorded details - First release: August 2026 - Tech: PHP (port of Chiaki's psn-account-id.py) ## Screenshots ![PSN Account ID Finder steps 1 and 2 with a Get my Account ID button](https://pyrosoft.pro/store-assets/media/7001ec5645-960.webp) ![Two panels: Free and built on open source, and What happens to your data](https://pyrosoft.pro/store-assets/media/672fd9eeaa-960.webp) ![The PSN Account ID Finder on a phone-width screen, showing the title and step 1, Sign in at PlayStation](https://pyrosoft.pro/psn-account-id/assets/finder-mobile.jpg) ## Questions ### What is a PSN Account ID? It's the ID Remote Play clients such as Chiaki ask for when you register a console. It isn't your online name: it's your numeric PSN user ID, written as eight little-endian bytes in base64. ### Does PyroSoft see my PlayStation password? No. Sign in with PlayStation opens Sony's own login page in a new tab. The finder only receives the redirect address you paste back, which carries a single-use code. ### Does the finder store anything? Only what its rate limit needs: a hash of your IP address and the times of your recent attempts, and entries older than an hour are cleared on the next lookup. The code you paste, the token and the account details Sony returns stay in memory for that single request and are never written to disk or a log. The finder sets no cookies. ### The page I land on after signing in is blank. Did it break? No. That page is expected to look empty or say "redirect". Copy the whole address bar and paste it into step 2. ### Can I paste just the code? Yes. The finder accepts the full redirect address or the code on its own. ### Can I look up someone else's Account ID? No. There's no search by name; the finder reads the ID of whichever account signed in at Sony to create the code. ### Is this made by Sony? No. PyroSoft is not affiliated with or endorsed by Sony Interactive Entertainment. The finder is a PHP port of Chiaki's psn-account-id.py script. ## Related guides and journals - [Preserving the whole PSN identifier](https://pyrosoft.pro/blog/preserving-the-whole-psn-identifier.md) - [Finding the account ID a Remote Play client asks for](https://pyrosoft.pro/blog/finding-the-account-id-a-remote-play-client-asks-for.md) --- # PyroSoft Model Archive > AI models. By torrent. Canonical page: https://pyrosoft.pro/software/model-archive Status: active Platforms: Web PyroSoft Model Archive is a compact, unofficial catalog of AI model torrents. Each entry is a community mirror of an openly licensed model (speech, vision and documents, embeddings, text generation and language representation) listed with its size, licence, reported swarm and a magnet link. The archive deals in metadata, never model files. For every record PyroSoft recomputed the torrent's info-hash and matched each file path, size and published digest ID against a pinned upstream revision. The model bytes themselves were not downloaded or rehashed, and every entry says so. Seed counts are a dated snapshot reported by AI Seedbank. Search by model, publisher or licence, filter by task and licence, and open the magnet in any BitTorrent client. Only ungated releases labelled Apache-2.0 or MIT are listed. Price: Free. ## Features - 11 community mirrors of openly licensed models (seed counts as of Sep 14, 2026) - Search by model, publisher or licence; filter by task and licence - Each entry pins the upstream revision, publisher and licence - Info-hash recomputed; file paths, sizes and digest IDs matched to upstream - Reported seeds and leechers from AI Seedbank, with the snapshot time - Magnet links only: PyroSoft never hosts, proxies or seeds model files - Verification evidence published as catalog-review.json ## How to get it - [Open web app]() - [Project website]() ## Recorded details - Tech: Static catalog with a JSON evidence file ## Screenshots ![PyroSoft Model Archive page with search, filters and the first model entries](https://pyrosoft.pro/store-assets/media/53e293cd1a-960.webp) ![Model Archive entries with size, licence, seeds and Magnet buttons](https://pyrosoft.pro/store-assets/media/a71dbba688-960.webp) ![Model Archive on a phone-width screen](https://pyrosoft.pro/store-assets/media/8f1f31b55a-960.webp) ## Questions ### Does PyroSoft host the model files? No. The site serves only catalog metadata and verification evidence, and no .torrent files. Model bytes come from the peer swarm. ### Have the downloads been verified? The torrent paths, sizes and published digest IDs were matched against pinned upstream metadata, and the info-hashes were recomputed. The model payloads themselves were not downloaded or rehashed by PyroSoft. ### Are web seeds included? Not yet. No web seeds are approved or included in these magnet links; HTTP web seeding (BEP 19) is planned. --- # Rite of Eris > Free-to-play 3D survival roguelike: pick a hero and survive the waves. Canonical page: https://pyrosoft.pro/software/rite-of-eris Status: active Platforms: Windows Rite of Eris is a free-to-play 3D survival roguelike set in the fractured realm of Eris, the Greek goddess of strife and discord. It draws on the intensity of Vampire Survivors, the characters of Paragon and the worlds of Hades: pick a hero, survive wave after wave of enemies, and grow stronger as the run goes on. Each character has a distinct play style, and towering bosses reshape the battlefield, from Rampage in the Ruins of Mystras to Poison Sevarog in the Tower of Hera and Terra in the Gladiator's Arena. The game currently includes 5 maps, 5 bosses and 8 characters, and you can play alone or in local co-op. Since February 2026 every character, map, game mode and update can be unlocked through play. Optional cosmetic DLC for players who want to support development was announced as coming soon at the same time. The June 2026 update rebuilt each run around XP gems and level-up upgrade drafts with rerolls and banishes, and added permanent progress at the Altar of Power and the Arsenal. Rite of Eris is built in Unreal Engine 5 for Windows, with programming help from Monster Tooth Studios. Its first free demo build, dated November 20, 2023, went up on itch.io; the game entered Early Access on Steam on February 1, 2024, and had its full release on February 25, 2026. Price: Free. ## Requirements Windows 10, Intel i3 7th gen+, 8 GB RAM, GTX 1050+, DirectX 11, 10 GB storage (minimum) ## Features - Free to play: every character, map, mode and update unlocks through play - Distinct heroes, each with their own abilities and play style - Boss fights against Rampage, Poison Sevarog and Terra - Level-up upgrade drafts with Common to Legendary cards, rerolls and banishes - Permanent upgrades at the Altar of Power and per-hero weapon unlocks in the Arsenal - Play solo or team up in local co-op - Controller support: partial Xbox, plus DualShock and DualSense (per Steam) - Optional cosmetic DLC is planned (announced Feb 2026); it will not affect gameplay ## How to get it - [Steam]() ## Recorded details - First release: Demo Nov 20, 2023 (itch.io); Early Access Feb 1, 2024 - Tech: Unreal Engine 5 ## Screenshots ![The rock giant Rampage leaving a trail of fire across the battlefield](https://pyrosoft.pro/store-assets/media/53945e0625-960.webp) ![Poison Sevarog surrounded by enemies on a stone walkway](https://pyrosoft.pro/store-assets/media/65c88d5eac-960.webp) ![Choose Your Hero screen with abilities, maps and the hero roster](https://pyrosoft.pro/store-assets/media/b771a0fc33-960.webp) ![Rite of Eris main menu with three heroes before sandstone ruins](https://pyrosoft.pro/store-assets/media/294e172023-960.webp) ![A hero swinging a golden hammer across a red-earth field](https://pyrosoft.pro/store-assets/media/2690c62acc-960.webp) ![Level Up panel offering four upgrades mid-run](https://pyrosoft.pro/store-assets/media/07fd1803ab-960.webp) ![A hero bursts out of a fiery impact among red-rock temple ruins, with a Powerups marker and four ability icons](https://pyrosoft.pro/store-assets/media/20b44888fa-960.webp) ![Top-down dungeon fight: a hero swings a glowing hammer at shadowy enemies, with a 0:15 timer and the Level 1 bar](https://pyrosoft.pro/store-assets/media/5f58f815fa-960.webp) ![Top-down view of an armoured hero on a stone path by a camp tent, with a Powerups marker and the ability bar](https://pyrosoft.pro/store-assets/media/31795bfd12-960.webp) ![Character select: the locked rock golem Greystone (Element: Earth) with its move set and a grid of upcoming heroes](https://pyrosoft.pro/store-assets/media/a2adfe26c2-960.webp) ## Questions ### Is Rite of Eris really free? Yes. Every character, map, game mode and update is free and unlocked through play. Optional cosmetic DLC (skins, visual customization, supporter packs) was announced as coming soon in February 2026; it is cosmetic only and will not affect gameplay. ### Can I play with a friend? Yes, you can team up in local co-op. ### Does it support controllers? Yes. Steam lists partial Xbox controller support plus DualShock and DualSense support. Controller support in menus and gameplay arrived in the January 2024 updates (24.1.23 and 24.1.26). --- # Steam Command Generator > Generate Steam commands instantly. Canonical page: https://pyrosoft.pro/software/steam-command-generator Status: active Platforms: Web Steam Command Generator turns a Steam App ID into ready-to-copy Steam console commands. Type an App ID, or pick one of PyroSoft's own games under Quick try, and it fetches the game's name and details from the Steam Store API, then lays out the commands you're most likely to need. You get download_depot lines for the Windows, macOS and Linux depots, worked out with a simple depot-numbering heuristic (the App ID, then +1 and +2), app_info_request, app_info_print and app_status for app details, licenses_for_app and license_for_app for license checks, and download lines for the game's first five DLCs. You can add a command for any other depot ID, copy a single line, or copy everything at once. It's a free web tool that runs in any browser. The Quick try list features Rite of Eris, Polygone and StreamSavers. Price: Free. ## Features - Turns a Steam App ID into ready-to-copy console commands - download_depot lines for Windows, macOS and Linux using platform depot heuristics - app_info_request, app_info_print and app_status commands - licenses_for_app and license_for_app license checks - Download commands for up to five DLCs, named from the Steam Store - Add a download command for any depot ID you enter - Copy one command or Copy All - Quick try cards for Rite of Eris, Polygone and StreamSavers ## How to get it - [Open web app]() - [Project website]() ## Recorded details - First release: July 2026 - Tech: HTML, CSS and JavaScript; Steam Store API ## Screenshots ![Steam Command Generator with an App ID field and three Quick try cards](https://pyrosoft.pro/store-assets/media/7cd21a9fa0-960.webp) ![Steam Command Generator showing download commands for Rite of Eris](https://pyrosoft.pro/assets/images/steamcg_results.png) ![Steam Command Generator on a phone-width screen](https://pyrosoft.pro/store-assets/media/b67deac1e2-960.webp) ## Related guides and journals - [Steam Command Generator: useful commands with the right expectations](https://pyrosoft.pro/blog/steam-command-generator-useful-commands-with-the-right-expectations.md) --- # StreamSavers > A desktop-overlay idle RPG where Twitch chat unleashes chaos. Canonical page: https://pyrosoft.pro/software/streamsavers Status: beta Platforms: Windows StreamSavers is an idle RPG that runs on your desktop. The current version, StreamSavers Desktop, sits on top of everything as a transparent, always-on-top overlay: heroes fight waves, hatch from eggs, equip loot and level up while you use your PC, and running Windows apps can spawn enemies based on their icons. It reacts to your activity using counts only, never the content of your screen. It is made with streamers in mind. Twitch chat appears in the game world, emotes become targets your heroes can attack, viewers can type !enemy to spawn foes, and an OBS browser-source mode is built in. The developer's March 2026 announcement lists five zones from Desktop Wastes to Void Kernel, collectible characters, 46 egg variants, spells, quest chains and full equipment and inventory. StreamSavers began in 2020 on itch.io as a GameMaker idle game that sat in your YouTube or Twitch stream, and it entered Early Access on Steam in January 2021. In March 2026 it was rewritten from scratch as StreamSavers Desktop, a single portable Windows executable. That Early Access build is, in the developer's words, a focused slice: the core idle loop, a tutorial, the shop, quests and save/load with backups. Camp, bounties, formation, prestige and other systems are planned for later updates, and the Steam store page describes that fuller design, including viewer reward effects. Price: $9.99. ## Requirements 64-bit Windows 10, 2 GB RAM, broadband internet, 512 MB storage (minimum) ## Features - Transparent, always-on-top overlay: heroes fight on your real desktop - Running Windows apps can spawn enemies based on their icons - Twitch chat appears in-world; emotes become targets and !enemy spawns foes - Hatch collectible heroes from 46 egg variants - Five zones, from Desktop Wastes to Void Kernel - Activity tracking uses counts only, never the content of your screen - One portable Windows EXE, no installer, with built-in OBS browser-source mode - Early Access slice: idle loop, tutorial, shop, quests and save/load with backups ## How to get it - [Steam]() ## Recorded details - First release: Beta on itch.io Sep 25, 2020; on Steam Jan 20, 2021 - Tech: Desktop (2026): its own engine; original: GameMaker Studio 2 ## Screenshots ![StreamSavers main menu with Idle RPG modes and Fire Elemental, Pumpkin Head and Zombie Mummy character panels](https://pyrosoft.pro/store-assets/media/1c09e16ff1-960.webp) ![StreamSavers characters and status bars along the bottom of a video with a face camera overlay](https://pyrosoft.pro/store-assets/media/28fb88b23f-960.webp) ![StreamSavers forest main menu with Idle RPG, Battle Royale and Settings buttons, characters and coins](https://pyrosoft.pro/store-assets/media/bbf6c2feeb-960.webp) ![Original StreamSavers shop panel with eggs counting down to hatch](https://pyrosoft.pro/store-assets/media/streamsavers/streamsavers-r1.png) ![A crowd of StreamSavers cartoon heroes: knights, wizards, mummies, a pumpkin head and more](https://pyrosoft.pro/software/art/streamsavers.jpg) ![Original StreamSavers main menu and Twitch settings panel](https://pyrosoft.pro/store-assets/media/f8521d4db2-960.webp) ## Questions ### Do I have to be streaming to play? No. Its Steam store page describes it as a living desktop companion and a collection RPG as well as a stream-powered game; it runs on your desktop while you work, play or stream. ### Does it look at what's on my screen? No. It reacts to activity using counts only, for clicks, scrolling and window swaps, never the content on your screen. ### Is there an installer? No. StreamSavers Desktop is a single portable Windows executable you can run from anywhere. ### Is StreamSavers finished? No. It is in Early Access. The March 2026 StreamSavers Desktop build is a focused slice (core idle loop, tutorial, shop, quests and save/load with backups); camp, bounties, formation, prestige and other systems are planned for regular updates. --- # UE5 Action Adventure > Create your own 3rd Person action adventure game with Blueprints and Unreal 5's features! Canonical page: https://pyrosoft.pro/software/ue5-action-adventure-course Status: active A GameDev.tv online course taught by Mike Rodriguez. You make your own third-person action adventure game in Unreal Engine 5.1, scripting every part of it with Blueprints: movement and physics, pickups and interactables, enemy AI and behavior trees, raycast weapons, health and destruction, lighting, user interface and packaging. It uses MetaHumans for characters, Quixel Bridge for assets, and Nanite and Lumen for the look. By the end of the course you'll have your own playable level, complete with hazards, obstacles, pickups and interactables. 12 hours, 83 lectures, intermediate level. Price: On GameDev.tv. ## Features - Build your dream 3rd person action adventure game in UE5. - Use Unreal Blueprints for easy yet powerful game scripting. - Craft stunning levels with MetaHumans, Nanite, and Lumen. - Design gameplay with raycasting for cool shooting mechanics. - Create interactive environments with dynamic obstacles and hazards. - Learn to manage game events, enemy AI, and object movements. - Dive deep into UE5's latest tools like Quixel Bridge for assets. - Tackle game design challenges to hone your skills. ## How to get it - [Take the course on GameDev.tv]() ## Course details - Provider: GameDev.tv - Title: UE5 Action Adventure: Make Your Own Action Adventure Game In Unreal - Instructor: Mike Rodriguez - Hours: 12 - Lectures: 83 - Level: Intermediate - Engine: Unreal Engine 5.1 - Tools: MetaHumans, Quixel Bridge, Nanite, Lumen - Language: en ## Screenshots ![Course cover: “Forge Action Adventures” above a third-person character walking a jungle path](https://pyrosoft.pro/store-assets/media/48442c235a-960.webp) --- # Virtual Audio Driver > Add a virtual speaker and virtual microphone to your Windows device. Canonical page: https://pyrosoft.pro/software/virtual-audio-driver Status: active Platforms: Windows Virtual Audio Driver adds two devices to Windows 10 and 11: a virtual speaker and a virtual microphone. Windows sees them as ordinary sound hardware, which helps on headless machines, in remote desktop and game-streaming setups, and when you need to test audio software without plugging anything in. The speaker accepts formats from 8-bit, 8,000 Hz up to 32-bit, 192,000 Hz and works with Windows Sonic spatial sound. The microphone offers 16-, 24- and 32-bit formats up to 192 kHz and works with Windows audio enhancements such as Voice Focus. Apps can take exclusive control of either device, and the speaker follows the Windows volume mixer per app. It is built with the Windows Driver Kit on Microsoft's Sysvad audio sample, and release 25.7.14 is code-signed through SignPath. The driver is free and open source under the MIT licence, and Virtual Driver Control can install and enable it alongside the Virtual Display Driver. Price: Free. ## Requirements Windows 10 build 1903 or later, or Windows 11. x64 tested; ARM64 listed. Only test-signed builds need test signing. ## Features - A virtual speaker (playback) and a virtual microphone (recording) device - Speaker formats from 8-bit, 8,000 Hz up to 32-bit, 192,000 Hz - Microphone formats: 16-bit 44.1/48 kHz, 24-bit 96/192 kHz, 32-bit 48 kHz - Windows Sonic spatial sound on the virtual speaker - Microphone works with Windows enhancements such as Voice Focus - Exclusive mode, application priority and per-app volume - Windows 10 (1903+) and Windows 11; x64 tested, ARM64 listed - Signed release (25.7.14) via SignPath; installable from Virtual Driver Control ## How to get it - [Source code]() - [Download on GitHub]() ## Recorded details - Version: 25.7.14 - License: MIT (Microsoft sample code: MS-PL) - Updated: 2026-03-03 - First release: 25.1.2 (January 2025) - Tech: C++ and C, Windows Driver Kit (Sysvad sample) ## Screenshots ![Windows 11 Sound properties for the virtual Speakers (Virtual Audio Driver by MTT), 32-bit 48 kHz](https://pyrosoft.pro/assets/images/audiodriver.png) ![Windows 11 microphone properties for the Virtual Audio Driver with Voice Focus on](https://pyrosoft.pro/store-assets/media/virtual-audio-driver/virtual-audio-driver-r2.png) ![Three Device Manager property sheets for the Virtual Audio Driver devices](https://pyrosoft.pro/store-assets/media/d8b2f33607-960.webp) ## Questions ### Where do the new devices show up? In Device Manager, 'Virtual Audio Driver' (speaker) appears under Sound, video and game controllers and 'Virtual Mic Driver' (microphone) under Audio inputs and outputs. In Sound Settings, pick them under Output and Input. ### Do I need to enable test signing? Only for test-signed builds. The README still carries a beta warning about test signing, but notes that a production-signed driver can skip it; release 25.7.14 is labelled Signed (SignPath). ### How do I install it by hand? In Device Manager choose Action > Add legacy hardware, pick the hardware from a list, choose Sound, video and game controllers, click Have Disk and select VirtualAudioDriver.inf. ### Can I change the sample rate? Yes. In the speaker's Properties > Advanced tab choose any format from 8-bit, 8000 Hz up to 32-bit, 192000 Hz. ## Related guides and journals - [Making the audio driver's foundations explicit](https://pyrosoft.pro/blog/making-the-audio-driver-s-foundations-explicit.md) - [Rolling back the effects experiment](https://pyrosoft.pro/blog/rolling-back-the-effects-experiment.md) - [Exploring more formats, channels and audio controls](https://pyrosoft.pro/blog/exploring-more-formats-channels-and-audio-controls.md) - [Virtual audio endpoints for a computer without speakers](https://pyrosoft.pro/blog/virtual-audio-endpoints-for-a-computer-without-speakers.md) --- # Virtual Display Driver > Add virtual monitors to Windows 10/11 for VR, OBS, Sunshine and screen sharing. Canonical page: https://pyrosoft.pro/software/virtual-display-driver Status: active Platforms: Windows Virtual Display Driver adds virtual monitors to Windows 10 and 11. Windows treats each one like a physical display, so it appears in Display Settings and can be used by game-streaming hosts such as Sunshine, by OBS, by VR desktop apps and for remote access to machines that have no monitor attached. Each virtual display can run the standard resolutions from 640 x 480 to 7680 x 4320 (8K), plus custom modes you add yourself, including ultrawide sizes. Refresh rates include 60, 144, 240 and 500 Hz, and fractional rates such as 59.99 Hz. Custom EDIDs let it present itself as a specific monitor, and HDR is available on Windows 11 23H2 and later. Settings live in one file, C:\VirtualDisplayDriver\vdd_settings.xml, which you can edit by hand or through Virtual Driver Control. The driver is built on Microsoft's Indirect Display Driver framework (IddCx), ships for x64 and ARM64, and is code-signed through SignPath. It is free and open source under the MIT licence, maintained by MikeTheTech with Jocke (zjoasan), and can also be installed with winget. Price: Name your price. ## Requirements Windows 10 or 11; Microsoft Visual C++ Redistributable. HDR needs Windows 11 23H2+ (IddCx 1.10). ARM64 on Windows 11 24H2+ may need test signing, and ARM64 users install manually or with the community scripts. ## Features - Virtual monitors that Windows treats like physical displays - Resolutions from 640 x 480 to 8K, plus custom and ultrawide modes - Refresh rates including 240, 480 and 500 Hz, plus fractional rates like 59.99 Hz - Custom EDIDs to emulate a specific monitor - HDR (10/12-bit) on Windows 11 23H2 and later; SDR in 8 or 10-bit - Hardware cursor and a choice of which GPU renders the displays - x64 and ARM64 builds, code-signed through SignPath - Set up with Virtual Driver Control, vdd_settings.xml or winget ## How to get it - [itch.io]() - [Source code]() ## Recorded details - Version: 25.7.23 - License: MIT - Updated: 2026-10-05 - First release: October 2023 (23.10.14.4) - Tech: C++ and C, IddCx 1.10 (user mode) ## Screenshots ![Windows 11 Display settings with four displays arranged and the large display 4 selected](https://pyrosoft.pro/software/art/vdd.jpg) ![Windows display information showing a virtual display at 7680 by 4320 and 120 Hz](https://pyrosoft.pro/store-assets/media/virtual-display-driver/virtual-display-driver-r1.png) ![Device Manager listing Virtual Display Driver by MTT under Display adapters](https://pyrosoft.pro/store-assets/media/virtual-display-driver/virtual-display-driver-r2.png) ![Virtual Driver Control on a Windows desktop: the main window with its command console, the Virtual Display Driver XML editor, and the tray menu for driver options](https://pyrosoft.pro/store-assets/media/7a3f8b6416-960.webp) ![vdd_settings.xml with monitor count, GPU and refresh rate settings](https://pyrosoft.pro/store-assets/media/0e9023342b-960.webp) ## Questions ### How do I install it? Download Virtual Driver Control 25.7.23 (the Virtual Driver Control page links its GitHub release), extract it to a folder, run it and click Install. You can confirm the driver under Display adapters in Device Manager. It is also available with: winget install --id=VirtualDrivers.Virtual-Display-Driver -e ### Does HDR work on Windows 10? No. HDR needs IddCx 1.10, which is only available on Windows 11 23H2 or later, so Windows 10 systems run the virtual displays in SDR. ### Where are the settings stored? In C:\VirtualDisplayDriver\vdd_settings.xml. You can edit resolutions, refresh rates and options there by hand, or use Virtual Driver Control. ### I get a black screen after updating my GPU driver. What now? Uninstall VDD before major GPU or chipset driver updates. If you are already stuck, boot into Safe Mode, uninstall Virtual Display Driver under Display adapters in Device Manager and restart; pressing Win+P and cycling display modes can also bring your screen back. ### Does it run on ARM64? Yes, ARM64 builds are published. On Windows 11 24H2 or later ARM64 may require test signing, and the 25.7.23 notes say ARM64 users still install manually or with the community PowerShell scripts. ### It says vcruntime140.dll was not found. Install the latest Microsoft Visual C++ Redistributable, which the driver needs. ## Related guides and journals - [Safer monitor lifetimes and clearer driver replies](https://pyrosoft.pro/blog/safer-monitor-lifetimes-and-clearer-driver-replies.md) - [More precise GPU selection and multi-monitor corrections](https://pyrosoft.pro/blog/more-precise-gpu-selection-and-multi-monitor-corrections.md) - [Building the tools around the display driver](https://pyrosoft.pro/blog/building-the-tools-around-the-display-driver.md) - [Fine-tuning the virtual display](https://pyrosoft.pro/blog/fine-tuning-the-virtual-display.md) - [HDR and choosing the GPU behind the virtual screen](https://pyrosoft.pro/blog/hdr-and-choosing-the-gpu-behind-the-virtual-screen.md) - [A monitor without another panel on the desk](https://pyrosoft.pro/blog/a-monitor-without-another-panel-on-the-desk.md) --- # Virtual Driver Control > One app to control and configure VirtualDrivers tools. Canonical page: https://pyrosoft.pro/software/virtual-driver-control Status: active Platforms: Windows Virtual Driver Control (VDC) is the companion app for the Virtual Drivers on Windows. From one window it installs, uninstalls, enables and disables the Virtual Display Driver and the Virtual Audio Driver, and its tray menu gives quick access to display options such as HDR+, SDR 10-bit, custom EDID, hardware cursor and GPU selection. Version 25.7.23 is a portable, code-signed build with no installer: extract it and run it. It has a command console, a Reload Driver action in every context menu and an early XML editor for vdd_settings.xml, where you set the monitor count, default GPU, resolutions and refresh rates. ARM64 users still install the drivers manually. VDC first shipped as a beta alongside Virtual Display Driver 25.5.2 in May 2025. It is free, and installing the Virtual Display Driver with winget sets up the same portable 25.7.23 app. Price: Free. ## Requirements Windows 10 or 11 (x64). ARM64 users install the drivers manually or with the community scripts. ## Features - Install and uninstall the Virtual Display and Virtual Audio drivers - Enable, disable and reload each driver from the app and its context menus - Tray menu for HDR+, SDR 10-bit, custom EDID, hardware cursor and GPU choice - XML editor (alpha) for monitor count, default GPU, resolutions and refresh rates - Command console with a HELP list of driver commands - Portable and code-signed: no installer needed ## How to get it - [Source code]() - [Download on GitHub]() ## Recorded details - Version: 25.7.23 (beta) - License: No licence file - Updated: 2026-06-12 - First release: 25.5.2, May 2025 (beta from January 2025) - Tech: C# Windows Forms, .NET 6 (25.5.2) ## Screenshots ![Virtual Driver Control on a Windows desktop: the main window with its command console, the Virtual Display Driver XML editor, and the tray menu for driver options](https://pyrosoft.pro/store-assets/media/7a3f8b6416-960.webp) ## Questions ### Is there an installer? Not since 25.7.23: Virtual Driver Control is a portable app. Extract the zip to a folder, run it and click Install to set up the display driver. ### Can it install the audio driver too? Yes. The 25.7.23 build includes the signed Virtual Audio Driver and can install, uninstall, enable and disable it. ### Does it work on ARM64? The 25.7.23 notes say ARM64 users still need the manual installation method or the community PowerShell scripts. ## Related guides and journals - [A rebuilt panel with displays, audio and an EDID lab](https://pyrosoft.pro/blog/a-rebuilt-panel-with-displays-audio-and-an-edid-lab.md) - [Moving the panel behind a clearer application boundary](https://pyrosoft.pro/blog/moving-the-panel-behind-a-clearer-application-boundary.md) - [Reconnecting the interface and fixing driver detection](https://pyrosoft.pro/blog/reconnecting-the-interface-and-fixing-driver-detection.md) - [Connecting the panel to everyday driver tasks](https://pyrosoft.pro/blog/connecting-the-panel-to-everyday-driver-tasks.md) - [A control panel for the settings behind the driver](https://pyrosoft.pro/blog/a-control-panel-for-the-settings-behind-the-driver.md) --- # Virtual Driver Installer > Inno Setup source for the Virtual Display Driver installer. Canonical page: https://pyrosoft.pro/software/virtual-driver-installer Status: active Platforms: Windows Virtual Driver Installer is the source of the Windows setup program for the Virtual Display Driver: an Inno Setup script together with the PowerShell and batch helpers, driver tools and test scripts it needs, kept in one repository. The script installs the driver files and Virtual Driver Control to C:\VirtualDisplayDriver. If it finds an existing vdd_settings.xml it asks whether to keep your settings or replace them with the defaults, it can launch Virtual Driver Control when it finishes, and uninstalling runs the driver's own uninstall script. The Virtual Display Driver's setup program last shipped with release 25.5.2 in May 2025, as Virtual.Display.Driver-v25.05.03-setup-x64.exe. Release 25.7.23 moved to a portable Virtual Driver Control that installs the drivers itself, while work on this script continued into August 2025. This repository has no releases of its own. Price: Free. ## Features - Inno Setup script with the modern wizard, installing to C:\VirtualDisplayDriver - Keeps or replaces an existing vdd_settings.xml, your choice - Optionally launches Virtual Driver Control when setup finishes - Uninstall runs the driver's own uninstall script - Build script set up to stamp a date-based (yy.MM.dd) version - Nine test scripts comparing devcon, nefconw, pnputil and PowerShell installs ## How to get it - [Source code]() ## Recorded details - Updated: 2025-08-17 - Tech: Inno Setup, PowerShell and batch ## Screenshots ![GitHub view of Setup.iss lines 1 to 27 with the repository file tree](https://pyrosoft.pro/store-assets/media/5a0fec4ae6-960.webp) ## Questions ### Is there a ready-made installer to download here? Not in this repository, which has no releases. A setup program, Virtual.Display.Driver-v25.05.03-setup-x64.exe (5.26 MB), was published with Virtual Display Driver 25.5.2; since 25.7.23 the drivers are installed from the portable Virtual Driver Control app instead. ### Will reinstalling overwrite my settings? Not unless you choose to: when vdd_settings.xml already exists, setup offers 'Keep my existing settings (recommended)' or 'Overwrite with new default settings'. --- # VirtualBT > A Windows-host Bluetooth server that simulates input devices. Canonical page: https://pyrosoft.pro/software/virtualbt Status: active Platforms: Windows VirtualBT is an early project that turns a Windows PC into a Bluetooth input device. It runs a Bluetooth Low Energy server on the PC so that phones, game consoles and other devices that accept Bluetooth peripherals can pair with it as if it were a keyboard. Today it scans for nearby devices, pairs using a security PIN, connects as a standard input peripheral and forwards keystrokes from your physical keyboard to paired devices while the app is in focus. Mouse and gamepad emulation are planned, and work had started on NXBT integration for Nintendo Switch support and Linux. It is written in C# on Microsoft's BluetoothLEExplorer and GattServicesLibrary samples and licensed under GPL-3.0. The Virtual Drivers team describes it as still very early and not fully functional, and the last code change was in October 2024. Price: Free. ## Requirements Bluetooth Low Energy capable hardware ## Features - Makes a Windows PC appear as a Bluetooth LE keyboard to other devices - Scans for nearby Bluetooth devices and pairs using a security PIN - Forwards your keystrokes to paired devices while the app is in focus - Discoverable switch and a list of subscribed clients - Built on Microsoft's BluetoothLEExplorer and GattServicesLibrary - Planned: mouse and gamepad emulation, NXBT for Nintendo Switch and Linux ## How to get it - [Source code]() ## Recorded details - License: GPL-3.0 - Updated: 2024-10-13 - First release: Sep 19, 2024 (repository created) - Tech: C#, Windows Bluetooth LE APIs ## Screenshots ![VirtualBT Virtual Keyboard page with a Discoverable switch and a clients list](https://pyrosoft.pro/store-assets/media/a13e603dbb-960.webp) ## Questions ### Can it act as a mouse or a game controller yet? Not yet. Keyboard input is supported today; the README lists mouse and gamepad emulation as future enhancements and NXBT (Nintendo Switch) integration as work in progress. ### Which devices can it connect to? The goal is any device that supports Bluetooth input peripherals, such as smartphones and game consoles. The README notes some Android devices may need a Bluetooth radio toggle after the Discoverable switch is changed. --- # DevZIP > A Windows-first archiver with a native C++ engine. Canonical page: https://pyrosoft.pro/software/devzip Status: active Platforms: Windows DevZIP is a Windows-first archiver built around a native C++ engine and its own readable .dvz container format. It is aimed at one goal: the smallest possible archives for mixed, real-world data, without the format becoming unreadable as the engine evolves. The engine packs files solid by type, removes duplicates at the file and block level, and runs content-aware transforms before compressing: a lossless JPEG transcoder, a PNG and zip deflate-undo step, and executable filters. Four levels (fast, balanced, max and insane) trade time for size. The fast level uses LZMA2 alone; from balanced upward, each block is compressed by several codecs and the smallest result wins, with the winning codec stamped into the archive so it always extracts. DevZIP also has its own clean-room context-mixing codec, DZCM, available as an opt-in backend. The project's own notes are candid that this costs CPU time: in its own benchmark sweep the max level makes archives 18% smaller than 7-Zip's LZMA2 (balanced, the default, 11.7%), at roughly 20 to 45 times the compression time. There's a command-line tool for compress, extract and verify, and a WPF desktop shell for Windows. The source is public on GitHub under the DevZIP Non-Commercial License 1.0: free for personal, academic and other non-commercial use, with a separate licence for commercial use. Price: Free. ## Requirements Build from source: CMake for the native engine and CLI, .NET (dotnet build) for the WPF app; no prebuilt binaries ## Features - Native C++ engine with a readable, self-describing .dvz (v4) archive format - CLI with compress, extract and verify, plus --level and --backend options - Levels fast, balanced, max and insane; balanced picks LZMA2 or ZPAQ-5 per block - Content-aware transforms for JPEG (brunsli), PNG (preflate) and executables (BCJ) - Solid packing by file type with file- and block-level deduplication - DZCM, DevZIP's own clean-room context-mixing codec (opt-in backend) - WPF desktop shell for Windows that drives devzip_cli.exe - Benchmark harness included; up to 18% smaller archives than 7z-lzma2 in its own tests ## How to get it - [Source code]() ## Recorded details - License: Non-commercial licence - Updated: 2026-06-05 - First release: Source published Apr 13, 2026 - Tech: C++ engine and CLI, C# (WPF) desktop shell ## Questions ### Is DevZIP open source? It's source-available under the DevZIP Non-Commercial License 1.0. Non-commercial use, study, modification and redistribution are allowed; commercial use needs a separate written licence. It is not an OSI-approved licence. ### Why is it slower than 7-Zip? DevZIP buys smaller archives with CPU time: ZPAQ-5 context mixing and the PNG preflate path dominate. Decompression is fast at every level, and --level fast runs close to 7-Zip's speed when size matters less. ### How does it compare with other compressors? In the project's own sweep (97.41 MB of text, code, executables, JPEG and PNG on a Ryzen 5900X), DevZIP max produced 44.561 MB against 54.317 MB for 7z LZMA2 and 52.503 MB for kanzi -l9, the strongest general-purpose rival tested. The lead comes from content-aware transforms for JPEG and PNG; the docs are candid that kanzi -l9 still beats DevZIP's current backend on raw code (0.151 vs 0.162 MB) and executables (6.792 vs 6.930 MB). ### What is DZCM, and is it on by default? DZCM is DevZIP's own context-mixing codec, written from scratch for the project. It isn't in any level's default codec pool: you pick it with --backend dzcm or add it to a best-of-N pool (for example best-of-n:lzma2,zpaq5,dzcm), where it can only help because the smallest block wins. In the project's tests it beats LZMA2 by about 30% on text and 7% on code, but it trails on executables and doesn't yet beat ZPAQ-5. ## Related guides and journals - [DZCM: a context-mixing codec of our own](https://pyrosoft.pro/blog/dzcm-a-context-mixing-codec-of-our-own.md) - [Compression levels and the cost of a smaller archive](https://pyrosoft.pro/blog/compression-levels-and-the-cost-of-a-smaller-archive.md) - [DevZIP opens up its archive engine](https://pyrosoft.pro/blog/devzip-opens-up-its-archive-engine.md) --- # Bambi3D > Print the things you care about. Canonical page: https://pyrosoft.pro/software/bambi3d Status: coming-soon Platforms: Web Bambi3D is PyroSoft's studio for customisable 3D prints. You configure an object in your browser and print it yourself, and every piece ends up as the same kind of thing: a framed, sealed relief with your own words raised on the rail, ready to hang. The hanger is cut into the solid rather than stuck on: a keyhole that takes a screw head and sits flat against the wall, a plain nail hole on rails under 13 mm, or no hanger at all if you'd rather. Each model is built as a solid with its voids already in it, then checked (every edge matched, every normal facing out) before it can leave the page. Exports are tuned for Bambu Studio and the AMS, carrying the plate, the filament assignments and a matching profile, with plain files for any other slicer. Every plate is signed with a small 'Generated with ♥ at Bambi3D.com' mark engraved into its underside. BambiMaps, which turns real streets and terrain into a framed city relief, is the first studio: built and waiting on launch. BambiPeaks, BambiTracks, BambiStars and BambiWaves are planned on the same frame, lettering and export engine, and none of them works yet. Both sites are live, but the designer and downloads aren't open yet, and pricing hasn't been published. Price: Price TBA. ## Requirements No Bambu printer needed: the 3MF is tuned for Bambu Studio and the AMS, and plain files work in any slicer ## Features - Configure a framed, hangable relief in the browser; no 3D modelling needed - Sealed solids, checked before export: matched edges, outward normals, positive volume - Bambu-ready 3MF with plate, filament assignments and profile; files for other slicers - Rectangle, oval or heart frames with your words on the rail or a ribbon - Hanger cut into the solid: keyhole, nail hole on rails under 13 mm, or none - BambiMaps first; BambiPeaks, BambiTracks, BambiStars and BambiWaves planned - Every plate signed 'Generated with ♥ at Bambi3D.com' on its underside ## How to get it Coming soon. Use the product page and development journal for current status. - [Open web app]() - [Project website]() ## Recorded details - Tech: In-browser model builder; OpenStreetMap and AWS Terrain Tiles data ## Screenshots ![A BambiMaps model of Nob Hill, San Francisco on a build plate: white buildings over real terrain in a walnut frame with “Our First Date <3” raised on the rail](https://pyrosoft.pro/store-assets/media/fe5e196116-960.webp) ![The back of a BambiMaps piece: a flat underside with the engraved Bambi3D mark and a keyhole hanger cut into the walnut rail](https://pyrosoft.pro/store-assets/media/de2286e3db-960.webp) ![bambimaps.com hero with the headline Print the place you love beside a live Nob Hill model in a walnut frame](https://pyrosoft.pro/store-assets/media/a6e4e11dda-960.webp) ![The Real places, real models section: a live Nob Hill relief next to five worked example cards](https://pyrosoft.pro/store-assets/media/ae2f4e162c-960.webp) ![bambi3d.com product shelf: line-drawn cards for BambiMaps (Coming soon) and planned products marked In the workshop](https://pyrosoft.pro/store-assets/media/76cd14be13-960.webp) ## Questions ### What is Bambi3D, exactly? A small studio building customisable 3D prints: objects you configure in your browser and print yourself. Every product ends up as a framed piece you can hang. BambiMaps, which makes framed city reliefs, is the first one. ### Can I use it today? Not yet. Both sites are live, but the designer sits behind a launch gate while it finishes testing. You can explore the real example models on bambimaps.com and leave an email to hear the day it opens. ### Do I need a Bambu printer? No. The 3MF is tuned for Bambu Studio and the AMS, but every export also includes plain files that any slicer will open. ### Do I need to know 3D modelling? None at all. You pick a place or a moment, choose a frame and type your words; the model is built for you and checked before you get it. ### Can I sell what I print? Personal prints are yours to keep and give away. A commercial licence covers selling prints and lets you change or remove the small mark engraved into the back of the plate. --- # BambiMaps > Print the place you love. Canonical page: https://pyrosoft.pro/software/bambimaps Status: coming-soon Platforms: Web BambiMaps is the first Bambi3D studio. Search for a place, drag a box over it and pick a frame, and it builds that patch of the world as a framed relief: OpenStreetMap buildings at their real heights, terrain from AWS Terrain Tiles, streets, water and parks, and your own lettering raised on the rail. The result is made for printing, not just for looking at. Heights snap to whole layers for your nozzle, landmarks rise through the frame without supports, and a keyhole hanger is recessed into the back (rails under 13 mm get a plain nail hole instead). It exports a Bambu Studio 3MF with each layer on its own AMS slot, or a plain STL for any slicer, with the real plate sizes of the X1 Carbon, X1E, P1S, P1P, A1, A1 mini and H2D built in. bambimaps.com shows five worked examples (Nob Hill, the Eiffel Tower, the Las Vegas Convention Center, Laguna Seca and Battersea), each rebuilt live in your browser, and a short animated film of the workflow from map to print. The designer itself is in its last stretch of testing behind a launch gate, and pricing hasn't been published. Price: Price TBA. ## Requirements The STL prints on any printer; the 3MF has real plate sizes for Bambu X1 Carbon, X1E, P1S, P1P, A1, A1 mini and H2D ## Features - Real OpenStreetMap building footprints and heights, with tower setbacks - Terrain from AWS Terrain Tiles, as fine as 1-3 m where lidar exists - Rectangle, heart or oval frames; six rail profiles and four size presets - Raised lettering on the rail or a ribbon; the place name is filled in for you - Heights snap to whole printer layers; details finer than the nozzle are dropped - 3MF with each layer on its own AMS slot, or a plain STL; keyhole hanger built in - Built-in plates for Bambu X1 Carbon, X1E, P1S, P1P, A1, A1 mini and H2D - Five worked examples rebuilt live in the browser ## How to get it Coming soon. Use the product page and development journal for current status. - [Open web app]() - [Project website]() ## Recorded details - Tech: OpenStreetMap buildings, AWS Terrain Tiles elevation; built in the browser ## Screenshots ![BambiMaps relief of Nob Hill, San Francisco: dense white buildings rising over real hills in a walnut frame lettered SAN FRANCISCO](https://pyrosoft.pro/store-assets/media/0b68e95320-960.webp) ![A BambiMaps model of Nob Hill, San Francisco on a build plate: white buildings over real terrain in a walnut frame with “Our First Date <3” raised on the rail](https://pyrosoft.pro/store-assets/media/fe5e196116-960.webp) ![The bambimaps.com landing page today: a Coming soon badge, the headline Print the place you love, an email signup and the live Nob Hill model](https://pyrosoft.pro/store-assets/media/a6e4e11dda-960.webp) ![The Real places, real models section: a live Nob Hill relief next to five worked example cards](https://pyrosoft.pro/store-assets/media/ae2f4e162c-960.webp) ![A BambiMaps relief of Paris: the Eiffel Tower, the Champ de Mars in green and the Seine in blue inside an ornate walnut frame lettered PARIS](https://pyrosoft.pro/store-assets/media/048367c647-960.webp) ![BambiMaps relief of Laguna Seca raceway: the circuit raised in red over dark hilly terrain in a stepped walnut frame](https://pyrosoft.pro/store-assets/media/b00c5c9643-960.webp) ![BambiMaps relief of the Las Vegas Convention Center halls and surrounding towers in a slim walnut frame lettered LAS VEGAS](https://pyrosoft.pro/store-assets/media/96d77808bd-960.webp) ![BambiMaps heart-shaped frame around Battersea, London, with a raised ribbon lettered BATTERSEA](https://pyrosoft.pro/store-assets/media/8a90fcad38-960.webp) ## Questions ### Does it work on my printer? X1 Carbon, X1E, P1S, P1P, A1, A1 mini and H2D are built in, each with its real plate size; if a design won't fit you get a one-click resize. The STL prints on anything. ### Can I do a heart, or a ribbon with a name on it? Yes. Alongside the rectangle there are heart and oval silhouettes, and a heart crops the map rather than stretching it. Any shape can carry a ribbon banner. Terrain relief is rectangles-only; hearts and ovals print flat. ### How big can I go? Anything from a 100 mm coaster to a 300 mm statement piece. Roughly half a kilometre to three kilometres of ground across gives the best-looking prints. ### Where does the data come from? Building footprints and heights from OpenStreetMap, elevation from AWS Terrain Tiles. Google Maps is only the backdrop for picking your area. ### Can I use it today? Not yet. The examples, how it works and ideas are public; the designer is still behind a launch gate. Leave an email on the site to hear the day it opens. --- # Bourbon OS > Power on. Straight into Steam. Canonical page: https://pyrosoft.pro/software/bourbon-os Status: coming-soon Platforms: Linux, macOS Bourbon OS is PyroSoft's lean ARM64 gaming operating system, styled after SteamOS and built on Fedora 44. It signs itself in and opens Valve's native ARM64 Steam client in Game Mode, with FEX translating x86 game code and Proton running Windows games through Steam. There is no desktop in the way, and no Steam account, games or purchases are baked into the image. It is headed for Bourbon 26 as a Steam appliance. Bourbon sets it up as a virtual machine on stock UTM, sized to your Mac, keeps your Steam library in a folder outside the VM so a reset leaves your games alone, and uses a guest agent to check on it, restart Steam, launch a game you own or run a repair. Inside Bourbon 26 it has been labelled Bourbon Linux (SteamOS). Bourbon OS is in internal testing and isn't available to download yet. Setup stays locked until a validated image ships, there is no date, and no performance figures have been published. Price: Coming to Bourbon 26. ## Requirements ARM64 (aarch64) only; main target is a UTM or QEMU virtual machine on an Apple Silicon Mac ## Features - Valve's native ARM64 Steam client, opening in Game Mode - FEX for x86 and x86-64 game code; Proton via Steam for Windows games - Console-style boot: UEFI, automatic sign-in, Openbox, then Steam - Mesa Vulkan and OpenGL, PipeWire audio, GameMode and Steam Input - Root filesystem grows on boot into a bigger VM disk - Steam library kept outside the VM, so resetting it leaves your games alone - VM image (qcow2) for UTM and QEMU; installer ISO not released ## How to get it Coming soon. Use the product page and development journal for current status. ## Recorded details - License: Proprietary (source private) - Tech: Fedora 44 (aarch64), FEX, Proton, Mesa, Gamescope, PipeWire ## Screenshots ![Bourbon 26 Experimental page listing the Windows 11 ARM64 and Bourbon Linux (SteamOS) virtual-machine experiments, both switched off](https://pyrosoft.pro/store-assets/media/d8a8039187-960.webp) ![The Supermarket Chaos title menu inside a UTM window titled Bourbon Linux on a Mac, captured during internal Bourbon OS testing](https://pyrosoft.pro/store-assets/media/2f7e3a91ff-960.webp) ## Questions ### Can I download Bourbon OS? Not yet. There is no public build. Bourbon OS is coming to Bourbon 26, which will set it up as a virtual machine once a freshly baked image passes its final boot test. There's no date. ### Is Bourbon OS SteamOS? No. It's PyroSoft's own OS, built on Fedora 44 and styled after SteamOS. It isn't made or endorsed by Valve. ### Why does Bourbon 26 call it Bourbon Linux? BourbonLinux is the project's code name; Bourbon OS is the brand. Inside Bourbon 26 the edition is labelled Bourbon Linux (SteamOS). ### Will my games run? Steam runs natively on ARM64, but no title is promised to work. Game code goes through FEX (and Proton for Windows games), and in a VM the graphics are paravirtualised. For Windows games on a Mac today, use Bourbon 26. --- # BurnFlix > Your whole media library, ready instantly. Canonical page: https://pyrosoft.pro/software/burnflix Status: coming-soon Platforms: Windows BurnFlix is a local-first media server that brings movies, TV shows, personal videos, games and apps into one library you can browse from the couch. It opens from a saved snapshot of your library, so you aren't waiting on a full rescan every time, while new files, metadata and artwork are picked up in the background. Scan errors never wipe your library, and removed files are only reconciled after a successful scan. BurnFlix enriches titles with provider metadata, caches covers, backdrops and video thumbnails locally, and gives games and emulators their own section with platform artwork. A Library Health view surfaces missing artwork, metadata gaps and setup issues, and recommendations come from your genres and what you watch most, not AI generation. BurnFlix is in development for Windows and hasn't been released yet. Price: Price TBA. ## Features - Opens instantly from a persisted local snapshot of your library - Background scans that never wipe the library on errors - Metadata from TMDB, OMDb, TheTVDB, IGDB and more, cached locally - Movies, TV, personal videos, games and apps in one interface - Video thumbnails extracted from your own recordings - Library Health: missing artwork, metadata gaps and setup issues - Recommendations from your own library, no AI generation ## How to get it Coming soon. Use the product page and development journal for current status. - [Project website]() ## Recorded details - Tech: React, Vite and Tailwind; Express on Node.js ## Screenshots ![BurnFlix home screen with media rows and cached artwork](https://pyrosoft.pro/store-assets/media/11c83f5a46-960.webp) ![BurnFlix Movies page with poster grid](https://pyrosoft.pro/store-assets/media/2577128c32-960.webp) ![BurnFlix TV Shows page](https://pyrosoft.pro/store-assets/media/240c8d6cf7-960.webp) ![BurnFlix Files section, shown with a sample library (stock-style thumbnails, generic titles)](https://pyrosoft.pro/store-assets/media/ec77983a0f-960.webp) ![BurnFlix Games page](https://pyrosoft.pro/store-assets/media/8cce775ee6-960.webp) ![BurnFlix Library Health page](https://pyrosoft.pro/store-assets/media/fde43da7c1-960.webp) ## Questions ### Can I download BurnFlix yet? Not yet. BurnFlix is in development, and the release will appear on burnflix.app when it's ready. If you need a media server today, PyroSoft's own guide recommends Jellyfin as the honest free option. ### How is it different from Plex or Jellyfin? BurnFlix loads the library from local cache first, so browsing never waits on a scan. It also keeps personal videos, games and apps in the same library as movies and shows, with metadata enrichment handled automatically. ### Does it depend on the cloud or a paid tier? PyroSoft's stated position is one local-first library with metadata enrichment built in, no cloud dependency and no tier that unlocks the real product. Pricing hasn't been announced. ### Does BurnFlix use AI? Metadata enrichment is built in; AI generation is deliberately not, and recommendations come from your own library. --- # EmberLink > One desk. Every computer. Canonical page: https://pyrosoft.pro/software/emberlink Status: coming-soon Platforms: macOS EmberLink shares one keyboard, mouse and clipboard across the computers on your desk. Arrange every monitor where it really sits, push the pointer across a touching edge, and your typing, scrolling and clipboard follow. Two modes cover different desks. In Extended mode each computer keeps its own monitor; Super Display opens another computer's desktop fullscreen on the screen you're already using, streamed as H.264 or HEVC over the same encrypted connection as your input. Computers pair directly on your local network over TLS, confirmed by a six-digit code you compare yourself, with no account and no cloud relay, and Esc always hands your keyboard and mouse back. EmberLink is an engineering preview. The current build, 26.9.8.8, is signed and notarized for Apple Silicon Macs; Windows and Linux support is written but hasn't been run on real machines yet, and there is no public download or announced price. Launch news goes out on the PyroSoft Discord. Price: Price TBA. ## Requirements Apple Silicon Mac (tested on macOS 26; oldest supported version not yet confirmed); Accessibility and Input Monitoring, plus Screen Recording for Super Display; computers on the same local network (TCP 24880 and 24881) ## Features - Extended mode: cross a touching monitor edge and your input follows - Super Display: another computer's desktop fullscreen, as H.264 or HEVC - Two-way clipboard: text, rich text, PNG images and up to 16 small files - Direct TLS connection on your own network: no account, no cloud relay - Pairing confirmed with a six-digit code; old invitations can be revoked - Esc stops sharing; held keys and buttons are released if the link drops - Activity log of connections and sessions, never keystrokes or clipboard - Streaming profiles up to 3,840 px wide, 15–120 fps and 1–150 Mbps ## How to get it Coming soon. Use the product page and development journal for current status. ## Recorded details - License: Proprietary - Tech: Qt/PySide6, FFmpeg (PyAV), ScreenCaptureKit, VideoToolbox ## Screenshots ![The EmberLink Workspace page: Extended and Super Display mode pills, a Start sharing button, and a display arrangement showing a Main Mac built-in display snapped beside a connected Studio Mac display](https://pyrosoft.pro/store-assets/media/e5e4a65375-960.webp) ![The EmberLink Modes page comparing Extended, one continuous physical workspace, with Super Display, every computer on your main screen, above panels on shared input and headless computers](https://pyrosoft.pro/store-assets/media/249a8eb163-960.webp) ![EmberLink's Welcome setup page with Enable Accessibility and Enable Input Monitoring buttons and a disabled Continue to pairing button](https://pyrosoft.pro/store-assets/media/4f562e5824-960.webp) ![EmberLink's Connect your computers page listing a nearby computer with a Pair button, this computer under On your desk, and a Can't find your computer link](https://pyrosoft.pro/store-assets/media/8bf74d444d-960.webp) ![EmberLink Streaming preferences: Light, Balanced and Detailed profiles, then resolution, frame rate, bitrate and video codec settings, and encoder options](https://pyrosoft.pro/store-assets/media/08d214e313-960.webp) ## Questions ### When can I get EmberLink? It's coming soon. There's no public download yet and no price has been announced. Join the PyroSoft Discord for launch news. ### Is it like Synergy? Same idea: one keyboard and mouse moving between computers as if their screens were one desk. EmberLink is a new implementation, with no Synergy or Deskflow code, and it adds Super Display for bringing a remote desktop onto the screen you're using. ### Does anything go through the internet? No. Paired computers talk directly over TLS on your local network, with no account and no cloud relay. ### What if something goes wrong mid-session? Press Esc to stop sharing. If the connection drops, EmberLink releases any held keys and mouse buttons and gives you back local control. ### What happened to MousePort? MousePort was the working name for EmberLink's first private preview builds. Pairings, layouts and settings from those builds carry over. --- # Ferrum > Windows games on a Mac, without Rosetta. Canonical page: https://pyrosoft.pro/software/ferrum Status: coming-soon Platforms: macOS Ferrum is PyroSoft's native macOS x86-64 translation layer for Windows games on Apple Silicon. Built on FEX, it turns a game's Intel instructions into ARM64 as the game runs, answers its Windows requests through Wine, and hands its graphics to Metal through DXVK and MoltenVK: no Rosetta, no virtual machine and no Windows licence. It exists because Apple is retiring Rosetta, which almost every Windows-on-Mac setup depends on, Bourbon's current Windows path included. Ferrum replaces the layer underneath with a native ARM64 host and FEX only where x86-64 code needs translating, while Smart Play, the Bottle Shelf and the rest of Bourbon stay as they are. Ferrum is still in development. It boots a real game, renders its menus through DXVK and presents frames in a real macOS window, but no game has been played end to end by a person yet. There is no public build and no ship date; when it lands, it ships inside Bourbon 26 with nothing extra to buy. The public repository holds documentation only. Price: Ships inside Bourbon 26. ## Requirements Apple Silicon (M-series) Mac ## Features - x86-64 game code translated to ARM64 as it runs, built on FEX-Emu - Windows requests answered by Wine: no Windows licence, no virtual machine - DirectX to Vulkan via DXVK and vkd3d-proton, then to Metal via MoltenVK - A real macOS window and Vulkan swapchain; audio through CoreAudio - Handles the XGETBV instruction Rosetta 2 rejects (CPUID, XGETBV, XSAVE) - Isolated runtime: no Homebrew, PATH lookups or other Wine installs - Will ship inside Bourbon 26, with nothing extra to buy ## How to get it Coming soon. Use the product page and development journal for current status. - [Source code]() ## Recorded details - License: Proprietary (Ferrum Commercial License) - Tech: FEX-Emu, Wine, DXVK, vkd3d-proton, MoltenVK and Metal ## Screenshots ![Hollow Knight gameplay in King's Pass, the Knight mid nail-swing, rendered by Ferrum on an Apple M5](https://pyrosoft.pro/store-assets/media/15b643cc35-960.webp) ![Hollow Knight gameplay restored from a save in King's Pass](https://pyrosoft.pro/ferrum/assets/hk-kingspass-save.jpg) ![Hollow Knight title menu rendered by Ferrum](https://pyrosoft.pro/store-assets/media/7dfa191ff2-960.webp) ## Questions ### Will my games work? Not yet. Ferrum can create a Direct3D 11 device and put a rendered frame in a real Mac window, but no full game has been driven from launch to gameplay by a person. For playing Windows games today, use Bourbon 26. ### Do I need a Windows licence? No. Ferrum never runs Windows. The Windows interfaces come from Wine, which reimplements them without Microsoft code. ### Isn't this what Rosetta does? Rosetta translates Intel Mac apps and knows nothing about Windows. Most Windows-on-Mac setups use it as one layer in a taller stack, which is the problem, because Apple is retiring it. Ferrum replaces that layer. ### Which Macs? Apple Silicon only (M-series). Intel Macs don't need it. ### What about anti-cheat? Kernel-level anti-cheat won't work under any translation layer. User-mode Easy Anti-Cheat and BattlEye can, where a publisher has enabled it; that is on the roadmap, not working yet. ### How do I get it? Ferrum will ship as an integrated part of Bourbon 26, with nothing extra to buy or sign. For use outside Bourbon, ask about commercial licensing at contact@mikethetech.com. ## Related guides and journals - [Asynchronous I/O and the Bytes a Cancelled Write Keeps](https://pyrosoft.pro/blog/async-io-and-the-bytes-a-cancelled-write-keeps.md) - [A Real Archive Roundtrip and Better File Behavior](https://pyrosoft.pro/blog/real-archive-roundtrip-and-file-behavior.md) - [Making the Launcher Own Its Storage and Processes](https://pyrosoft.pro/blog/making-the-launcher-own-its-work.md) - [Getting Wine's Real 32-Bit Startup to Run](https://pyrosoft.pro/blog/getting-wines-real-32-bit-startup-to-run.md) - [Making Memory Protection and Lifetime Tests More Useful](https://pyrosoft.pro/blog/memory-protection-and-lifetime-tests.md) - [Recovering the Project and Resuming Real Tests](https://pyrosoft.pro/blog/recovering-the-project-and-resuming-real-tests.md) - [Correcting the Ferrum Progress Report](https://pyrosoft.pro/blog/correcting-the-progress-report.md) - [Portal Reaches a Command Stream, With the Frame Still Ahead](https://pyrosoft.pro/blog/portal-reaches-a-command-stream.md) - [A Launcher and a Freeze That Wasn't the Presenter](https://pyrosoft.pro/blog/a-launcher-and-a-freeze-that-wasnt-the-presenter.md) - [Working on Presentation and Controller Input](https://pyrosoft.pro/blog/windows-that-keep-up-and-controllers-that-wake.md) - [DirectX 12, Shader Caches, and the Steam Startup Work](https://pyrosoft.pro/blog/directx-12-shader-caches-and-steam.md) - [Making Memory, Files, and Graphics State Agree](https://pyrosoft.pro/blog/making-runtime-state-consistent.md) - [Building the 32-Bit Graphics Path](https://pyrosoft.pro/blog/building-the-32-bit-graphics-path.md) - [Game Progress and Measuring the Right Thing](https://pyrosoft.pro/blog/gameplay-performance-and-measuring-the-right-thing.md) - [Installers, Saves, Fonts, and the Parts Around the Game](https://pyrosoft.pro/blog/installers-saves-fonts-and-audio.md) - [Following a Game Through Its Opening Video](https://pyrosoft.pro/blog/following-a-game-through-its-opening-video.md) - [Building More of the Windows Runtime](https://pyrosoft.pro/blog/windows-runtime-threads-and-older-directx.md) - [From Return Values to Pixels and Sound](https://pyrosoft.pro/blog/from-return-values-to-pixels-and-sound.md) - [Bringing FEX to macOS: The First Windows Program](https://pyrosoft.pro/blog/bringing-fex-to-macos.md) --- # FireFetch > Download literally anything worth keeping. Canonical page: https://pyrosoft.pro/software/firefetch Status: coming-soon Platforms: Windows FireFetch is a Windows desktop app that turns videos, music, playlists, direct files and torrents into an offline library you control. Paste a link, review what FireFetch found, choose the quality when you care, and let the queue do the rest. Behind a simple interface it uses proven tools: yt-dlp to analyse videos and playlists, FFmpeg to merge and convert, aria2c for fast direct downloads, and Peerflix for torrent media. The queue shows waiting, active, finished and failed jobs with pause, resume and retries, and keeps its state between sessions. A music workspace builds albums, artists and playlists from what you save, with suggestions based on your favourite artists and official album metadata rather than AI. Everything stays local: settings, queue state, downloads and optional cookies live beside the app, and FireFetch does not bypass DRM. Earlier builds, up to 25.12.26, were published on itch.io between 2025 and early 2026. Price: Price TBA. ## Requirements Windows (packaged build). Running from source needs Node.js and npm; Windows is the primary target because the bundled tools are .exe files ## Features - Video, music and playlist downloads via yt-dlp, with format selection - Fast direct downloads with aria2c; torrent and magnet links - Queue with pause, resume, retries, reordering and saved state - Download board for waiting, active, finished and failed jobs - Music workspace: albums, artists, playlists, songs and offline view - Suggestions from your favourite artists and album metadata, no AI - Dependency manager keeps bundled tools current; optional local cookies - Local-first: settings, downloads and cookies stay beside the app ## How to get it Coming soon. Use the product page and development journal for current status. - [Project website]() ## Recorded details - First release: Earliest build on itch.io: 25.5.19 - Tech: Electron and Express; yt-dlp, FFmpeg, aria2c ## Screenshots ![FireFetch home screen with link intake and library shortcuts](https://pyrosoft.pro/store-assets/media/b20fb7001f-960.webp) ![FireFetch videos library](https://pyrosoft.pro/store-assets/media/c3d4be0c6c-960.webp) ![FireFetch Music For You page](https://pyrosoft.pro/store-assets/media/26a1f0b689-960.webp) ![FireFetch albums page](https://pyrosoft.pro/store-assets/media/4b4e85e6ec-960.webp) ![FireFetch artists page](https://pyrosoft.pro/store-assets/media/ed024e5b89-960.webp) ![FireFetch downloads board](https://pyrosoft.pro/store-assets/media/fc84d7f935-960.webp) ![FireFetch Settings with folders, quality, formats and filename templates](https://pyrosoft.pro/store-assets/media/33dd5c9b2b-960.webp) ![Earlier FireFetch Browse Videos page with site and date filters](https://pyrosoft.pro/store-assets/media/f0f0e06208-960.webp) ## Questions ### Is downloading videos legal? FireFetch is a tool, like a browser's save button. Downloading content you have rights to keep (your own uploads, purchases, public-domain and permissively licensed media) is fine; redistributing copyrighted work is not. Check the terms of the sites you use. ### What sites and formats does it support? FireFetch is powered by yt-dlp, which supports hundreds of sites, plus direct file downloads and torrents through aria2. FFmpeg handles conversion, including audio-only extraction. ### How do updates work when sites change? The bundled yt-dlp engine is updated with FireFetch releases, so when sites change their players you update the app instead of debugging command-line flags. ### Does FireFetch bypass DRM? No. FireFetch does not bypass DRM-protected content. --- # Fuse > See how much of each AI plan you have left, from your Mac's menu bar. Canonical page: https://pyrosoft.pro/software/fuse Status: coming-soon Platforms: macOS, Windows Fuse shows how much of each AI plan you have left, in one compact view: remaining-capacity meters, reset countdowns, plan names, credits and spending caps for Cursor, Claude, ChatGPT/Codex and Gemini, plus experimental integrations for GitHub Copilot, Perplexity, Grok and Windsurf. On a Mac it lives in the menu bar, in a floating notch you can dock to any edge of the display, or in its own dashboard window. Bars drain as you use your allowance, a 24-hour history is drawn from real readings, and a service that goes quiet keeps its last good reading, clearly marked. Add the same service twice and work and personal accounts get separate rows and sign-ins. You sign in on each service's own page; Fuse keeps only the resulting session, in the macOS Keychain, and never sees your password. It is an independent app that reads what each signed-in dashboard already shows. Fuse isn't publicly released yet: the Mac build needs macOS 14 or later on Apple Silicon, and an earlier Windows build runs from the system tray. Price: Price TBA. ## Requirements macOS 14 or later on Apple Silicon (no Intel build); Windows 10 or 11, x64 or ARM64, with the Edge WebView2 Runtime; your own accounts with the services you track ## Features - Remaining capacity, reset countdowns, credits and spending caps per account - Cursor, Claude, ChatGPT/Codex and Gemini checked; four more experimental - Menu bar, a dockable floating notch, or a standalone dashboard window - 24-hour usage history charted from real readings - Multiple accounts per service, each with its own browser profile - Sessions kept in the macOS Keychain; Fuse never sees your password - Checks every 15 minutes by default, adjustable from 5 to 60 ## How to get it Coming soon. Use the product page and development journal for current status. ## Recorded details - Tech: Embedded-browser sign-in, Keychain sessions; WebView2 on Windows ## Screenshots ![Fuse's floating notch expanded from the top edge of the display, showing remaining-capacity meters and reset times for two Cursor accounts, Claude, ChatGPT and Gemini](https://pyrosoft.pro/fuse/assets/fuse-notch.jpg) ![The Fuse dashboard window listing Cursor, Claude, ChatGPT and Gemini accounts with plan badges, remaining-capacity bars and reset countdowns](https://pyrosoft.pro/fuse/assets/fuse-dashboard.jpg) ![Fuse Settings showing the Tray menu and Floating notch switch, five accounts with Connect buttons, and the Add an account controls](https://pyrosoft.pro/fuse/assets/fuse-settings.jpg) ## Questions ### Does Fuse see my passwords? No. You sign in on each service's own page in an embedded browser, and Fuse keeps only the resulting session: in the Keychain on a Mac, encrypted for your user account on Windows. ### Is Fuse official, or affiliated with these services? No. Fuse is an independent app from PyroSoft. It reads the same data the services' signed-in dashboards load; those endpoints are unofficial and can change. ### Does it count my prompts or tokens? No. Fuse reports what each service's own dashboard reports. ### Why does ChatGPT only show Codex? ChatGPT's core chat message caps have no self-serve usage source, so Fuse tracks the Codex windows the service does expose. ### Will it run on an Intel Mac? Not currently. The Mac build is Apple Silicon only and needs macOS 14 or later. ### Is the Windows build signed? Not yet. The Windows build (26.8.26.1) isn't Authenticode-signed, so SmartScreen may ask before the first launch. It needs no administrator rights. --- # MagicGlass > Your Mac screen. Now touchable. Canonical page: https://pyrosoft.pro/software/magicglass Status: coming-soon Platforms: macOS MagicGlass turns a Mac into a touch-capable computer using an iPhone you already own. Stand the iPhone beside the display where Continuity Camera can see the screen, run a short calibration, and your finger becomes the pointer: hover to move the cursor, touch the glass to click, touch and move to drag, and use two fingers for a right-click. It works with computer vision rather than extra hardware. Four coded markers locate the exact screen plane even when the phone views it from an angle, hand-pose tracking follows 21 landmarks, and a calibration of nine touch targets plus a hover pass teaches MagicGlass the difference between pointing and pressing. Camera frames are processed locally on the Mac, with no account, no cloud processing and no video uploads. MagicGlass is in development and not publicly available yet. macOS with iPhone comes first; Windows and Android support are planned. Price: Price TBA. ## Requirements A Mac and an iPhone available through Continuity Camera; no touchscreen or special hardware ## Features - Hover to move the cursor; touch the screen to click - Touch and move to drag; two fingers for a right-click - Uses an iPhone you already own, through Continuity Camera - Four corner markers find your exact screen, even from an angle - Calibration: nine touch targets plus a hover pass - All processing on the Mac: no account, no cloud, no video uploads - Zero third-party runtime dependencies - Windows and Android support planned ## How to get it Coming soon. Use the product page and development journal for current status. - [Project website]() ## Recorded details - Tech: Vision hand pose, QR fiducials, Continuity Camera ## Screenshots ![The MagicGlass website hero: Your Mac screen. Now touchable.](https://pyrosoft.pro/store-assets/media/eb1e77742b-960.webp) ## Questions ### Do I need a touchscreen or special hardware? No. MagicGlass uses an iPhone you already own as the camera, through Continuity Camera. No proprietary mount, calibration sheet or cables. ### Does my camera feed leave the Mac? No. Camera frames are processed locally on your Mac: no account, no cloud processing and no video uploads. ### Does it work on Windows or Android? Not yet. MagicGlass currently targets macOS with iPhone; Windows and Android support are planned. --- # NotSoMysteryBox > The mystery box that tells you what's inside. Canonical page: https://pyrosoft.pro/software/notsomysterybox Status: coming-soon Platforms: Web NotSoMysteryBox is a mystery box without the gamble. Every box will list its exact contents, condition and honest retail value before you buy, and each one is a single, unique build: one quantity, one owner. When a box is claimed, its listing comes down for good. The boxes are curated tech (gadgets, gear and peripherals), always listed below the value of what's inside. Buying works in three steps: read the manifest, claim your 1-of-1, and it ships while the listing retires. NotSoMysteryBox is in coming-soon mode: no boxes are on sale yet and prices haven't been published. Leave an email on the site to hear when the first boxes go live. Price: Price TBA. ## Features - A full itemized manifest on every box: products, condition and value - Every box is 1 of 1; the listing retires once it's claimed - Hand-picked tech, always listed below the value of the contents - Three steps: read the manifest, claim your box, it ships and retires - Email waitlist for the first drops ## How to get it Coming soon. Use the product page and development journal for current status. - [Open web app]() - [Project website]() ## Screenshots ![NotSoMysteryBox coming-soon page on a phone with the headline and an email waitlist form](https://pyrosoft.pro/store-assets/media/516e65018a-960.webp) ![NotSoMysteryBox promises and How it works sections](https://pyrosoft.pro/store-assets/media/bbb393a0cd-960.webp) --- # AlisalTech - Kids > Educational games, activities and resources for home and class. Canonical page: https://pyrosoft.pro/software/alisaltech-kids Status: deprecated Platforms: Web AlisalTech – Kids was a website Mike Rodriguez created as part of the AlisalTech.com network to help teachers, parents and students find useful learning resources for home and the classroom. It lived at alisaltech.com/kids under the motto “Education comes first.” Each entry pointed to an educational website, game or activity, with a short write-up, an image and tags, filed under Individual Games and Activities, Language Arts, Maths or Science/Social Studies. Some entries noted when a site required a paid subscription, and visitors could suggest new resources through a Submit a Site! page. The site's archive began in March 2009, and entries were still being added in 2012, including one submitted from the Del Rey Woods computer lab. It is no longer online. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: WordPress ## Screenshots ![The AlisalTech – Kids homepage in 2012 with a red tab menu and two resource entries](https://pyrosoft.pro/store-assets/media/alisaltech-kids/alisaltech-kids-r1-5865cc6c.webp) --- # Blue Box > Modern blue box tone generator. Canonical page: https://pyrosoft.pro/software/blue-box Status: deprecated Platforms: Windows Blue Box was a small Windows tool from MikeTheTech, a digital blue box. A blue box generates the in-band signaling tones once used on the North American long-distance telephone network, the tones phone phreakers used. It was published on itch.io in January 2022 with a simple greeting, “Hey, Phreaks!”, as a modern tone generator with usable, accurate tones. Everything happened in one keypad window: the digits 0 to 9, KP and ST keys, and a 2600 Hz button, with keyboard hints on the keys and Esc to close. It was a free, name-your-own-price download and is no longer offered. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: Jan 22, 2022, on itch.io ## Screenshots ![Blue Box keypad window with digits, ST and KP keys and a 2600 Hz button](https://pyrosoft.pro/store-assets/media/blue-box/blue-box-r1.png) --- # Box2D Space Shooter Source (GMS2) > GameMaker Studio 2 template for a Box2D physics space shooter. Canonical page: https://pyrosoft.pro/software/box2d-space-shooter-source Status: deprecated Platforms: Windows Box2D Space Shooter Source was a free GameMaker Studio 2 project Mike shared in May 2019: a top-down space shooter built as an experiment in using physics-based objects to push, pull and otherwise control things in the game. It came as two downloads, a ready-to-play Windows build and the GMS2 source files, so it could be played, studied or used as a template. Its graphics came from Kenney.nl, and the on-screen readout tracked health, two laser cooldowns, lives, credits, score and a Super Laser. The same day, Mike posted a short YouTube clip about it. It later had an itch.io page, which has since been taken down. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: May 21, 2019 - Tech: GameMaker Studio 2 with Box2D physics ## Screenshots ![Top-down space shooter gameplay with asteroids, enemy ships and a HUD in the top left](https://pyrosoft.pro/store-assets/media/box2d-space-shooter-source/box2d-space-shooter-source-r1.png) --- # CinemaVerse > Credit trails between any two movies, shows or people. Canonical page: https://pyrosoft.pro/software/cinemaverse Status: deprecated Platforms: Web CinemaVerse was a "connection studio" for film and TV. You picked two endpoints (a movie, a scripted show, an actor or a director) and it searched for the shortest trail of real credits between them, then drew that trail as a visual path. Connections came only from scripted acting, directing and creator credits. Talk shows, news, reality, documentaries and self or interview appearances were filtered out so the links stayed meaningful. A bidirectional shortest-path search worked from both ends at once, and TV shows could be explored down to season and episode names. It used TMDB names, credits, metadata and image URLs only, with no clips, downloads or playback. Its final version was a plain PHP port, written in PHP, HTML, CSS and vanilla JavaScript with no build step, and CinemaVerse is now part of PyroSoft's legacy collection. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: PHP, vanilla JavaScript; TMDB API ## Screenshots ![CinemaVerse start screen with From and To search fields and Origin and Destination cards](https://pyrosoft.pro/store-assets/media/1239389fea-960.webp) ![CinemaVerse on a phone-width screen with the From and To fields](https://pyrosoft.pro/store-assets/media/6c98e0ed23-960.webp) --- # Custom Bouncing Screensaver > Bounce your own image around the screen, DVD-logo style, in a browser. Canonical page: https://pyrosoft.pro/software/custom-bouncing-screensaver Status: deprecated Platforms: Web Custom Bouncing Screensaver is a tiny browser-based take on the classic bouncing DVD logo. Open the page, pick any image from your computer and press Start Screensaver: your picture drifts diagonally across a black screen and bounces off every edge. The image is scaled to about a tenth of the window, keeps its proportions and resizes with the window, so it works at any screen size. If you skip the upload, it bounces its default image, the classic DVD Video logo. Everything happens in your browser; the image is read locally and kept in the page's local storage. Mike published it as a free web tool in November 2024, together with a short how-to video on the MikeTheTech YouTube channel. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: Nov 11, 2024 - Tech: HTML, CSS and JavaScript ## Screenshots ![The bouncing screensaver start page with an image upload field and a Start Screensaver button](https://pyrosoft.pro/store-assets/media/debcc4dee3-960.webp) --- # DRW Auto Loader > Classroom launcher for K-12 learning sites, built for Del Rey Woods. Canonical page: https://pyrosoft.pro/software/drw-auto-loader Status: deprecated Platforms: Windows DRW Auto Loader, titled Del Rey Woods “Auto-Load” in its own window, was a Windows launcher Mike built for Del Rey Woods Elementary School, where he worked as computer lab technician. It opened onto a grid of large, colorful tiles for popular learning sites such as Starfall, ABCya!, Dance Mat Typing, PBS Kids and BBC Bitesize. Mike described it as quick and easy access to a massive list of K-12 educational resources. The menu bar also offered the Windows Calculator, Paint and sound options, and the window showed the current date. It was first released privately for the school in 2014. It was later shared on itch.io as Educational Site Loader (2014); both names refer to the same program, DRWAutoLoad.exe. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: 2014, privately for Del Rey Woods Elementary ## Screenshots ![Del Rey Woods Auto-Load window with a 3 by 3 grid of learning-site tiles](https://pyrosoft.pro/store-assets/media/drw-auto-loader/drw-auto-loader-r1-f4235bc7.webp) --- # Educational Site Loader > One-window launcher for popular K-12 learning websites. Canonical page: https://pyrosoft.pro/software/educational-site-loader Status: deprecated Platforms: Windows Educational Site Loader was the public release of the Windows launcher Mike first made for Del Rey Woods Elementary School in 2014. It opened a single window, titled Del Rey Woods “Auto-Load”, filled with large tiles for popular learning sites such as Starfall, ABCya!, Dance Mat Typing, Sheppard Software, EducationCity, PBS Kids, BBC Bitesize and Mr. Nussbaum. Alongside the links, the menu bar gave quick access to the Windows Calculator and Paint plus sound options. It was meant for an elementary school, though many of the resources suit K-12. It was shared on itch.io as a free, name-your-own-price download: a single 545 kB program, DRWAutoLoad.exe, started from an apple icon (“Double-click the apple!”). Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Screenshots ![Auto-Load window with nine tiles for learning websites and a menu bar](https://pyrosoft.pro/store-assets/media/educational-site-loader/educational-site-loader-r1.png) --- # Fight for the Hood: The Game > Urban zombie survival game based on the Fight for the Hood movie. Canonical page: https://pyrosoft.pro/software/fight-for-the-hood-game Status: deprecated Fight for the Hood: The Game was announced as a survival game that puts urban culture at the center of a zombie apocalypse. Based on the Fight for the Hood movie, it was meant to bring the film's story and atmosphere into street-level zombie combat, with players defending their community against the undead in neighborhood settings. PyroSoft listed the game as in development, with the release date and platforms still to be announced. No build, platform or price was published. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Screenshots ![Fight for the Hood key art with a character, a dog and a car](https://pyrosoft.pro/store-assets/media/648baf165a-960.webp) --- # Free 3D Dice Roller > 3D dice for tabletop games: D4 to D100 on a table they can't fall off. Canonical page: https://pyrosoft.pro/software/free-3d-dice-roller Status: deprecated Platforms: Windows Free 3D Dice Roller was a Windows app for tabletop players: a full set of dice (D4, D6 with dots or numbers, D8, D10, D12, D20 and a D100 tens die) on a wooden table in a 3D room with a fireplace. It was made for Dungeons & Dragons adventures or any game that needs dice, and the table is built so the dice can never fall off. To roll, right-click to grab a die and drag it to the center of the table, then left-click to give it an impulse. A bar along the top shows the latest result for every die so rolls are easy to confirm, and M toggles the audio. It was released free (name your own price) on itch.io in 2021 and is no longer offered for download. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Screenshots ![Red 3D dice on a wooden table in a room with a fireplace, with roll results along the top](https://pyrosoft.pro/store-assets/media/d723f03939-960.webp) --- # Guardians of Dale > A Notepad-made text adventure from a game-design lesson plan. Canonical page: https://pyrosoft.pro/software/guardians-of-dale Status: deprecated Platforms: Windows Guardians of Dale was a small text adventure that came out of a game-design lesson plan, built, as the tutorial put it, in "the most powerful game engine in the world, Windows Notepad." It ran as a Windows batch file in the command prompt, with ASCII art, a welcome from the town's mayor, and simple systems for attacking, taking damage, earning gold and buying weapons that change your stats. It was never meant to be a complete game, but a teaching project with open source code to edit. The full source was published on mikethetech.com in May 2019 along with a section-by-section code breakdown, and the download was later offered on itch.io as name-your-own-price. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: May 20, 2019, on mikethetech.com - Tech: Windows batch script, written in Notepad ## Screenshots ![Command-prompt title screen with an ASCII-art dragon and the Guardians of Dale banner](https://pyrosoft.pro/store-assets/media/guardians-of-dale/guardians-of-dale-r1.png) ![Text combat screen against an ASCII-art Small Rat](https://pyrosoft.pro/store-assets/media/guardians-of-dale/guardians-of-dale-r2.png) ![Text screen for repairing Potter's Potions with gold, lumber and limestone](https://pyrosoft.pro/store-assets/media/guardians-of-dale/guardians-of-dale-r3.png) --- # Kinect Virtual Green Screen > Use a Kinect as a webcam, with your background swapped for green. Canonical page: https://pyrosoft.pro/software/kinect-virtual-green-screen Status: deprecated Platforms: Windows Kinect Virtual Green Screen let you use a Kinect v1 sensor as a webcam with your background removed automatically. It replaced your real-life background with a virtual green screen, ready to be keyed out in OBS Studio or any app that can capture a window. Mike built it in C# with Visual Studio on the BackgroundRemovalBasics sample from the Kinect Toolkit. The window showed the live result, with a Near Mode option and a Screenshot button that saved a still to your My Pictures folder. He first released it on his website in April 2020 with the source code, then offered it free (name your own price) on itch.io and on GitHub, where version 21.4.22 was posted in October 2023. It needed the Kinect for Windows SDK 1.8 and the Kinect PC drivers. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Version: 21.4.22 - License: No licence listed - First release: Apr 28, 2020 - Tech: C#, Kinect Toolkit (BackgroundRemovalBasics) ## Screenshots ![Kinect Virtual Green Screen window with a green output area and a Near Mode checkbox](https://pyrosoft.pro/store-assets/media/kinect-virtual-green-screen/kinect-virtual-green-screen-r1.png) ![Kinect Virtual Greenscreen by MikeTheTech window with an empty green output](https://pyrosoft.pro/store-assets/media/kinect-virtual-green-screen/kinect-virtual-green-screen-r2.jpg) --- # LinuxWidgets > Glassmorphism desktop widgets for Linux. Canonical page: https://pyrosoft.pro/software/linuxwidgets Status: deprecated Platforms: Linux LinuxWidgets put frosted-glass widgets on the Linux desktop: weather, system stats, network, sticky notes, a calendar and a clock. Each one sat in its own frameless, transparent window below other apps, with real backdrop blur and a coloured glow along the top edge. The data was live. Weather and a five-day forecast came from Open-Meteo with no API key, the system widget showed CPU, RAM, disk and CPU temperature as animated ring gauges, and the network widget graphed download and upload speeds alongside the machine's IP and MAC address. Every widget had its own settings for accent colour, background opacity and blur, plus options such as temperature units or a 12/24-hour clock. A Widget Manager window and a tray icon added and removed widgets, and positions, sizes and settings were remembered between sessions. LinuxWidgets was released as open source under the GPL-3.0 in March 2026; it was built with Electron and ran from source with Node.js 18 or later. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - License: GPL-3.0 - First release: Repository created Mar 30, 2026 - Tech: Electron 35, Open-Meteo API ## Screenshots ![LinuxWidgets Widget Manager with six widget cards](https://pyrosoft.pro/store-assets/media/linuxwidgets/linuxwidgets-r1.png) --- # MBARI Underwater Rover Simulation > An Unreal Engine underwater expedition with MBARI's Doc Ricketts ROV. Canonical page: https://pyrosoft.pro/software/mbari-underwater-rover Status: deprecated MBARI Underwater Rover Simulation was a personal Unreal Engine project in which Mike recreated an underwater scientific expedition around MBARI's Doc Ricketts ROV. He shared its progress on the MikeTheTech YouTube channel in late 2020, with an 'Underwater Rover Project Update' in November and 'MBARI Project Update, Doc Ricketts ROV and Real Discoveries' in December, plus a project page on his website the same month. The footage shows the yellow rover model in the editor and the view from the rover as it moves through a lit underwater scene, with Mike narrating on webcam. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: First shown Nov 20, 2020 - Tech: Unreal Engine ## Screenshots ![Underwater canyon seen from the rover, with the yellow ROV frame in the foreground](https://pyrosoft.pro/store-assets/media/2b50eef8b5-960.webp) ![Yellow ROV model in a dark underwater scene inside the Unreal Engine editor](https://pyrosoft.pro/store-assets/media/de5a0ad697-960.webp) ![Rocks, fish and coral seen from the rover](https://pyrosoft.pro/store-assets/media/c05b5a0aa9-960.webp) --- # MDEdit > A cross-platform WYSIWYG Markdown editor built with Electron. Canonical page: https://pyrosoft.pro/software/mdedit Status: deprecated Platforms: Windows, macOS, Linux MDEdit was a cross-platform Markdown editor built with Electron. Writing happened in a rich-text (WYSIWYG) view, with a one-click or Ctrl+/ switch to raw Markdown, and an optional split view showed the rendered result next to the editor while typing. Every Markdown feature sat in the toolbar: text styles, six heading levels, bullet, numbered and task lists, links, images, tables, code blocks in more than 30 languages, footnotes, a table of contents, emoji and LaTeX math. It also had find and replace, drag-and-drop for images and .md files, smart paste that cleaned up HTML, dark mode, and a status bar with word, character and line counts. Files opened and saved through native dialogs, and documents could be exported to HTML or printed to PDF. MDEdit was released as open source under the GPL-3.0 in March 2026. It was distributed as source code, with build targets for AppImage and .deb on Linux, an installer or portable .exe on Windows, and a .dmg on macOS. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - License: GPL-3.0 - First release: Repository created Mar 30, 2026 - Tech: Electron 35, marked, turndown ## Screenshots ![MDEdit editor with a formatting toolbar and a welcome document](https://pyrosoft.pro/store-assets/media/6999957d74-960.webp) --- # Paragon Tournament > A Smash-style platform fighter prototype built with Paragon assets. Canonical page: https://pyrosoft.pro/software/paragon-tournament Status: deprecated Platforms: Windows Paragon Tournament was a prototype that set out to reimagine Epic Games' Paragon as a Super Smash Bros.-style platform fighter. Built in Unreal Engine 5, it drew on the Paragon characters, levels and assets that Epic Games released to Unreal Engine developers. The plan was a Smash-style game with recognizable Paragon characters, moves, attacks, combos and stages, starting from the 39 Paragon heroes. The idea first appeared in short dev-day videos in September 2021, and in October 2021 a tech demo went up on itch.io under the working title Paragon Smash. That demo covered a stage and movement only, with no combat interactions; its screenshots show the heroes Countess and Aurora. By 2022 the project had its own website, an early character select screen with locked characters, and a working Ready Player Me integration so players could bring in their own avatars. Plans included more Unreal Engine assets such as Windwalker Echo, MetaHumans in place of Miis, cross-platform play and a Kickstarter campaign, but no build beyond the 2021 tech demo was published. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: Oct 18, 2021: tech demo on itch.io - Tech: Unreal Engine 5; Ready Player Me ## Screenshots ![Countess and Aurora on a jungle ruins stage in the Paragon Tournament tech demo](https://pyrosoft.pro/store-assets/media/abccf8581d-960.webp) ![Two Paragon heroes on a ruins stage with damage percentages along the bottom](https://pyrosoft.pro/store-assets/media/78accb36be-960.webp) ![Character select screen with a robotic hero on a turntable](https://pyrosoft.pro/store-assets/media/a442c7d2b1-960.webp) ![A Ready Player Me avatar on the character select screen](https://pyrosoft.pro/store-assets/media/30dfb79ad9-960.webp) --- # Pixoo 64: Snake > Classic Snake for the Pixoo 64 LED display. Canonical page: https://pyrosoft.pro/software/pixoo-64-snake Status: deprecated Pixoo 64: Snake brought the classic Snake game to the Divoom Pixoo 64 LED display. You played on your PC with the arrow keys while the game drew every frame on the Pixoo over your local network, with a Tkinter window mirroring the 64x64 playfield. It had four difficulty levels, Easy, Medium, Hard and Insane, which changed the size of the snake from 8-pixel blocks down to single pixels. You could pause, resume or stop at any time and toggle a grid over the preview. The snake wrapped around the edges of the screen, your score was drawn on the Pixoo and in the window title, and 'Game Over!' or 'You Win!' appeared on the display when a round ended. Written in Python with Pillow and the open-source pixoo library, it was published on GitHub on the same day as Pixoo 64 Tools (February 2025). It is now a legacy project. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - License: No licence file - First release: Feb 26, 2025 (repository created) - Tech: Python, Tkinter, Pillow, pixoo ## Screenshots ![Pixoo Snake window on Easy with a large-block snake preview](https://pyrosoft.pro/store-assets/media/pixoo-64-snake/pixoo-64-snake-r1.png) ![Pixoo Snake on Insane with single-pixel snake and food](https://pyrosoft.pro/store-assets/media/pixoo-64-snake/pixoo-64-snake-r2.png) --- # Python VDD Pipe Control > A small window for sending commands to the VDD's named pipe. Canonical page: https://pyrosoft.pro/software/python-vdd-pipe-control Status: deprecated Platforms: Windows Python VDD Pipe Control was a small Python tool for talking to the Virtual Display Driver directly. It opened a simple window that connected to the driver's named pipe, \\.\pipe\MTTVirtualDisplayPipe, let you type a command and send it, and showed the driver's replies in a log. It had a Reconnect button for when the pipe dropped and showed an alert when a connection failed or a command was invalid. It needed Python 3 with Tkinter and pywin32, and the source was published under the MIT licence in February 2025. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - License: MIT - First release: Repository created Feb 3, 2025 - Tech: Python 3, Tkinter, pywin32 ## Screenshots ![Small Python window with a command field and a connection log](https://pyrosoft.pro/store-assets/media/python-vdd-pipe-control/python-vdd-pipe-control-r1.png) --- # SalinasRadio.com > Internet radio that promoted the Monterey Bay music scene. Canonical page: https://pyrosoft.pro/software/salinasradio Status: deprecated Platforms: Web SalinasRadio.com was an internet radio station and blog built to promote the Monterey Bay music scene. Mike Rodriguez built it: a small streaming server on a cheap host with an upstream server at home, a website, and one favourite local band, Rum & Rebellion, streamed with their permission. Listeners followed, other bands began sending in songs for free air time, and the station soon moved to a dedicated server that could handle multiple streams. The station streamed local music live to anyone in the world and grew into a WordPress site with artist pages, band news and listings for local shows. On 13 April 2009 it opened its first genre station, "Rock, Metal, and Acoustic", in beta alongside the all-genres stream. An On Demand Player, also a beta, played songs from the participating local bands; in March 2010, after a long move, it was working while the live streams were still down. By November 2009 the Artists page listed dozens of local acts, with about 150 more on a contact list; PyroSoft's project timeline credits the site with showcasing over 50 local bands. In March 2011 Mike announced that the live stream would return and ordered a new streaming server. Archived copies show the site running from April 2009 into mid-2013, with the last posts dated April 2011. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: Online by April 2009 - Tech: WordPress and a self-run streaming server ## Screenshots ![Archived capture of SalinasRadio.com in April 2009 with a post inviting local bands](https://pyrosoft.pro/store-assets/media/9f2b22aff2-960.webp) ![Archived capture of the SalinasRadio Artists page listing local acts](https://pyrosoft.pro/store-assets/media/ba1c413054-960.webp) ![Archived capture of the SalinasRadio home page in July 2010](https://pyrosoft.pro/store-assets/media/67b49ceb8a-960.webp) --- # ScreenSaver XP > A 3D Unreal Engine tribute to the Windows XP Bliss hill, day to night. Canonical page: https://pyrosoft.pro/software/screensaver-xp Status: deprecated Platforms: Windows ScreenSaver XP was a 3D tribute to the Windows XP "Bliss" wallpaper, built in Unreal Engine. Instead of a flat photo, it recreated the rolling green hill and sky as a fully 3D scene and ran it as a screensaver with a full 24-hour day/night cycle, from bright daylight through sunset to a starry night. The original 2021 build let you switch to a one-hour cycle with 1 or a five-minute cycle with 5. Version 0.1, posted in July 2022, offered four speeds instead: 1 for one hour, 2 for 30 minutes, 3 for 15 minutes and 4 for one minute, with Tab to hide the on-screen help. Esc closed it in both. Mike released it for Windows on itch.io in May 2021. In 2021 it was listed at a $1.99 minimum; by July 2022 the page offered version 0.1 alongside the original build and had become name-your-own-price. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Version: 0.1 - Tech: Unreal Engine ## Screenshots ![Green 3D hill under a cloudy blue sky](https://pyrosoft.pro/store-assets/media/5fe511a575-960.webp) ![Stars over the hill at night](https://pyrosoft.pro/store-assets/media/3b16eedbdd-960.webp) ![Pink sunset sky over the hill with a key-help overlay](https://pyrosoft.pro/store-assets/media/screensaver-xp/screensaver-xp-r4-cf0c38c3-crop.webp) --- # Spotify for Pixoo 64 > Display your current Spotify album artwork on your Pixoo 64 device. Canonical page: https://pyrosoft.pro/software/spotify-for-pixoo-64 Status: deprecated Platforms: Windows Spotify for Pixoo 64, sold on itch.io as Spotify on Pixoo64, was a small Windows app that showed the album artwork of whatever you were playing on Spotify on a Divoom Pixoo 64. It connected to your Spotify account and updated the display automatically whenever the track changed. The app window let you sign in to Spotify, connect to the Pixoo by IP address, set how often it checked for a new track, and start or stop updates. Like Pixoo 64 Tools, it offered a choice of scaling method and image filter, a 1:1 crop and a grid preview of the 64x64 result. Mike showed it working in his February 2025 Pixoo 64 video on YouTube. It was listed in 2025 for $2.50 or more on itch.io, linked from PyroSoft.pro, where it was also marked free for Patreon patrons. It has since been retired. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: Shown working Feb 27, 2025; on itch.io by Jun 2025 ## Screenshots ![Spotify Pixoo window with connection settings and a 64 by 64 album-art preview](https://pyrosoft.pro/store-assets/media/spotify-for-pixoo-64/spotify-for-pixoo-64-r1.png) --- # Tech Helper > Technical support and troubleshooting utility for Windows systems. Canonical page: https://pyrosoft.pro/software/tech-helper Status: deprecated Platforms: Windows Tech Helper was a Windows maintenance utility Mike wrote during his school IT work to put common support jobs in one place. It came in two editions: a command-line menu for quick, discreet use, and a fuller .NET program with a cleaner window and more visual features. Its itch.io spec list, which follows the command-line menu, covered IP tools (view configuration, release and renew, tracert, netstat, nslookup and ping), a built-in task manager and services manager, and Check Disk options (read-only, with repair, or scheduled for the next startup). The command-line menu also offered removing the Sality keylogger, fetching SASIxp and ClassXP shortcuts, backing up user files to a server and disconnecting a user from a server. The GUI's menu had IP Tools, Task Manager, Services Manager and Disk Utilities entries, added System Info and CPU Information, and still marked its Sality, shortcut and backup items as in progress. The command-line build published on itch.io carried AUSD branding, from Alisal Union School District, where Mike worked as a computer technician from 2007 to 2010. Both editions were later shared on itch.io as Tech Helper (2008). Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: .NET program and a Windows batch script ## Screenshots ![Tech Helper GUI with its menu of IT tools open](https://pyrosoft.pro/store-assets/media/tech-helper/tech-helper-r1.png) ![Tech Helper command-line menu with 10 options](https://pyrosoft.pro/store-assets/media/b696565623-960.webp) ![Tech Helper GUI IP Tools submenu above the command-line menu](https://pyrosoft.pro/store-assets/media/tech-helper/tech-helper-r3.png) --- # The Hacker's Toolkit > A hacking sim played across desktop apps that mimic real hacker tools. Canonical page: https://pyrosoft.pro/software/the-hackers-toolkit Status: deprecated Platforms: Windows The Hacker's Toolkit was a mixed-reality hacking simulation prototype. You were thrust into the dark web and handed a limited set of tools by an underground "security" organization called the HTK Group. Prove you had what it takes and you would earn membership, bigger jobs and bigger risks. The game was designed to be played across separate desktop applications that mimicked real hacker tools, all connected to the same save file: a password cracker, port scanner, decrypter, encrypter and crypto wallet to start, with upgrades such as steganography, firewall bypass, trace route, VPN and facial recognition planned as your dark-web reputation grew. New jobs were to arrive through the HTK Group's secure messaging service, and the story was to reach into remote desktops, QR codes, cryptography and websites such as the HTK Group's htk.icu and the fictional company MantiCorp's site. It was built across several engines and tools, including Unreal Engine 4.27 and 5 with MetaHumans and live face capture, Unity 2022, DreamOS, GameMaker Studio 2, Visual Studio 2022 and web technologies. The prototype first appeared on itch.io in July 2021, followed by dev updates, a gameplay mission preview and an early trailer draft on YouTube through February 2022. In 2022 the itch.io page was relaunched with more screenshots and a Windows pre-order at $9.99, but no playable build appears in any archived copy of the page, and by December 2023 the pre-order had been removed. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: July 2021, as a prototype page on itch.io - Tech: Unreal Engine 4.27 and 5, Unity 2022, GameMaker Studio 2 ## Screenshots ![In-game lock screen for the user Jack Marley](https://pyrosoft.pro/store-assets/media/1cfdc9b4db-960.webp) ![Decrypter app with progress bars for encrypted archives](https://pyrosoft.pro/store-assets/media/28de02d2ed-960.webp) ![Fictional MantiCorp website in an in-game browser](https://pyrosoft.pro/store-assets/media/c81d8efa4f-960.webp) ![In-game email inbox with a welcome message about a SmartID](https://pyrosoft.pro/store-assets/media/the-hackers-toolkit/the-hackers-toolkit-r6.png) ![HTK Group messaging app composing a message](https://pyrosoft.pro/store-assets/media/the-hackers-toolkit/the-hackers-toolkit-r2.png) ![Lock screen with a mountain-lake wallpaper and Press any key to login](https://pyrosoft.pro/store-assets/media/feaae49b95-960.webp) ![HTK Group Secure Login window](https://pyrosoft.pro/store-assets/media/the-hackers-toolkit/the-hackers-toolkit-r1.png) --- # Video Tools > Remux MKV and convert almost any video to MP4. Canonical page: https://pyrosoft.pro/software/video-tools Status: deprecated Platforms: Windows Video Tools by MikeTheTech was a free Windows utility for getting videos into MP4. It did two jobs: remuxing MKV files into MP4 containers quickly, and transcoding almost any other video, including AVI, FLV, MOV, MPEG, WMV and 3GP, to MP4. It worked with folders: you copied your files into the input folder, opened the app and chose Remux MKVs to MP4s or Transcode Videos to MP4s, and the finished MP4s appeared in the output folder. Under the hood it used FFmpeg, licensed under the LGPLv2.1. Mike introduced it in September 2023 in a short YouTube video, “Convert ANY video to MP4 with my new free tool!”. Its itch.io page has since been taken down. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: FFmpeg ## Screenshots ![Video Tools window with Remux MKVs and Transcode Videos buttons](https://pyrosoft.pro/store-assets/media/video-tools/video-tools-r1.png) ![Video thumbnail with the Video Tools window and the title Any Video to MP4](https://pyrosoft.pro/store-assets/media/50f340aea1-960.webp) --- # Virtual Studio (Unreal Engine 5) > A live 3D broadcast studio in Unreal Engine, wired into Twitch. Canonical page: https://pyrosoft.pro/software/virtual-studio-ue5 Status: deprecated Virtual Studio is a virtual 3D studio Mike created in Unreal Engine. It brings the host's webcam, video capture devices and Twitch interactions into one scene, with effects such as coins dropping when viewers donate and several ways to control it. PyroSoft's timeline lists it as an Unreal Engine 5 live virtual-production project in December 2024. The public footage and images come from the 2020-2022 studio, which Mike built in Unreal Engine 4 and shared on the MikeTheTech YouTube channel. Its first set appeared in September 2020, and a fly-around demo of it, Virtual Studio Tour, was published on itch.io and on his website in December 2020. A new set followed in March 2021 (first shown 17 March, then toured in 'A Special Announcement and Studio Tour'), along with Twitch chat integration in the studio and, that spring, an interactive interview show. Audio-reactive effects arrived in October 2021, a tutorial on live cameras in a virtual studio in December 2021, and a March 2022 update brought Twitch chat back to the set. Mike's 'Virtual Studio Live' project page features the March 2021 studio tour, and his 'Virtual Studio Tour' page carries the 2020 demo. No public footage of an Unreal Engine 5 build was found, so the pictures here show the 2020-2022 studio. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: Unreal Engine ## Screenshots ![Virtual studio set with beige columns, a flame-panel desk and wall screens](https://pyrosoft.pro/store-assets/media/24b6e92a63-960.webp) ![Mike at a flame-panel desk in the March 2021 virtual studio set](https://pyrosoft.pro/store-assets/media/9f7c189383-960.webp) ![Mike at the flame-panel desk of the 2020 virtual studio set](https://pyrosoft.pro/store-assets/media/virtual-studio-ue5/virtual-studio-ue5-r9-35bb9bff-crop.webp) --- # WinDebbie > Windows desktop chatbot built on the A.L.I.C.E. AIML framework. Canonical page: https://pyrosoft.pro/software/windebbie Status: deprecated Platforms: Windows C++ implementation of the A.L.I.C.E. AIML framework for Windows with custom personalities and a visual UI. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Version: 3.0 - Tech: C++ and AIML ## Screenshots ![WinDebbie chat window with green text over a falling-character effect](https://pyrosoft.pro/store-assets/media/b15f0d88c9-960.webp) ![WinDebbie 3.0 starting up and loading its AIML files](https://pyrosoft.pro/store-assets/media/03f1a08eb4-960.webp) ![WinDebbie running on Windows 11 beside File Explorer](https://pyrosoft.pro/store-assets/media/f9e423c5ac-960.webp) --- # Anarchist Calculator > Humorous Windows calculator remake with a calendar and memo pad. Canonical page: https://pyrosoft.pro/software/anarchist-calculator Status: deprecated Platforms: Windows Anarchist Calculator was an early PyroSoft Productions release that Mike shared on the PyroSoft forum in October 2004: a playful remake of the Windows calculator. It kept the familiar calculator but moved parts of the window around and rewrote the menus and messages with a sense of humor, so “Windows Help Topics” became “Help! I'm stupid!” Over the following days it gained a calendar that follows the Windows date and time (v1.1) and a built-in memo pad for jotting down results without opening Notepad (v1.2). Windows 98 builds followed for forum members still on that system, and the resource source files were posted on the forum in November 2004. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Version: 1.3 - First release: Oct 10, 2004, on the PyroSoft forum --- # ChatGPT Completion Script > Script for adding ChatGPT completions to apps and workflows. Canonical page: https://pyrosoft.pro/software/chatgpt-completion-script Status: deprecated ChatGPT Completion Script was an automation script from October 2023 for bringing ChatGPT completions into other applications and workflows. It came from the same stretch of PyroSoft's AI work as the ChatGPT sample templates for Replit, which included a GPT-3 completion template, and the LangChainCSV and LangChainDoc Processing utilities. No public download or source code is available, so it is kept here as part of PyroSoft's history. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. --- # Claude File Context > Open-source tool for managing file context with Claude. Canonical page: https://pyrosoft.pro/software/claude-file-context Status: deprecated Claude File Context was a tool, released in August 2024, for managing file context when working with Anthropic's Claude AI assistant. PyroSoft's timeline lists it as open source, but no public download or source code is available, so it is kept here as part of PyroSoft's history. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. --- # EDIDtvScraper > Extracted and analysed EDID data from displays and TVs. Canonical page: https://pyrosoft.pro/software/edidtvscraper Status: deprecated EDIDtvScraper was a utility for extracting and analysing the EDID information that displays and televisions report about themselves. It appears on the PyroSoft project timeline as released in October 2024. No download, source code or screenshots of it are online any more, so the details beyond that timeline entry are not known. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. --- # GameSalad Top-Down Shooter Project Files > Project files for Mike's 11-part GameSalad top-down shooter tutorial. Canonical page: https://pyrosoft.pro/software/gamesalad-top-down-shooter-source Status: deprecated Platforms: Windows GameSalad Top-Down Shooter Project Files were the companion downloads for Mike's free YouTube tutorial series on building a top-down space shooter in GameSalad Creator. The series ran to eleven episodes between February 2017 and January 2019, covering movement, camera control, obstacles, shooting and HP, animations and explosions, enemies and a second level, enemy HP and scoring, scrolling backgrounds, dynamic explosions and room borders, and a second enemy type with progressive spawners. The itch.io page offered the GameSalad project as it stood at Episodes 9, 10 and 11, so viewers could open it and follow along. Downloads were name-your-own-price; earlier video descriptions offered the files for a donation of $1 or more. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: Files from Episode 9, Mar 5, 2018 (series began Feb 2017) - Tech: GameSalad Creator ## Screenshots ![GameSalad top-down shooter cover with the game running, the GameSalad logo and the series title](https://pyrosoft.pro/store-assets/media/gamesalad-top-down-shooter-source/gamesalad-top-down-shooter-source-r1.png) --- # HazMat Clock Screensavers > Custom clock screensavers made for the band HaZmAt. Canonical page: https://pyrosoft.pro/software/hazmat-clock-screensavers Status: deprecated HazMat Clock Screensavers was a collection of custom clock screensavers made for the band HaZmAt, with band-themed design elements, released in May 2006. It was part of a run of work for the band: PyroSoft's timeline also lists Space Warz 3: HaZmAt Edition, and Mike's own project history mentions a game he released to accompany an audio CD for the indie punk band. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. --- # Integrity Messenger > Instant messaging client with encryption and privacy features. Canonical page: https://pyrosoft.pro/software/integrity-messenger Status: deprecated Integrity Messenger was an instant messaging client from July 2006 with encryption and privacy-focused features, one of the earliest projects on PyroSoft's timeline. No public download or source code is available, so it is kept here as part of PyroSoft's history. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. --- # LangChain Sample Templates for Replit > ChatGPT and LangChain starter templates for Replit (GPT-3). Canonical page: https://pyrosoft.pro/software/langchain-replit-templates Status: deprecated In October 2023 PyroSoft created a set of ChatGPT sample templates for Replit. The set included a completion template and two LangChain templates, one for loading CSV files and one for loading documents, all using GPT-3. They sat alongside PyroSoft's other 2023 LangChain projects, LangChainCSV and LangChainDoc Processing. No public copy of the templates could be found, so they are kept here as part of PyroSoft's history. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: ChatGPT (GPT-3) and LangChain --- # LangChainCSV > CSV data analysis tool built on LangChain. Canonical page: https://pyrosoft.pro/software/langchaincsv Status: deprecated LangChainCSV was a CSV data processing tool from September 2023 that used LangChain for AI-assisted analysis and manipulation of a file's contents. A related public GitHub repository, LangChainCSV-HealthExample, was described as a CSV file processing script for ChatGPT and LangChain, written in Python. That repository is no longer online, so LangChainCSV is kept here as part of PyroSoft's history. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: LangChain (Python) --- # LangChainDoc Processing > LangChain utility for AI text analysis and extraction. Canonical page: https://pyrosoft.pro/software/langchaindoc-processing Status: deprecated LangChainDoc Processing was a document processing utility from November 2023 that used LangChain for AI-powered text analysis and extraction. It followed LangChainCSV (September 2023) on PyroSoft's project timeline. No public download or source code is available, so it is kept here as part of PyroSoft's history. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: LangChain --- # Matrix Screensaver > Matrix-style digital rain screensaver with custom effects and colors. Canonical page: https://pyrosoft.pro/software/matrix-screensaver Status: deprecated Matrix Screensaver is one of the earliest entries on PyroSoft's timeline: a Matrix-style digital rain screensaver with customizable effects and colors, released in March 2006. It was the first of three screensavers PyroSoft released that spring, followed by the Uplink Screensaver in April and the HazMat Clock Screensavers in May 2006. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. --- # PHilliP > PHP AIML chatbot that replied to forum posts from its own account. Canonical page: https://pyrosoft.pro/software/phillip-aiml Status: deprecated Platforms: Web PHilliP was the PHP side of PyroSoft's early chatbot work. According to Mike's project timeline, after his C++ Alice work he continued with AIML datasets and built a PHP version, codenamed PHilliP. Rather than put it on a simple chat site, he wired it into the community's forum software, where it had its own user account and could reply to any post within one board. The timeline dates PHilliP to March 2007. No public code, screenshots or download of PHilliP could be found, so PyroSoft keeps it here as part of its history. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: PHP and AIML --- # Pixoo-Paint > A pixel-art drawing tool made for the Pixoo 64 LED display. Canonical page: https://pyrosoft.pro/software/pixoo-paint Status: deprecated PyroSoft's timeline describes Pixoo-Paint as a digital art tool for the Divoom Pixoo 64 LED display, built for pixel-perfect editing of artwork for the panel. The timeline lists it as released in February 2025, alongside Pixoo 64 Tools, Pixoo 64: Snake and Spotify for Pixoo 64, but no public download, repository, store page or video for it has been found. It is part of PyroSoft's legacy collection. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: Listed as released Feb 2025; no public release found --- # Post Warz > A GameMaker side-scrolling platformer, released as a demo. Canonical page: https://pyrosoft.pro/software/post-warz Status: deprecated Post Warz was a side-scrolling platformer made in GameMaker under the PyroSoft Productions name, developed in the open on PyroSoft's community forums as "Post Warz: The Quest for l33t." It featured original music by composer Christian Ponte and pixel art by Nessa Bok, and it was released as a demo. Development stretched over several years. In February 2004 Mike described a plan to split the game's code into small .PW1 files written in GML, so updates could ship as patches of a few kilobytes instead of a new download of the whole game (likely around 10 MB), which would also make it easier to mod. PyroSoft's timeline dates the release to September 2008, built in GameMaker 6. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: GameMaker 6 (GML) --- # Pyro's Air Ride > Top-down shooter set in 1942 with period aircraft. Canonical page: https://pyrosoft.pro/software/pyros-air-ride Status: deprecated Pyro's Air Ride was a top-down shooter, and the first of PyroSoft's Air Ride games. PyroSoft's project timeline describes it as set in 1942, with period-appropriate aircraft and combat. It was distributed as a download on MvpZERO.com, a small community site that hosted PyroSoft's early games. It was followed by two sequels, starting with Pyro's Air Ride 2, released on the community forums in September 2003, which itself received an expanded 2.1 upgrade in January 2004. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: 2003 or earlier --- # Pyro's Air Ride 2.1 > Expanded 2004 upgrade of the top-down shooter Pyro's Air Ride 2. Canonical page: https://pyrosoft.pro/software/pyros-air-ride-2-1 Status: deprecated Platforms: Windows Pyro's Air Ride 2.1 was an expanded upgrade of Pyro's Air Ride 2, the top-down shooter sequel PyroSoft released on its community forums in September 2003. Air Ride 2 had brought new graphics, a HUD showing your plane's damage percentage and remaining lives, pilot voice lines, eight-direction controls, new levels and bosses, new secrets, and four Time Trial difficulty levels with a high score table. Announced in October 2003 as part fix, part add-on, version 2.1 lengthened the game so it could no longer be beaten in 15 minutes, added new secrets, made the final boss beatable, and trimmed size, improved speed and fixed its data and error-log files. It was released on January 14, 2004 as a full download, so players did not need the earlier version. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Version: 2.1 - First release: Jan 14, 2004 --- # PyServe > Python web server framework with built-in development tools. Canonical page: https://pyrosoft.pro/software/pyserve Status: deprecated PyServe was a Python-based web server framework from September 2024, with built-in development tools and simple deployment. No public download or source code is available, so it is kept here as part of PyroSoft's history. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Tech: Python --- # QSuite Public SDK > Developer SDKs for quantum-safe cryptographic operations. Canonical page: https://pyrosoft.pro/software/qsuite-public-sdk Status: deprecated Platforms: Windows, macOS, Linux QSuite Public SDK was a pair of client libraries, one for Node.js/TypeScript and one for Python, for working with a quantum-safe key management service (KMS). They let an application create and list keys, encrypt and decrypt messages, and sign and verify data with post-quantum algorithms: Kyber512, Kyber768 and Kyber1024 for encryption, Dilithium2, Dilithium3 and Dilithium5 for signatures, and hybrid schemes that paired Kyber with X25519 and Dilithium with Ed25519. The SDKs came with TypeScript interfaces and Python type hints, supported JWT, OAuth and API-key authentication with automatic token refresh, and retried failed network requests. The Python SDK added a command-line tool, and the repository included examples for message encryption, signature verification and hybrid certificates. The SDKs talked to a compatible Quantum-Safe KMS backend through its HTTP API and did not work on their own. They were published as source code on GitHub in June 2025. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: Jun 19, 2025 (repository created) - Tech: TypeScript (Node.js) and Python --- # Space Warz > An early PyroSoft space combat game. Canonical page: https://pyrosoft.pro/software/space-warz Status: deprecated Space Warz was one of PyroSoft Productions' earliest games, a space combat game that started a small series: Space Warz 2 followed, and Space Warz 3: HaZmAt Edition was a custom version made for the band HaZmAt. PyroSoft's project timeline sums it up as a classic space combat game with battles and strategic gameplay elements; no archived page describes the game itself. It predates most of what survives online. In August 2003 the MvpZERO.com downloads page listed Space Warz among the PyroSoft games that were not added yet but would be up soon, and a September 2003 forum post about Pyro's Air Ride 2 recalls letting players fly around during the credits as a Space Warz touch. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: By Aug 2003; release date unknown --- # Space Warz 2 > Sequel to PyroSoft's early space combat game Space Warz. Canonical page: https://pyrosoft.pro/software/space-warz-2 Status: deprecated Space Warz 2 was the sequel to Space Warz, one of PyroSoft Productions' earliest games, and came before Space Warz 3: HaZmAt Edition. PyroSoft's project timeline describes it as an enhanced sequel with improved graphics and new gameplay mechanics, but no archived page names or describes the game itself. No screenshots, downloads or dates survive publicly. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. --- # Space Warz 3: HaZmAt Edition > Third Space Warz game, a custom edition for the band HaZmAt. Canonical page: https://pyrosoft.pro/software/space-warz-3 Status: deprecated Space Warz 3: HaZmAt Edition was the third Space Warz game, a custom edition made for the band HaZmAt. It was part of PyroSoft's early work. In August 2003 the MvpZERO.com downloads page listed "Space Warz 3 - HazMat Version" among the PyroSoft games that were not added yet but would be up soon; no archived copy shows the download itself. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - First release: By Aug 2003 (listed as upcoming); release date unknown --- # SteamDeckDriversPack > Steam Deck Windows drivers, bundled in one download. Canonical page: https://pyrosoft.pro/software/steamdeck-drivers-pack Status: deprecated Platforms: Windows SteamDeckDriversPack collected the Windows drivers for Valve's Steam Deck in one place, so people installing Windows on the handheld could get them in a single download. It had separate packs for the LCD and OLED models, both published on 23 February 2025. Each pack covered the APU driver, Wi-Fi, Bluetooth, the SD card reader and the audio drivers, with a short note on how to install each one. The OLED notes added that Bluetooth needed a newer BIOS from SteamOS Beta 3.6.9 or later, installed before Windows, and that Bluetooth audio was output only at the time. The repository is no longer online; this description comes from archived copies. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Version: 25.2.23 (LCD and OLED packs) - First release: Feb 23, 2025 --- # Sunshine Script Builder > Built Sunshine host scripts for your own game-streaming setup. Canonical page: https://pyrosoft.pro/software/sunshine-script-builder Status: deprecated Sunshine Script Builder was an open-source tool for writing host scripts for Sunshine, the self-hosted game-streaming server, generating launch configurations for your own setup. It was published on GitHub under GPL-3.0 in August 2025. The repository is no longer online and no archived copy or screenshots were found, so nothing more is known about how it worked. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - License: GPL-3.0 --- # Transite > A super-simple browser that makes any website transparent. Canonical page: https://pyrosoft.pro/software/transite Status: deprecated Platforms: Windows Transite was a super-simple browser that made any website see-through. Mike built it because he wanted to make Discord transparent so he could chat while watching videos, then made it work with every site. It opened Discord's web app by default; typing another address into the box at the bottom and pressing Enter or Go loaded that site, and search terms that weren't valid addresses went to Google. A slider set the window's opacity anywhere from 10 to 100 percent, and the current value showed in the title bar. Transite was a Windows app written in C# on .NET 7 with Microsoft Edge WebView2. Its source code was published on GitHub in June 2024. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Version: 24.6.27 - License: No licence file - First release: Jun 27, 2024 - Tech: C#, .NET 7, Windows Forms, WebView2 --- # Uplink Screensaver > Custom screensaver with network-connectivity themes. Canonical page: https://pyrosoft.pro/software/uplink-screensaver Status: deprecated Uplink Screensaver was a custom screensaver with network-connectivity themes and visual effects, released by PyroSoft in April 2006. It sits between the Matrix Screensaver (March 2006) and the HazMat Clock Screensavers (May 2006) in PyroSoft's early run of desktop screensavers. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. --- # VoidChat > Modern rewrite of 2006's ajChat web chat. Canonical page: https://pyrosoft.pro/software/voidchat Status: deprecated Platforms: Web VoidChat was a modern rewrite of ajChat, rebuilt with current web technology. ajChat was the open-source AJAX web chat that ran on Mike's GrungeMedia network as gm chat in the mid-2000s. PyroSoft's timeline lists VoidChat as released free on GitHub in October 2025; that repository is no longer available, so VoidChat is kept here as part of PyroSoft's history. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. --- # WinPick > Unlock hidden Windows features. Canonical page: https://pyrosoft.pro/software/winpick Status: deprecated Platforms: Windows WinPick, a play on 'Windows lockpick', was a Windows 10/11 desktop app for browsing and running scripts that customise, optimise and tweak Windows. Scripts were sorted into categories in the left panel. A double-click ran one and showed its output in the built-in console, and a right-click offered more options, such as running or undoing a script as administrator. WinPick downloaded scripts from the public WinPick-Scripts repository by default, or from any GitHub repository, branch and folder the user chose; a New Script button started one from a template, and most scripts included an undo option. The client was written in Python with Tkinter. Mike moved it from a private repository to GitHub in April 2025 and released it as open source under the GPL-3.0, at version 25.4.12. Its source code and the script library, mostly PowerShell, remain on GitHub. Legacy reference only. This product is no longer distributed. No purchase or outbound links are provided. ## Recorded details - Version: 25.4.12 - License: GPL-3.0 (client) - First release: February 2025; on GitHub Apr 11, 2025 - Tech: Python 3, Tkinter; PowerShell scripts --- # Delivering the tested arena build without changing the server around it > The exact public package, preserved rollback and a separate desktop browser check. Canonical page: https://pyrosoft.pro/blog/delivering-the-tested-arena-build-without-changing-the-server-around-it Live development journal; no publication date. Work period: 2026-10-12 to 2026-10-12 Updated: 2026-10-21 Once the browser build was qualified, the deployment job was to deliver that same build. The October 12 release record ties Battle Bot Arena Engine 2.0.0 to a specific five-file WebGL package, rather than treating any successful Unity export as interchangeable. The package contained the page, loader, framework, WebAssembly and data payload. Its compression fallback matched the existing hosting behavior, so the update could use the current server configuration. The old site was preserved before an atomic switch to the new release. After activation, the four engine and loader payloads matched their expected bytes over HTTPS. The page received the site's existing analytics injection, so its served response was checked against a separately prepared expected result. That's a good example of why the source file's hash and the public HTML response aren't always the same check. The deployment record also verified retained legacy assets for cached clients and kept private manifests, archives and diagnostic paths out of the public site. The surrounding service and hostname comparisons remained unchanged across the deployment captures. A separate report from the Windows build owner recorded a fresh public desktop-browser check: Workshop and components, preflight, the Garage handoff, actual driving, weapon spin and the Forge switch. That is distinct from the deployment audit's direct file and HTTP checks. This release still wasn't mobile-qualified. The wrapper recommended desktop keyboard and mouse, and the source acceptance explicitly excluded touch input. The next browser milestone needs a deliberately tested mobile artifact and a complete save/load editing path, alongside audio and performance checks. For this stage, the important result was getting the tested desktop experience onto the site with its identity and recovery path preserved. --- # Battle Bot Arena Engine 2.0 reaches the browser > Workshop, Garage and combat behavior in the exact WebGL build. Canonical page: https://pyrosoft.pro/blog/battle-bot-arena-engine-2-0-reaches-the-browser Live development journal; no publication date. Work period: 2026-10-12 to 2026-10-12 Updated: 2026-10-21 Battle Bot Arena Engine is about building a robot and finding out what it does when the arena pushes back. The October 12 milestone brought the 2.0.0 Unity build into a desktop browser, with an acceptance record that followed actual input and simulation behavior. The build included Workshop, Garage, Tournament and Local Versus scenes. The browser checks covered choosing parts and paint, preflight, saving the bot and handing its file into Garage. From there, the test drove forward and backward, steered, activated the weapon and switched the arena. The useful evidence went beyond a button press being sent. Recorded position and rotation changed, the weapon spun up, and the Forge burner produced damage during contact. The supplied acceptance also records AI, impact and detachment, knockout and reset behavior. There were limits worth keeping attached to this milestone. Saved JSON persisted, but Workshop didn't have a Load control, so that wasn't proof of a complete re-edit workflow. Audible output, mobile input and optional online integration weren't qualified. The test also didn't establish a reliable foreground frame-rate benchmark. One browser issue did lead to a concrete wrapper correction. A denied fullscreen request produced an uncaught error, so the page was changed to catch the denial and explain the fallback. The retest covered that failure path; successful native fullscreen remained a separate check. What I like here is that the build was judged through the things you'd actually try: create a bot, bring it into the arena and see movement, weapon activity and damage. That gave the WebGL package a specific desktop qualification before the separate work of putting those exact files on the public site. --- # DZCM: a context-mixing codec of our own > A new experimental backend, with its strong and weak cases recorded. Canonical page: https://pyrosoft.pro/blog/dzcm-a-context-mixing-codec-of-our-own Live development journal; no publication date. Work period: 2026-06-04 to 2026-06-04 Updated: 2026-10-21 Later on June 4, DevZIP added DZCM, a new context-mixing backend. The commit and design notes describe an original implementation rather than another wrapper around an existing compression library. The idea is to predict the next bit from several kinds of context: recent bytes, words, sparse patterns and matches with earlier input. A mixer combines those predictions, and an arithmetic coder turns them into the compressed stream. The decoder repeats the same updates to reconstruct the original bytes. The first recorded backend-only results were mixed in a useful way. DZCM compressed the text corpus about 30 percent smaller than the LZMA2 backend and improved code by roughly seven percent, but it was still behind ZPAQ-5. It performed worse on the executable corpus. Those are comparisons within the same DevZIP pipeline, not a new aggregate win over every archiver. The backend could be selected directly or included in a best-of-N pool. Choosing the smallest candidate per block can protect the size result when one codec isn't a good fit, although trying another codec still consumes time and memory. Keeping the winning codec identity is what makes the mixed archive decodable. The record includes byte-exact verification and additional per-file hash comparison for the code corpus. The roadmap names better context-state modeling, executable structure and hints from the transform pipeline as areas to explore next. What I like about this stage is that it leaves the weak result on the page. We have a working experimental codec and a clear reason to continue improving it. The next decision should come from another measured comparison and round trip, rather than assuming the new backend belongs in every default just because we wrote it. --- # Compression levels and the cost of a smaller archive > Best-of-N selection and content-aware transforms in the June overhaul. Canonical page: https://pyrosoft.pro/blog/compression-levels-and-the-cost-of-a-smaller-archive Live development journal; no publication date. Work period: 2026-06-04 to 2026-06-04 Updated: 2026-10-21 The June DevZIP overhaul made the size-versus-time choice more explicit. The engine and Windows interface gained compression levels, with a best-of-N backend selecting the smallest result for each solid group and recording the winning codec for extraction. The levels could use different pools of codecs and transforms. Content-aware work included lossless JPEG reconstruction through Brunsli and a more expensive PNG path using preflate at the higher level. This wasn't simply turning one general compression setting further to the right. On the recorded 97.41 MB per-category sweep, the default balanced result totaled about 47.98 MB, compared with 54.32 MB for the 7-Zip LZMA2 baseline. Max reached about 44.56 MB. Those correspond to roughly 11.7 and 18 percent smaller on that particular sweep. The time cost was substantial. The same table totals about 275 seconds for balanced and 574 for max, against 12.5 seconds for the baseline. That is why the smaller max result shouldn't be described as the default's performance, or as a good tradeoff for every archive job. The records describe byte-exact round trips for the reported DevZIP outputs. They also show competitors ahead on individual code and executable corpora, even where DevZIP won the aggregate. The earlier April mixed-large run used a different dataset, so its percentage isn't directly comparable to this sweep. For me, the useful progress is the ability to make the tradeoff deliberately. If storage size matters most, there is a path to try; if turnaround time matters, use a faster level. The next codec work would explore improving the compression pool while keeping the archive readable and its reconstruction verifiable. --- # DevZIP opens up its archive engine > A native Windows engine, a readable container and a measured starting point. Canonical page: https://pyrosoft.pro/blog/devzip-opens-up-its-archive-engine Live development journal; no publication date. Work period: 2026-04-13 to 2026-04-13 Updated: 2026-10-21 DevZIP asks a straightforward question: can we make smaller archives for mixed real-world files while keeping the format understandable and the engine maintainable? The April 13 source publication put the native C++ engine, command-line tools and Windows WPF shell into the public repository. The archive format is .dvz. It records the backend identity so the decoder knows how a block was stored, while the pipeline handles preprocessing, solid groups and deduplication. The desktop interface delegates the actual compression and extraction work to the native command-line engine. The initial retained README described a best-of-two default and a mixed-large benchmark where DevZIP produced about 143.8 MB against about 144.8 MB for the 7-Zip LZMA2 baseline. That was a modest size improvement with a real time cost: roughly 304 seconds against 107 on that recorded run. I like having both numbers in the same explanation. A smaller archive can be valuable, but someone making a quick transfer may care much more about how long it takes. The project needed to show the tradeoff rather than presenting one size result as a universal win. The Windows preservation contract was deliberately bounded too. It covered things such as file bytes, relative paths, empty directories and modified timestamps, while excluding ACLs, alternate streams, EFS metadata and sparse-hole maps. That makes this different from claiming a complete system-backup format. This was a source-publication milestone, with benchmark results recorded in the project rather than independently rerun for this article. The next work broadened the compression choices and content-aware transforms, keeping byte-exact reconstruction as the check that mattered before celebrating a smaller output. --- # Route, gather, then write the answer once > A simpler pipeline and a more practical automatic model choice. Canonical page: https://pyrosoft.pro/blog/route-gather-then-write-the-answer-once Live development journal; no publication date. Work period: 2026-09-12 to 2026-09-13 Updated: 2026-10-21 The next FreeSpark plan started with a measurement: the tools weren't the main source of delay. The model was repeatedly reading long prompts, sometimes across several calls for a single answer. Changing the prompt and conversation also prevented the engine from reusing its existing context efficiently. The replacement pipeline routed the request, gathered useful context concurrently, wrote one streamed answer and checked it in code. A fixed conversational prompt let ordinary follow-ups reuse more of the existing conversation. Narrow tasks could still finish directly through code without a model call. Pass 8's 41-case record showed 40 automatic passes on the 2B model and 41 on both the 8B and 9B models. Blind answer judgments and tone scores remained separate. Some of the bare-model comparisons reused the earlier recorded baseline, so this wasn't a brand-new paired run for every number. The timing notes also preserve an important detail: hidden browser panes slowed the tests down, and the quoted 2B timing preceded its final prompt change. I don't want to turn those measurements into a speed promise for every computer. They were useful evidence for removing unnecessary work from this implementation. The latest commit also changed Auto to load one step below the strongest model estimated to fit. On an eligible memory budget that meant the 8B choice rather than the top 9B option, with the larger model still available manually. Fitting in memory doesn't automatically make a model the most comfortable default. FreeSpark still needs broader device, image and recovery qualification. But this pass made the architecture easier to explain: find the information, keep the conversation, and spend the model's time on the answer instead of repeatedly asking it how to begin. --- # Checking whether Spark actually helps the model > A growing prompt suite, bare-model comparisons and fixes from real answers. Canonical page: https://pyrosoft.pro/blog/checking-whether-spark-actually-helps-the-model Live development journal; no publication date. Work period: 2026-09-10 to 2026-09-11 Updated: 2026-10-21 Adding tools around a small model only helps if the answers get better. The September 10–11 FreeSpark work made that a question we could test, comparing the same requests through Spark and through the bare model. One early comparison found a useful regression. Asked to sort a supplied list, the bare model preserved the numbers while Spark invented a leading value. The fix moved narrowly defined numeric-list operations into deterministic code. Sorting the user's numbers shouldn't depend on the model reproducing every digit correctly. The suite then grew to 41 cases, including conversation, code, strict formatting, misleading questions, supplied material and injected instructions in research results. Routing changes kept private-context questions out of web search and treated pasted content as local material. A chart tool only needed to run when a chart was actually requested. Pass 7 recorded 38 of 41 automatic checks for the 2B Spark route and 39 of 41 for the 8B route, against 32 of 41 for the corresponding bare runs. The blind-graded results were recorded separately. Those scores describe this suite and harness, not a universal intelligence score. The tests also needed review. A correct poem could fail an overly literal word check, and a mechanical formatting pass could miss an answer that sounded awkward or searched unnecessarily. Keeping the actual answers alongside the scores made those differences visible. For me, that's the useful outcome of this stage: a way to find where Spark improves a model and where the extra machinery hurts. The next pass used that evidence to reduce repeated model calls, improve responsiveness and keep more of the conversation feeling natural. --- # Making local work survive the next conversation > IndexedDB chats, workspace previews and a context budget. Canonical page: https://pyrosoft.pro/blog/making-local-work-survive-the-next-conversation Live development journal; no publication date. Work period: 2026-09-09 to 2026-09-10 Updated: 2026-10-21 An assistant becomes much more useful when the work is still there after you close the tab. The next FreeSpark changes moved chats into IndexedDB with a one-time migration and cross-tab synchronization, then gave the model a more deliberate context budget. That addresses two different limits. Browser storage needs to preserve the conversation reliably, while the language model can only read a bounded amount of material at once. Summarizing older turns and reserving room for the answer is more predictable than sending everything until a small model runs out of context. Workspace changes also gained a preview, approval, history and revert path. If the assistant is about to edit a file, you should be able to see the proposed change and recover an earlier version. A chosen folder remains the boundary for those tools; having file features in the interface doesn't grant access to your entire computer. The application structure grew clearer too. Interface code was split into modules with an explicit initialization order. Local file context, richer text rendering and on-device Python chart work followed, giving documents and calculations a more useful place in the conversation. The earlier safety pass had also isolated JavaScript and previews rather than giving generated content ordinary application privileges. Those protections need to stay connected to the actual execution path as the interface evolves. This stage was about making the assistant a place to do work you can keep. Better persistence, a reviewable file change and a known context limit are less flashy than another model in the picker, but they're the details that decide whether you can return to a task and understand what happened. --- # FreeSpark: useful AI on the hardware you already have > Local inference, clearer online boundaries and the first reliability pass. Canonical page: https://pyrosoft.pro/blog/freespark-useful-ai-on-the-hardware-you-already-have Live development journal; no publication date. Work period: 2026-09-09 to 2026-09-09 Updated: 2026-10-21 FreeSpark starts with a practical idea: run an open language model on the GPU in your browser, without requiring an inference account or charging for each message. Then give that model useful ways to work with writing, calculations, documents and a folder you choose. The September 9 review concentrated on reliability before adding another long feature list. Arithmetic moved to a parser, ordinary writing took a shorter route, and tools stopped running simply because the model happened to mention them in its reasoning. The real-model checks showed why those changes mattered. A small model could load successfully and still fail a normal writing request. The recorded 0.5B probe returned closing markup, while the 1.5B model produced coherent writing but missed the requested sentence count. Loading a model and getting dependable answers are different milestones. Persistence and recovery received attention too. Failed saves became visible, partial stopped text was retained, and failed or replaced workers were cleaned up more carefully. Generated images needed durable data rather than temporary browser URLs that would disappear later. Local inference also needed a clear explanation. Model downloads can be large, and web research uses an online service. The language model running on your device doesn't make every tool offline. The default settings changed during the following work, so the early opt-in state shouldn't be mistaken for the final configuration. What I like about this foundation is that it keeps the product useful without pretending a small model can do everything. We can let code handle exact arithmetic, show when storage fails and qualify actual answers, then use the model where its ability to write and reason is helpful. --- # Connecting FriendlyIP to the rest of PyroSoft > Shared navigation without losing the local tool menu. Canonical page: https://pyrosoft.pro/blog/connecting-friendlyip-to-the-rest-of-pyrosoft Live development journal; no publication date. Work period: 2026-09-14 to 2026-09-14 Updated: 2026-10-21 A small web tool should be easy to reach again once you've found it. The September 14 website continuation added the shared PyroSoft navigation to FriendlyIP while keeping the site's own converter and related-tool navigation in place. The work began by comparing the local product files with the server copies. FriendlyIP was part of the six-domain comparison that found no drift before the header changes. That gave the update a known starting point instead of overwriting a product site that might have changed independently. The shared header came from a generator and common assets, with markers that let it update the intended section consistently. That's useful maintenance work: the product can keep its own interface while the company-wide links don't need to be manually recreated on every page. The final record reports all 43 product-domain HTML pages returning successfully, plus rendered checks on representative desktop and mobile pages. The navigation checks exercised opening the menu, closing it with Escape and returning keyboard focus. Local product navigation remained present. Those are navigation results. They don't independently prove that every IPv6 lookup, temporary PIN expiry or QR workflow passed a fresh end-to-end test during the header update. The underlying features and their online boundaries remain described in the preceding snapshot. For FriendlyIP, this was a useful presentation and accessibility step. You could keep using the address tools and move between PyroSoft products through a consistent menu. The core conversion idea stayed the same, while the surrounding site became easier to navigate and maintain across different screen sizes. --- # FriendlyIP: an address you can read over the phone > A documented snapshot of the IPv4 converter and its related tools. Canonical page: https://pyrosoft.pro/blog/friendlyip-an-address-you-can-read-over-the-phone Live development journal; no publication date. Work period: 2026-09-14 to 2026-09-14 Updated: 2026-10-21 Reading an IP address over the phone is a small task that gets awkward surprisingly quickly. FriendlyIP turns an IPv4 address into a six-character code, using an alphabet chosen to avoid several easily confused characters. The other person can turn the code back into the address. The useful part of the IPv4 design is that it doesn't need a lookup database. The address is represented as a number and encoded reversibly. The browser can do that conversion locally, so the core tool doesn't depend on creating a saved short-link record for each address. The retained source snapshot also includes three related paths. IPv6 beta uses online database-backed lookup codes. FriendlyPIN creates temporary codes with a one-hour lifetime. The QR page generates an SVG code in the browser. They belong in the same family, but they don't all have the same storage and connectivity requirements. That distinction matters if you're choosing a tool for a quick LAN setup or another handoff. A short code is a convenient representation of an address; it doesn't itself make the machine reachable, change router configuration or provide authentication. The dated September 14 website record confirms the product files were present and compared with their server copies before navigation work. It doesn't establish when each core feature was first created, so I'm using this as a documented snapshot rather than inventing an earlier release sequence. What I like about FriendlyIP is that the central idea stays easy to explain. Make an address less annoying to share, keep the reversible IPv4 tool simple, and label the online beta features clearly. Broader feature-specific runtime and expiry checks remain useful next work beyond the website verification described here. --- # Preserving the whole PSN identifier > Correct large-integer conversion, request limits and clearer attribution. Canonical page: https://pyrosoft.pro/blog/preserving-the-whole-psn-identifier Live development journal; no publication date. Work period: 2026-09-14 to 2026-09-14 Updated: 2026-10-21 An account ID can be larger than a signed 64-bit integer. The September 14 PSN finder update addressed a subtle consequence: casting Sony's returned value directly to an integer could clamp a large ID before we ever encoded it. The correction kept large JSON integers as strings and converted the decimal value into the required eight-byte little-endian representation without that signed-integer assumption. The implementation used GMP when available, BCMath as another path and a manual fallback. The work record includes comparison tests against the expected packed representation. That's a small amount of code with a very practical effect. A user shouldn't have to wonder whether the result is wrong because their account happens to fall on one side of a numeric boundary. The conversion needs to preserve the complete value before Base64 encoding it. The request limiter also moved from an unkeyed address-derived hash to a keyed HMAC with a persisted random secret and daily rotation. The deployment record checked that its storage directory was writable. Account-detail copy was revised to describe what wasn't retained, without pretending the service had no operational state at all. The landing page and tool also received matching attribution to Chiaki's original work and corrected Sony-host wording. Updated desktop and mobile screenshots followed. The website record reports the revised files deployed and the expected public copy read back. These checks establish the recorded conversion and deployment work, rather than a new authenticated PlayStation session performed for this article. The useful progress is clear: preserve the full identifier, explain the sign-in boundary accurately and keep the credits attached to the implementation that made the tool possible. --- # Finding the account ID a Remote Play client asks for > The retained baseline for the PSN Account ID Finder. Canonical page: https://pyrosoft.pro/blog/finding-the-account-id-a-remote-play-client-asks-for Live development journal; no publication date. Work period: 2026-09-13 to 2026-09-13 Updated: 2026-10-21 Setting up a Remote Play client can involve an account ID that isn't the same thing as the name you normally type into PlayStation. The PSN Account ID Finder exists to make that particular step easier to understand. The September 13 retained website baseline contains the server-side lookup flow. You sign in on Sony's own page, then bring back the redirect address carrying its authorization code. The tool exchanges that code, reads the account's numeric identifier and converts it into the Base64 representation expected by clients such as Chiaki. The byte order is part of that job. This isn't just taking the visible decimal digits and Base64-encoding the text. The identifier is represented as eight little-endian bytes before encoding. If that conversion is wrong, the result can look plausible while being useless to the client. The intended privacy boundary is also specific. The tool doesn't ask you to type your PlayStation password into a PyroSoft form. Its backend does process the returned code and account response for the request; that is different from an entirely browser-local conversion. The source describes avoiding stored account payloads and tokens. This baseline is a record of what existed when the website was captured, not an original launch date or a newly repeated successful login test. The next day's work corrected an important large-integer issue in that implementation and made the public explanation more precise. What I like about a tool like this is that it removes one confusing setup step. It doesn't need to become a whole account-management application. It needs to explain the handoff, produce the exact identifier format and be clear about which service handles each part of the request. --- # Steam Command Generator: useful commands with the right expectations > An App ID workflow, copy controls and a clear limit on guessed depot IDs. Canonical page: https://pyrosoft.pro/blog/steam-command-generator-useful-commands-with-the-right-expectations Live development journal; no publication date. Work period: 2026-09-13 to 2026-09-14 Updated: 2026-10-21 Steam Command Generator is a small web tool for a task that can otherwise involve a lot of copying and editing. Enter an App ID and it prepares console commands for app information, depot downloads and license-related requests, with individual and copy-all controls. The local source tries to add context from Steam metadata, including a game name, artwork and DLC names. If those lookups fail, it can still show a basic App ID result. That makes the command templates available, although the external API and proxy paths need their own reliability checks. There is an important limit in the implementation. The platform download examples use arithmetic around the App ID to suggest depot IDs. Those are heuristics, not verified platform-to-depot mappings. The DLC examples likewise shouldn't be treated as proof that a DLC's App ID is its correct download depot. The more dependable starting point is the information-query workflow and the explicit depot placeholder. Use the app's actual metadata to identify the intended depot, then build the download request around that value. Generating a license command also doesn't grant an entitlement Steam hasn't authorized. The retained website baseline and September 14 catalog update document the tool and improve its discoverability. I don't have a separate dated implementation history for each generator feature in these records, so this chapter is a snapshot of the workflow and its limits rather than a sequence of invented releases. The next useful improvement is specific: replace guessed depot relationships with verified metadata and make the fallback state obvious. I like the convenience of a ready-to-copy command, but it should also tell you which values are known and which still need to be selected for the game you're working with. --- # Moving Bourbon safely, then making the verification faster > Qualified candidate work and a later storage improvement that still needs its own gate. Canonical page: https://pyrosoft.pro/blog/moving-bourbon-safely-then-making-the-verification-faster Live development journal; no publication date. Work period: 2026-10-19 to 2026-10-20 Updated: 2026-10-20 Moving a game library sounds simple until the app also owns a guest disk, private runtime, saved credentials and paths another application has stored. The next Bourbon pass connected those pieces to shared storage and lifecycle rules, with recovery copies and verification built into the move. The October 20 audit update records Candidate05 completing 351 required groups with no failed groups. Four individual opt-in or platform subtests were skipped. Its exact private upgrade test started from production 26.10.19.2, and the M2 acceptance included native Steam focus, input, relaunch, Stop and restore. The moved SteamOS environment rendered, accepted input, suspended, resumed and powered off cleanly. Those are useful results for that candidate. Physical controller testing and the original affected M5 Max/macOS 27 report remained separate gaps. The work record doesn't turn an M2 success into a universal fix or describe this private candidate as a new public release. A later cleanup exposed another practical issue: checking extended attributes could launch an external process for every file. The newest source added a native macOS reader, keeping the same digest representation and conservative error handling. On the recorded 7,477-entry archival corpus, it produced the same manifest as the prior command path in 9.5 seconds. That last change came after Candidate05's qualification. It needs a fresh full candidate and gate, so I'm leaving it clearly marked as development work in this entry. The direction is encouraging: safer moves, more dependable session focus and less overhead during verification. The next step is to qualify the exact newer artifact and close the remaining hardware and input gaps, while preserving the recovery behavior that made these moves reviewable in the first place. --- # The audit that put saves and reset safety first > Protecting newer environments before broadening the feature work. Canonical page: https://pyrosoft.pro/blog/the-audit-that-put-saves-and-reset-safety-first Live development journal; no publication date. Work period: 2026-10-19 to 2026-10-19 Updated: 2026-10-20 Adding a new launch route also means teaching the rest of the app how to preserve it. The October 19 audit found an example we needed to address immediately: Complete Reset's existing retention rules didn't fully cover the newer SteamOS and native Steam environments. With the default keep-games and keep-saves choices, the audited version could still remove a guest disk or private-prefix saves from those newer routes. The response was to put their full environments into the preservation contract and add activity checks before teardown. If an integration was running, changed or couldn't be verified safely, reset needed to stop before destructive work. The remediation kept disks, authentication, providers and recovery records in place. The reset screen explained that choice, and unsafe relocation combinations were contained while the complete transaction path was developed. The updated audit records those reset fixes as released in 26.10.19.1. Ownership verification was another priority. Different purchase methods needed consistent decisions, and a provider outage couldn't be treated as proof that someone didn't own Bourbon. The following changes bounded requests, handled incomplete responses as retryable failures and preserved the existing state during outages. The audit records that batch as released in 26.10.19.2. There were updater and focus fixes in the same day's work, but I wanted the safety story to have its own chapter. We found a real gap after earlier tests had passed, added cases that exercised that gap, and kept the broader audit open. That is useful progress even though it isn't a flashy new feature. Your installed games and saves should be the starting point for recovery. A reset or repair needs to earn the right to touch them through explicit ownership and preservation checks. --- # Native Steam integration and a library you can use from the couch > A new bridge, bigger controls and more careful cloud-save setup. Canonical page: https://pyrosoft.pro/blog/native-steam-integration-and-a-library-you-can-use-from-the-couch Live development journal; no publication date. Work period: 2026-10-17 to 2026-10-18 Updated: 2026-10-20 If you already use Steam on your Mac, having another library view isn't the whole solution. The October 17 work added a native Steam bridge and Couch Mode, bringing more of the launch workflow into a familiar place while giving Bourbon a layout intended for a larger screen. There are two native Steam ideas here that are easy to mix up. A game with a supported Mac build can use that build directly. Native Steam integration can also hand supported Windows launches to Bourbon's managed runtime and per-game private Wine environments. The Steam client is native in that second case; the Windows game still needs translation. The bridge's setup became more automatic the next day, including preparation of its qualified runtime and corrections to install callbacks. Earlier rollback generations stayed part of the recovery story. That's useful because integration with an application people already depend on needs a way back when preparation or repair goes wrong. Save handling received attention too. Existing Steam AutoCloud seeds were preserved and imported before the private bottle was prepared, and aliases connected the expected Windows application folders. The aim was to start from the saves already available instead of creating an empty environment and discovering the missing progress later. Couch Mode got larger-display scaling and ultrawide cover-row corrections. It was the beginning of a more comfortable library experience, with additional acceptance work still needed around input, errors and different displays. What I like about this direction is that it connects the pieces people already use: their Steam account, their game library and a sensible launch route. It also raises the bar for repair and storage safety, because those pieces now cross more than one environment. --- # Keeping older tools and newer Steam clients in their own lanes > Targeted runtime work, safer repairs and evidence from the real client. Canonical page: https://pyrosoft.pro/blog/keeping-older-tools-and-newer-steam-clients-in-their-own-lanes Live development journal; no publication date. Work period: 2026-10-13 to 2026-10-16 Updated: 2026-10-20 Not every Windows program wants the same Wine setup. The October 13–16 work spent time on that problem from both ends: a changing Steam client and older 32-bit software that needed a more specific environment. The Steam record is particularly useful because it includes what happened on the actual M2 test Mac. The stock October client helper produced a black sign-in window. After the exact measured helper was added to the existing compatibility policy, the form rendered, literal keyboard input appeared, and a clean client restart returned to the signed-in Library. That verifies a client workflow on that host; it doesn't certify gameplay across the library. For older software, the Neverwinter Nights Aurora Toolset received a versioned, isolated runtime path. Repair preserved authored content and private configuration instead of recreating the workspace. Missing Wine system files could be bootstrapped without treating the user's work as disposable setup data. There were also corrections to controller and graphics selection. Choosing controller Off disabled the Wine gamepad backends. Structured graphics imports took priority over optional backend strings, helping the analyzer avoid turning a stray reference into a hard requirement. The common theme here is keeping a fix where it belongs. A tool-specific Wine build should help that tool. A Steam helper policy should recognize measured bytes. A controller preference should survive the preparation path that actually launches the game. There's still more to verify whenever the runtime changes, but this gives us a much better basis for those tests. We can name the program, the environment and the observed result, then work on the next failure without losing the working configuration or the files someone created inside it. --- # Giving SteamOS its own place in Bourbon > A separate guest lifecycle and tighter launch observation. Canonical page: https://pyrosoft.pro/blog/giving-steamos-its-own-place-in-bourbon Live development journal; no publication date. Work period: 2026-10-09 to 2026-10-12 Updated: 2026-10-20 Bourbon's normal Windows translation route and its SteamOS experiment solve different problems. Wine translates Windows software on the Mac. SteamOS Beta runs a separate Linux guest, with its own disk, sign-in and installations. The October 9 work gave that guest experience a clearer place in the app. The new SteamOS integration replaced the older Linux presentation and kept guest lifecycle handling isolated. Diagnostics became bounded, and a suspended session received a clearer state. That helps when the question is simply whether the guest is paused, still preparing or actually stopped. Pointer work followed over the next couple of days. Fullscreen geometry changes needed tracking to reset correctly, and held mouse drags needed to survive click anchoring. Those sound like small input details until you're trying to use a desktop or game and the pointer no longer matches what your hand is doing. The main Windows route was getting stricter at the same time. Orphan Wine clients stayed classified as busy, renderer changes required recovery snapshots, and native Steam launchers were preserved. Later October 12 fixes stopped stale renderer logs from certifying a new launch and improved cold-start observation. What this means is that Bourbon was doing more work to connect a result to the session that produced it. A log from an earlier run shouldn't make today's attempt look successful. A guest state shouldn't be inferred from a window that happens to exist. SteamOS remained a beta route, and the optional desktop guests retained their own gates. I like having these options available, but they need clear boundaries so choosing one doesn't unexpectedly change the Windows stack or a native Mac Steam installation. --- # Activation, installers and knowing which program we launched > Small recovery fixes followed by more careful Windows software analysis. Canonical page: https://pyrosoft.pro/blog/activation-installers-and-knowing-which-program-we-launched Live development journal; no publication date. Work period: 2026-10-02 to 2026-10-08 Updated: 2026-10-20 Sometimes the right update is a small one. Bourbon 26.10.2.5 fixed itch.io sign-in for people activating after a purchase, signing back in or setting up another Mac. Existing activated copies kept working. There was no reason to rebuild bottles or reinstall games to recover a purchase check. The October 8 work then expanded the focus to Windows programs and installers. Opening an installer on a fresh setup prepared the core Wine runtime first. When an installation produced several similarly named programs, Bourbon preferred a unique exact match and asked for a selection when the result was ambiguous. If you explicitly chose a utility, that choice stayed yours. That's the kind of detail that makes a launcher feel predictable. Picking a companion updater when you asked for the main application isn't helpful, even if both files technically run. The same update included a specific DPI correction for the verified PuTTY 0.84 x64 build, with explicit user overrides preserved. Process tracking also became more precise. Launches retained records tied to their bottle and executable, Stop coordinated with the observer, and retries waited for the previous process to exit. A selected graphics backend alone stopped being enough reason to blame that backend for an unknown failure. This is also where the current private development history has an import boundary. The October 8 import captured the existing Bourbon source; it wasn't the day all of those earlier features were first written. The older release notes supply that part of the timeline. The practical result was a more careful handoff from analysis to execution. Detecting requirements could help choose a setup, while actual program windows and behavior still decided whether that setup worked. --- # Smart Play starts figuring out unfamiliar games > Reading game files before choosing a runtime. Canonical page: https://pyrosoft.pro/blog/smart-play-starts-figuring-out-unfamiliar-games Live development journal; no publication date. Work period: 2026-09-29 to 2026-09-30 Updated: 2026-10-20 Up to this point, a good game profile did a lot of the work for Bourbon. The next step was helping when a game didn't have one. With 26.9.29.5, the Smart Play analyzer started reading the installed files and using that information to choose a setup to try. It looked for the engine, graphics requirements and likely game executable without running the program during analysis. That's useful with games that include a launcher, prerequisite installer and several other executables. We want to start the actual game with an appropriate route, rather than guessing from the first EXE in the folder. The release notes record tests including RuneScape: Dragonwilds on D3DMetal and Deep Rock Galactic through its game executable, avoiding a prerequisite installer that hung under Wine. They also list titles across several engines. That testing took place on an M5 MacBook Air; online play and a wider hardware matrix were still separate work. Launch reporting improved alongside the analyzer. Bourbon waited for Steam to be ready, checked whether it received the request, and handled launchers that needed a sign-in. A fatal error window stopped counting as a successful game. Cancelling monitoring after a game started left the game and Steam running. The following day's update fixed a Unity window offset with fullscreen defaults while preserving a user's windowed choice. It also corrected save synchronization through linked library paths; that fix had automated coverage, with a real external-library trial still outstanding in that record. For me, this is where the analyzer became useful as a starting point for compatibility work. It could make a reasoned choice and recover from some failures. We still had to verify what the game actually did after launch. --- # Making setup and repair less disruptive > Better readiness checks and more careful handling of active sessions. Canonical page: https://pyrosoft.pro/blog/making-setup-and-repair-less-disruptive Live development journal; no publication date. Work period: 2026-08-30 to 2026-09-06 Updated: 2026-10-20 When you open a gaming tool, a status check should tell you what's ready. It shouldn't quietly start a virtual machine or disturb another session just to find out. The late August Bourbon work focused on making that distinction much more dependable. Version 26.8.30.13 improved recognition of existing verified Game Porting Toolkit installations and repaired the managed Windows stack after updates while keeping the Library available. Steam recovery checked the CEF packages actually present in the installation. Civilization IV and its expansions also received a dedicated DirectX 9 route instead of asking the graphics stack for geometry features that route couldn't provide. The optional OS Experience work received its own safety changes. Read-only checks stopped launching UTM in the background, and recovery preserved existing VM bundles. That matters if you've already got a guest doing something useful. Looking at Bourbon's status shouldn't become an instruction to restart your other work. The September 6 candidate continued in that direction. Runtime-specific networking checks avoided treating a healthy WineCX profile like a broken Wine Staging installation. Busy drive mappings were preserved, support output was redacted more carefully, and prepared Steam profiles could offer Open Steam without changing game assignments. There was still a real problem on the board: fresh Windows Steam sign-in had rendered black on the M2 test Mac. The candidate notes explicitly left that unresolved. I want this history to include those moments, because a useful repair path and a successful packaging run don't automatically prove the client itself renders correctly. August's release record and September's candidate record describe different levels of completion, and the next work needed to follow the remaining visible failure. --- # When the menus work but the game world is black > Following the real game executable and isolating the graphics route. Canonical page: https://pyrosoft.pro/blog/when-the-menus-work-but-the-game-world-is-black Live development journal; no publication date. Work period: 2026-08-17 to 2026-08-17 Updated: 2026-10-20 A game can show you a perfectly readable menu and still have a broken 3D world. That makes compatibility work a little deceptive, because getting a window on screen can look like we're almost finished. The August 17 Bourbon update has a couple of good examples of what had to happen next. Palworld moved to the dedicated Twelve Year route, using CrossOver-source Wine with official D3DMetal, and launched its actual Shipping executable. The release record includes character creation and the opening beach cinematic. MECCHA CHAMELEON reached a correct main menu through the same general route. Those are different test milestones, so I'm keeping them separate rather than calling both games fully tested. There were smaller fixes with very visible effects. LEGO Batman 3 received a windowed 1280 by 720 configuration after Retina backing pixels caused the picture to overflow. Legends of IdleOn needed its own Wine 11.10 setup and launch option. Keeping Wine versions side by side meant fixing that title didn't move the runtime underneath everything else. Smart Play's profiles also became harder to accidentally undo. Verified choices kept control of their known-bad routes, and preparation happened in the bottle that would actually launch the game. That is useful when an old configuration or remote recipe would otherwise put a broken setting right back. This update also reduced setup dependencies and improved signing, settings and accessibility presentation. But the part I want people to understand is the troubleshooting approach: find which executable is really running, identify the rendering path it needs, and keep that choice scoped to the game. We can explain a specific improvement without turning it into a claim that every Unreal game now behaves the same way. --- # Bourbon 26: choosing the right way to play > Native Mac games, per-game Wine choices and a more useful Bottle Shelf. Canonical page: https://pyrosoft.pro/blog/bourbon-26-choosing-the-right-way-to-play Live development journal; no publication date. Work period: 2026-07-31 to 2026-07-31 Updated: 2026-10-20 If a game already has a working Mac version, we should be able to use it. That was one of the useful changes in Bourbon 26.7.31.1: recognizing a supported 64-bit macOS build and sending it down the native path, while keeping Wine available for Windows software. The release notes record Subnautica, Stardew Valley and Tangle Tower moving to that route. Stardew is a good example of why the distinction matters. Its Windows route had been marked unsupported in this work, while its Mac build worked. Picking the right version solved a different problem from tuning another graphics setting. Old 32-bit Mac builds were excluded because current macOS can't run them. For games that still need Windows translation, Smart Play gained more specific choices. A profile could pin a Wine build and synchronization mode for one game. That means one title's requirement doesn't have to become the setting for your whole library. Bottle Shelf also received a more focused presentation, with a curated group of profiles instead of a wall of options. There was quite a bit of everyday cleanup around that. Bourbon waited for installations, handled cloud-save prompts more clearly, and stopped treating a window that immediately disappeared as a successful launch. Stop All was corrected for native Mac games, and save synchronization reached the shared vault from the different bottles. What I like about this stage is that the user-facing goal stayed simple: choose a game and get to it. Underneath, Bourbon was learning to respect the differences between native games, Windows runtimes and individual title requirements. The examples above describe the recorded July work; they aren't a blanket compatibility promise for every game. --- # Asynchronous I/O and the Bytes a Cancelled Write Keeps > The latest verified candidate passes focused 64-bit read and write profiles on both pipe routes. The tests caught real EOF, completion-block, and cancellation-accounting mistakes. Canonical page: https://pyrosoft.pro/blog/async-io-and-the-bytes-a-cancelled-write-keeps Live development journal; no publication date. Work period: 2026-10-11 to 2026-10-11 Updated: 2026-10-20 A file operation doesn't always finish before the function returns. The application may need to keep running, wait for an event, or cancel the request later. That means the port has to preserve the request's data and ownership until completion, even if the caller closes a handle or changes its memory in the meantime. The latest verified 64-bit candidate now passes focused read and write profiles on both the shared named-FIFO and private-pipe routes. The tests check pending operations, completion events, file waits, cancellation, duplicate and last-handle close behavior, and protection against writing into a freed and reused read buffer. Several real mistakes came out of those tests. One Darwin FIFO route didn't report peer closure through the readiness mechanisms first tried. Another review, using Wine's Windows conformance tests, showed that the native NT call should leave the caller's completion block unchanged while the request is pending. The earlier synthetic expectation had been wrong, so both the implementation and the test contract needed correction. The write-cancellation bug was especially concrete. A large write had already sent a prefix of its data to the peer. Cancelling it produced a completion that claimed zero bytes had transferred. The receiver disagreed: it had the exact bytes. The correction keeps the host-accepted byte count for cancelled writes, and the test compares that count with the full prefix actually received. The host engine passes 20 cases in each of two builds: normal ARM64 and ThreadSanitizer, for 40 case runs. The Windows write profiles pass on both routes, and the existing read profiles were repeated on that exact rebuilt driver. These are functional results for the tested profiles, not performance numbers or a complete Windows asynchronous-I/O claim. The next 32-bit bridge has a different requirement: its completion block is eight bytes, and its addresses belong to the guest window. An owned completion target is proposed so the worker won't retain temporary thunk-stack storage. That proposal is still uncompiled, unreviewed, and unadopted. It doesn't belong in the passing-results column yet. OVERLAPPED I/O, completion ports, guest-thread callbacks, lifetime races, and broader regressions remain open. So do full Windows application and game sessions, Intel Mac framework integration, the graphical launcher workflow, and signed clean-machine distribution. The latest tested code remains a development candidate rather than the adopted product baseline. What I want to keep from this increment is the way the evidence got better. We checked what the receiver actually received, preserved the old failing result, and reran related behavior on the fixed build. That's useful progress we can build on without bringing back a completion percentage the project can't support. --- # A Real Archive Roundtrip and Better File Behavior > The original 7-Zip command-line tool created, tested, and extracted an archive, with all four files compared byte for byte. Canonical page: https://pyrosoft.pro/blog/real-archive-roundtrip-and-file-behavior Live development journal; no publication date. Work period: 2026-10-11 to 2026-10-11 Updated: 2026-10-20 One of the more useful October results was getting an ordinary archive workflow to finish. The original 7zr 26.04 command-line tool created an archive from four files, tested it, and extracted it. The extracted files were compared with the originals, including their complete bytes and CRCs. That is a more useful result than a help screen, although the help screen was an earlier step in understanding the program's behavior. The work had to correct file-type reporting and other file APIs that applications use to decide how to handle their input and output. A wrong answer about a handle can change what a program does even when the next read or write function looks correct in isolation. Directory enumeration, clocks and alignment, allocation, and file metadata also received focused fixes and comparisons. The recorded candidate had 35 targeted cases across those areas, followed by repeated checks on the later archive candidate. These cases help explain why the application advanced; they aren't a count of supported programs. The archive run used the original single-threaded command. I'm keeping that qualification because the default multithreaded path still needs its own acceptance. I'm also keeping this result separate from the older 7-Zip 26.02 installer test. They prove different workflows on different development builds. The native 64-bit ReadFile path was exercised too, including short reads, end-of-file behavior, zero-length requests, invalid handles, file position, and protected or released memory. Those checks tested actual buffer and output effects instead of relying only on an exit status. For a user, opening and extracting an archive should be unremarkable. For the port, it was a helpful application milestone: real code scanned real files, wrote an archive, and got the originals back. The newer builds were still external development candidates awaiting the broader regression and application work needed before adoption. --- # Making the Launcher Own Its Storage and Processes > Managed storage and an app-local process supervisor are part of turning a development engine into an application people can safely launch and stop. Canonical page: https://pyrosoft.pro/blog/making-the-launcher-own-its-work Live development journal; no publication date. Work period: 2026-10-11 to 2026-10-11 Updated: 2026-10-20 A useful launcher needs to do more than start a process. It needs to know where its managed files belong, which process it owns, whether a launch is still active, and what stopping that launch actually means. Those details become especially important when the engine is running translated code and keeping several runtime components together. The October 11 launcher work included managed-storage checks, a native process supervisor, and a shared launcher client. The shared code compiled, the full SwiftUI launcher passed typechecking, and the native control tests exercised the supervisor protocol and the package-contained development pieces. The practical goal is to keep a launch attached to its owner. If the user closes or stops it, Ferrum should have a bounded way to finish that operation and report the result. It should also keep its own state separate from a live application library used elsewhere. Development tests use staged copies where state needs to change. This is also where storage and packaging choices start to affect the user experience. A managed runtime should have a known location and a predictable lifecycle. A successful development run that depends on a temporary directory or a developer's existing installation isn't enough for someone installing the finished application on another Mac. The limits are worth stating clearly. Native control tests and a typechecked GUI don't prove a complete graphical launch-and-play workflow through the newest FEX candidate. They also don't establish a signed, notarized, stapled distribution or a clean-machine installation. The development package and the final product have different acceptance requirements. This work made the launcher side more concrete while the translation work continued. The next step is to qualify those pieces together with real application launches and the intended runtime bundle, then repeat the workflow on the required clean test machines. --- # Getting Wine's Real 32-Bit Startup to Run > The ordinary Wine loader path needed real process, thread, locale, and shutdown state. A command prompt that prints and relaunches became a useful application milestone. Canonical page: https://pyrosoft.pro/blog/getting-wines-real-32-bit-startup-to-run Live development journal; no publication date. Work period: 2026-10-09 to 2026-10-11 Updated: 2026-10-20 The generic 32-bit goal is to run the application's real Windows components, rather than keep adding host-side replacements for whichever import the next title reaches. That meant moving into Wine's actual startup path and supplying the process and thread state it expects to find. The investigation followed the loader through its initialization, heap and process-parameter work, and kernel32 lookup. As it progressed, missing activation-context state, thread setup, locale data, and other startup details became concrete failures to resolve. These are ordinary runtime requirements, even when the visible application is only a command prompt. Shutdown needed its own work. A process can print the expected line and still fail to terminate correctly, leave a peer thread running, or break the next launch. The adopted checkpoint included owner-aware process termination and waiting for the relevant cleanup before final exit. That made clean shutdown part of the result rather than an afterthought. By the October 11 records, Wine's real 32-bit command prompt had produced the expected output, exited cleanly, and launched again. The current adopted checkpoint also had the original regression groups and additional native64 and locale-related groups rechecked. Those are bounded results on a named driver, not a blanket claim about the rest of the Windows catalog. I like this milestone because it's easy to understand and difficult to replace with a superficial test. An ordinary executable is using real runtime code, doing work, and leaving the system in a state where it can do it again. The remaining failures can then be investigated from a more realistic starting point. This still left asynchronous I/O, broader application behavior, Steam, graphics journeys, and a complete packaged release open. It was a meaningful step toward the generic path, and it gave us a better baseline for the archive and file tests that followed. --- # Making Memory Protection and Lifetime Tests More Useful > The memory work checked more than successful allocation: page permissions, decommit, release, reuse, process-image data, and the bytes around each result. Canonical page: https://pyrosoft.pro/blog/memory-protection-and-lifetime-tests Live development journal; no publication date. Work period: 2026-10-06 to 2026-10-09 Updated: 2026-10-20 Memory compatibility is one of the places where the difference between Windows and an Apple Silicon Mac becomes very concrete. Windows code can work with a 4 KB page while the host manages protection at a larger page size. The port needs to track the guest's view carefully instead of assuming that a writable host mapping means every smaller guest page is writable. The work in this period expanded the tests around allocation, protection, decommit, release, and reuse. A successful allocation is the easy case. More interesting questions include whether a protected neighbor keeps its bytes, whether decommitted memory is reported correctly, and whether a reused address is being mistaken for the old allocation. Process-image information needed the same care. The 32-bit structure has its own layout, and a buffer-size check or return-length field is part of the API's behavior. A result that looks plausible in the first field can still be wrong for a real loader reading the rest of the structure. The development packets retained complete output structures, before-and-after bytes, and guarded regions around the target. That makes it possible to catch a write outside the intended field or a change that an abbreviated log would hide. The ordinary memory and lifetime profiles were later repeated on the adopted checkpoint, rather than assuming that an older passing result applied to every newer driver. There were failures in the test and build machinery along the way as well. Those were preserved and repaired separately from product bugs. If a collector rejects a valid result because its own model is wrong, changing the collector doesn't magically become a new runtime success; the saved evidence still needs to be checked against the actual contract. This phase overlaps the later startup work because the loader depends on these same memory behaviors. It made the foundation more useful for real applications, but it wasn't a reason to mark every VM or concurrency path complete. The point was to make the next application failure easier to trust and explain. --- # Recovering the Project and Resuming Real Tests > The resumed work established the source baseline, exercised real NT/file behavior, and added bounded Intel Mac command-line evidence. Canonical page: https://pyrosoft.pro/blog/recovering-the-project-and-resuming-real-tests Live development journal; no publication date. Work period: 2026-10-05 to 2026-10-05 Updated: 2026-10-20 Before continuing the port, I needed a reliable answer to a basic question: which copy of the project are we actually working on? The recovery work compared the source repository, private branch records, local worktrees, documentation, and saved evidence. A newer folder timestamp wasn't enough to identify a newer working build. The resumed Windows work fixed native NT handler registration on the 32-bit entry path and repaired shared file ownership and synchronous I/O behavior. A focused selection of 89 NT, file, and mapping checks passed at the recorded snapshot. That is a useful regression baseline, not 89 supported applications. The Intel Mac investigation also produced bounded command-line evidence. Small Mach-O programs exercised the loader and Darwin syscall path. The shared translator needed a repair to preserve values across the generic syscall boundary, and the alignment path needed checks that distinguished a supported unaligned access from a real permission fault. That distinction is practical. A program shouldn't lose a register value because it asked the operating system for something, and a legitimate alignment repair shouldn't make a read-only write acceptable. The tests checked those behaviors with expected outputs and exits rather than calling a process start a success. There were core safety fixes too, including decoder bounds and stale lookup entries, alongside a review of upstream translation projects. FEX, Wine, box64, QEMU, LLVM, and the graphics projects are useful places to learn. A new upstream commit still needs to address a specific problem in this port and survive a relevant regression test before it becomes part of our stack. The Mac results remained command-line and loader evidence. They didn't establish Objective-C, AppKit, or arbitrary Intel Mac applications. The Windows checks similarly didn't close a complete game session. What this day gave the project was a more trustworthy place to continue, with the source, the tested artifacts, and the open requirements kept separate. --- # Correcting the Ferrum Progress Report > Some earlier 32-bit checks proved placeholder outputs rather than real NT behavior. The recovery work started by separating useful code from unsupported completion claims. Canonical page: https://pyrosoft.pro/blog/correcting-the-progress-report Live development journal; no publication date. Work period: 2026-10-02 to 2026-10-02 Updated: 2026-10-20 I need to correct an important part of the earlier Ferrum progress reporting. The project had used headlines such as 96 percent playable, 99 percent substrate, and a large total of passing checks. The October review found that some of the 32-bit NT milestone checks were accepting fixed placeholder answers instead of exercising the real behavior an application needed. A check can be green and still ask the wrong question. If an API test only verifies a constant that the implementation always returns, it doesn't prove the system query, file operation, or memory behavior behind that API. Those earlier totals therefore can't be used as a supported compatibility percentage or a release-readiness claim. The discarded placeholder approach was not the path to carry forward. The replacement work widened 32-bit arguments and structures so the guest could call real native NT implementations, with a shared handle space where appropriate. At the October 2 checkpoint, that replacement was still work in progress and had not been built and qualified. Written code and written tests were not yet runtime results. This review also made the product scope clearer. Running an installed Windows application through a complete session is one requirement. Doing the same for arbitrary 32-bit software is another. Intel 64-bit Mac applications and a signed, notarized distribution add two more tracks. None of them can be closed by a function count. The parked Mac branch had early Mach-O loader and command-line work, but it didn't establish normal framework-based Mac applications. Some integration candidates also had incomplete builds or test comparisons. Preserving those branches was useful; treating their presence as finished integration would not have been. Going forward, I want progress described in terms someone can inspect: which executable ran, which result was compared, what the negative control showed, and what remains open. That still leaves plenty of real work to be excited about. It gives us a much better way to decide what actually needs to happen next. --- # Portal Reaches a Command Stream, With the Frame Still Ahead > More Vulkan commands and application imports were connected for Portal. The recorded run still did not establish an intro, menu, or visible game frame. Canonical page: https://pyrosoft.pro/blog/portal-reaches-a-command-stream Live development journal; no publication date. Work period: 2026-09-23 to 2026-09-26 Updated: 2026-10-20 Portal continued to be a useful test of the 32-bit path because it combines a large application runtime with a substantial graphics workload. The September work added more of the Vulkan commands its path reached, including buffer updates, image copying, and vertex-buffer binding conversions. Those conversions have to preserve more than a function name. A 32-bit array of pointers or offsets needs the correct shape on the native side, and the length we validate has to be the same length we later copy. One hardening change explicitly joined that length check and copy, rather than giving them separate opportunities to disagree. Application imports also continued to surface. The recorded changes include handling a string-pointer query and binding the Steam installation-path query used by the title. These removed particular obstacles in the test path. They didn't turn a title-specific collection of imports into the finished generic Windows strategy. The important result from the September 26 report is that Portal reached a Vulkan command stream. The equally important limit is that the report claimed no visible Portal frame, no intro, and no menu. I'm keeping that limit right next to the progress because it's the question someone interested in playing the game would actually ask. Steam diagnostics were also exploring what a stalled worker was waiting for and which code created or signaled particular events. A trace can show that a client has advanced while still leaving the serving state needed by a game unresolved. I want the eventual milestone to be easy to understand: a real frame, a menu, and an interactive session through the intended runtime. Until then, a command stream is a useful place to continue debugging. It isn't a substitute for the picture we still need to show. --- # A Launcher and a Freeze That Wasn't the Presenter > The launcher made the project easier to approach. A separate graphics investigation showed why a changing frame counter wasn't enough to prove a changing picture. Canonical page: https://pyrosoft.pro/blog/a-launcher-and-a-freeze-that-wasnt-the-presenter Live development journal; no publication date. Work period: 2026-09-15 to 2026-09-17 Updated: 2026-10-20 The September launcher work gave Ferrum a more approachable starting point: drag a Windows program onto an application, classify it, prepare the environment, and launch it through the FEX path. The next changes added routing for 32-bit Windows executables. That was useful development packaging, although a launcher by itself doesn't make the runtime or the distribution ready to ship. At the same time, an on-screen freeze needed a better explanation. An earlier theory blamed presenter early returns. The later investigation showed that the scrolling test was still presenting while its picture stopped changing. The actual problem was in GDI object allocation: freed handle-table indices and drawing-context slots were not being recycled. The scrolling fixture created and deleted drawing objects repeatedly. Eventually the pools ran out, and later drawing operations stopped producing the expected content. A presentation counter could keep advancing through that failure, which made it a misleading witness if we looked at it alone. Recycling those resources changed the result. The recorded bounded on-screen run lasted 65 seconds, with distinct captured content rather than just a rising presentation count. A withdrawal control restored the old allocation behavior and reproduced the failure. That is much more useful than changing the presenter and assuming a smoother-looking number explains the original problem. There were still limits. The result belonged to that test, build, and display path; human smoothness and broader application sessions were not automatically accepted. The resource model also had documented stale-handle considerations. Those details matter before calling a component finished. Some other 32-bit NT work from this period later failed the project's evidence audit because checks were accepting placeholder answers. I cover that correction in the October 2 chapter. I'm keeping the valid launcher and GDI progress separate from those discarded claims, rather than treating everything from the same dates as equally proven. --- # Working on Presentation and Controller Input > Presentation timing and controller discovery needed tests outside a simple offscreen run. The Mac has its own window and input rules to account for. Canonical page: https://pyrosoft.pro/blog/windows-that-keep-up-and-controllers-that-wake Live development journal; no publication date. Work period: 2026-09-07 to 2026-09-12 Updated: 2026-10-20 Once a program can draw, the next thing you notice is whether its window keeps updating and whether your input reaches it. Those are user-facing behaviors, but they depend on the details of how the translated guest interacts with the Mac's display and input systems. The presentation work in this period explored a display-linked update loop and a layer-backed view. The goal was to keep the on-screen path moving without changing the meaning of the guest's drawing operations. Offscreen comparisons were useful for catching regressions, but an offscreen test can't tell us everything about a window managed by macOS. Controllers had a similar split between detection and actual use. Finding a device in an enumeration doesn't prove that button presses will arrive during a game session. The September 12 change enabled GameController background-event monitoring, which the driver had not been setting. The work also added a detector that looked across multiple input layers so a failure could be attributed more precisely. For a player, the desired behavior is simple: connect a controller, focus the application as needed, and have the controls work. During development, we still need to distinguish the device being present, the input events being delivered, and the application responding. Rumble, different connection types, focus changes, and a physical-controller matrix remain their own checks. The same caution applies to presentation. A counter can say frames are being presented while the contents of the window have stopped changing. The following development chapter uncovered exactly that kind of problem, and corrected an earlier explanation for an apparent freeze. So I wouldn't turn this period into a claim of finished controller support or guaranteed smooth presentation. It added mechanisms and better diagnostics for behaviors that have to be tested on screen and with real devices, as part of an actual application session. --- # DirectX 12, Shader Caches, and the Steam Startup Work > The graphics feature work and Steam startup fixes advanced useful components. Neither a feature probe nor a running Steam process closed the application journey. Canonical page: https://pyrosoft.pro/blog/directx-12-shader-caches-and-steam Live development journal; no publication date. Work period: 2026-09-04 to 2026-09-06 Updated: 2026-10-20 DirectX 12 support is a good place to be careful about the word working. A particular feature can pass a probe while a game still stops before it reaches that feature. During this period, the project had targeted work on the vkd3d-proton and MoltenVK route, including sparse-resource behavior, pipeline caching, and the feature level exposed by selected test configurations. Those results are useful because they identify a specific capability or missing mechanism. They aren't enough to label the whole DirectX 12 path complete. A real title has to reach the graphics code, render the expected image, and continue through an interactive session. Some title investigations stopped earlier in the surrounding Windows runtime. Steam was another large part of the work. Getting the client further into startup involved networking, COM and WMI behavior, process support, and thread-local storage. The records describe concrete blockers being removed and new ones becoming visible. That is progress, even when the final result is still a named failure. One example involved worker-thread TLS data. Code was trying to copy a template from a runtime module address that wasn't safe to use there. The repair validated and preserved the template in driver-owned memory so the worker could use a stable snapshot. That is the kind of fix that can let a program move past one crash without resolving the rest of its startup. The boundary I want to preserve is that SteamAPI_Init was still false in the relevant recorded work. A client process starting, loading more libraries, or passing a network initialization step doesn't prove that an owned Steam title reaches its menu through a working client. The shader-cache results also stay attached to the tests and staged graphics artifacts that produced them. I don't want to turn a specific warm-pipeline improvement into a promise about every game's frame pacing. This phase improved important pieces of the stack, while the complete Steam and DirectX application journeys remained open. --- # Making Memory, Files, and Graphics State Agree > Adjacent allocations, runtime-loaded modules, media resources, and pipeline caching showed why a growing API surface still needs consistent state underneath it. Canonical page: https://pyrosoft.pro/blog/making-runtime-state-consistent Live development journal; no publication date. Work period: 2026-09-02 to 2026-09-03 Updated: 2026-10-20 As more code started running, a lot of the remaining problems came from two parts of the system having different answers to the same question. Is this memory still committed? Does this file handle name the same object? Is a texture still valid when the next component uses it? Those disagreements are hard for an application to work around because the application expects the operating system to keep the answers consistent. One memory issue involved adjacent allocations. A range could be valid across two committed regions while an older validation rule only accepted a range contained inside one region. That rule was useful as an internal simplification, but it rejected ordinary application behavior. The fix had to check complete coverage while still rejecting an actual gap. The 32-bit runtime also continued gaining the file, network, loader, and drawing behavior used by larger application libraries. These are the details behind a familiar operation such as loading a module or drawing a small part of a game's interface. They need to agree about addresses and object lifetime even when the caller changes. Graphics and media work had the same kind of lifetime concerns. A resource that exists on one side of a bridge isn't automatically safe to use on another side. The project investigated texture ownership and presentation rather than assuming that sharing a handle guaranteed a usable image. Pipeline caching was another useful area of progress. The records include work on a Metal binary-archive path inside the graphics dependency, with targeted checks around serving cached pipeline work. A warm-cache benefit in those tests is useful. It doesn't mean shader stutter has disappeared from every game or that cache contents will behave correctly in every application. For me, this stage is a reminder that adding APIs is only part of compatibility. The more important goal is a system whose answers stay consistent while an application allocates, loads, draws, waits, and releases things. Those ordinary transitions are where a lot of the difficult bugs live. --- # Building the 32-Bit Graphics Path > The 32-bit path progressed from API setup to real Vulkan commands and a known-pixel readback. That established important pieces without establishing a visible Portal frame. Canonical page: https://pyrosoft.pro/blog/building-the-32-bit-graphics-path Live development journal; no publication date. Work period: 2026-08-28 to 2026-09-01 Updated: 2026-10-20 The 32-bit Windows target is important because an ARM64 Mac can't simply run those programs as native code. Ferrum needs to translate their Intel instructions and correctly handle their smaller pointers, structures, and calling conventions. A graphics API adds a lot of those structures in one place. During this phase, the i386 path gained more of the Vulkan connection: surfaces, swapchains, presentation, commands, synchronization, and descriptor-related work. One recorded test had a 32-bit guest draw a known pixel and read it back. Another set of changes moved DXVK initialization through its display-adapter requirements and into real device creation. A known-pixel test is useful because it gives us something more precise than a successful function return. We can ask whether the command reached the right resource and produced the requested result. The conversion code also has to carry array lengths, offsets, handles, and pointers correctly across the 32-to-64-bit boundary. There is an important limitation here. These focused graphics tests do not prove that an entire 32-bit game has the Windows environment it needs. The existing host-implemented import path was useful for finding problems, but the product goal is to run arbitrary applications through real Wine components, without adding one more title-specific import every time a different game asks for something. Portal became a demanding case for that work. It exercised a much larger combination of the loader, runtime, graphics, and application APIs than a small drawing fixture. Progress through those layers is worth recording, but I wouldn't describe device creation or command submission as a playable game. What we had by this stage was a stronger graphics foundation with specific readback evidence. The application startup path, a visible game frame, and the menu were still separate milestones. Keeping them separate makes it easier to see what the next fix actually accomplishes. --- # Game Progress and Measuring the Right Thing > Controlled gameplay in King's Pass was useful progress. Understanding the route, memory growth, and test conditions was just as important as reaching another screen. Canonical page: https://pyrosoft.pro/blog/gameplay-performance-and-measuring-the-right-thing Live development journal; no publication date. Work period: 2026-08-23 to 2026-08-27 Updated: 2026-10-20 Seeing a character move through an actual game is one of the more satisfying parts of this project. The Hollow Knight work reached controlled gameplay in King's Pass, with tests that followed the scene and checked what the game was doing. That was a useful application result, even though a complete human play session, audio, saves, and the rest of the game still needed broader acceptance. The route itself needed more care than simply holding a direction. A camera movement can make the player look stationary, and a character near the edge of a frame can be difficult to locate. The development work used the scene and the captured images to distinguish a real stall from a change in how the game was being observed. Performance work also needed better controls. If two guests or a build are competing for the same machine, an apparent slowdown may have very little to do with the code being compared. The project accumulated rules about one guest at a time, recording load, and comparing the same backend and workload. Those conditions are part of the result, not details to leave out of the report. Memory growth was another example. A long game run can show a problem without identifying which component owns it. Reproducing growth outside the game gives us a smaller case to examine, and it avoids blaming the title for behavior introduced by the translation stack or the harness. The same period included CPU and translation research, along with packaging and test-isolation work. I'm interested in optimizations that survive a real comparison, but I don't want a faster number produced by changing the workload, lowering the quality, or losing part of the measurement. So the takeaway from this part of the journal is specific: there was real, bounded gameplay progress, and the measurement process became more demanding. It wasn't a declaration that the game was fully supported or that Ferrum had reached a general performance target. Those are larger claims that need their own evidence. --- # Installers, Saves, Fonts, and the Parts Around the Game > A silent 7-Zip installation and progress on saves, fonts, and audio brought more ordinary Windows behavior into the development stack. Canonical page: https://pyrosoft.pro/blog/installers-saves-fonts-and-audio Live development journal; no publication date. Work period: 2026-08-21 to 2026-08-22 Updated: 2026-10-20 I want Ferrum to run useful software through its normal workflow. That includes the installer, the files it creates, and what happens after you close the program. A game rendering a scene is exciting, but it still needs a sensible place to put a save and the Windows state its installer expects to find. One concrete result in this period was the silent installation of the original 7-Zip 26.02 x64 setup. The recorded test checked the installed files against the archive, along with timestamps, shortcuts, registry changes, and the process exit. The record reports 107 matching installed files. That is a result for that installer and build, rather than evidence that every Windows installer works. Hollow Knight work also reached a save-file milestone. One synchronization investigation found a mutex held across a wait, blocking the other work needed to make progress. Fixes like that are easy to describe as a speed improvement, but they also affect correctness: whether a program can finish the work it already asked to do. Fonts and audio were getting more attention too. The GDI font surface gained real font data and glyph work through CoreText. The MIDI path was connected to native Mac facilities. These changes filled in pieces that an application may use before its main content ever appears. They also exposed remaining problems, including audio initialization and lifetime behavior that still needed their own fixes. The opening-video work continued through this period as well, with later records showing the sequence advancing. Taken together, these were more realistic application behaviors than the first small executables could exercise. They also made it clear how many layers an ordinary launch depends on. I'm keeping the historical installation result separate from the newer command-line archive tests covered later in this series. They use different 7-Zip versions and different builds. Both are useful, but combining them into a single claim that the entire application is finished would hide the work still needed. --- # Following a Game Through Its Opening Video > A game's opening sequence connected video formats, input timing, and its own state machine. Fixing the picture was only part of getting past it. Canonical page: https://pyrosoft.pro/blog/following-a-game-through-its-opening-video Live development journal; no publication date. Work period: 2026-08-19 to 2026-08-20 Updated: 2026-10-20 A game's opening video seems like it should be a simple milestone: play the video, let it finish, and get to the next screen. The actual work turned out to involve the media samples, the game's own logic, and the timing of the input used to move through its setup. During this phase, the Hollow Knight investigation followed the opening sequence into the game's code rather than assuming that every stall was a rendering problem. The video work included details such as the advertised image format, the stride of a frame, and the size of the sample being handed to the next component. If those disagree, the application can have data without getting the picture it expects. Input had a similar requirement. Sending a key isn't the same as proving that the game received the right press and release at the right point in its frame loop. A setup prompt can depend on state that isn't obvious from a screenshot. The tests needed to distinguish a key that was delivered, a prompt that accepted it, and the game actually advancing. That changed how I wanted to approach these problems. Rather than repeatedly send input and hope the next screen appeared, the work followed the condition the game was waiting for. When the media path and the state transition were both understood, there was a much more useful explanation for what still blocked progress. The August 19–20 work should be read as that investigation and repair period. Later entries record the opening sequence advancing; I wouldn't pull that later result backward and describe every earlier run as successful. Some observations and initial explanations had to be corrected along the way. For the eventual user, the desired result is ordinary: the opening finishes and the game responds. For the port, this was a good reminder that a visible image, a running process, and a completed application transition are three different things to verify. --- # Building More of the Windows Runtime > Older DirectX, thread state, windows, and system objects all became part of the same job: answering the requests real Windows components make. Canonical page: https://pyrosoft.pro/blog/windows-runtime-threads-and-older-directx Live development journal; no publication date. Work period: 2026-08-12 to 2026-08-18 Updated: 2026-10-20 A Windows compatibility layer starts to get interesting when the components begin depending on one another. A DLL needs thread-local state. A graphics library wants to enumerate a display. A registry operation needs the same view of an object that another API already created. Each individual call may look simple, but the application expects them to describe one consistent system. One useful example from this period was the older Direct3D path. Direct3D 9 doesn't discover a display in exactly the same way as the newer DXGI-based path. The work had to answer the display-enumeration requests that this code actually made before it could create the expected device. The milestone records include targeted device and pixel results; that isn't a promise that every older DirectX game is supported. Thread behavior was becoming just as important. A value that belongs to one thread can't be treated as a process-wide variable. Modules loaded after a thread starts still need the right initialization. A wait has to release the resources another thread needs in order to wake it. These are the kinds of problems that can make a program appear to stall somewhere unrelated to the original mistake. There was also more work on the 32-bit foundation, including the process information and loader state that i386 programs expect. That target brings an extra address-space problem on the Mac: a 32-bit guest pointer needs to be translated into the correct host address. Passing the number through unchanged isn't enough. For someone using the finished product, none of this should require a special setup step. You should launch the application and have its ordinary Windows components behave consistently. During development, though, those assumptions have to be made explicit and tested one at a time. The progress here was a broader set of real runtime behaviors, with plenty of application-level work still open. I was moving past the question of whether Intel instructions could execute and into the harder question of whether the surrounding environment made sense to the program using it. --- # From Return Values to Pixels and Sound > A window, a sound, and a changing image answer different questions. This phase started connecting translated Windows code to results a person can actually see and hear. Canonical page: https://pyrosoft.pro/blog/from-return-values-to-pixels-and-sound Live development journal; no publication date. Work period: 2026-08-08 to 2026-08-11 Updated: 2026-10-20 Once an executable can run, the next question is pretty straightforward: can it do anything useful outside the terminal? For a game or a desktop application, that means windows, drawing, input, and sound. Those are separate connections, and getting one working doesn't automatically bring the others along. The August work started joining those pieces. A translated guest produced sound, the Mac surface gained a way to accept an image from the graphics path, and the rendering checks moved toward verifying the pixels the guest had actually drawn. That last part matters more than a successful device-creation call. An application can create a graphics device and still leave you looking at a blank window. For example, if a test draws a known color, we can read the result back and compare it with what the program requested. Then we can ask a different question: did that image reach the window? The renderer and the presentation layer can each be doing something reasonable while the connection between them is wrong. This phase also exposed instruction and API gaps that tiny command-line programs hadn't reached. More realistic graphics code exercised vector instructions, DLL initialization, memory, and synchronization in combinations the earlier tests never used. That is one reason I don't treat the number of implemented functions as a compatibility score. What matters is whether the application can use them together. The sound and pixel milestones were encouraging because they made the work less abstract. There was something to observe. They were still targeted development results, though. They didn't establish sustained game audio, a long interactive session, or support for every DirectX feature. The practical lesson was to keep asking for the result at the far end of a feature. If we're working on drawing, let's inspect what was drawn. If we're working on presentation, let's make sure the window changes. A return value is useful evidence, but the thing the viewer sees needs its own check. --- # Bringing FEX to macOS: The First Windows Program > Getting the translation engine to build was the first step. Getting a real Windows executable to run showed where Ferrum's Mac-side work actually begins. Canonical page: https://pyrosoft.pro/blog/bringing-fex-to-macos Live development journal; no publication date. Work period: 2026-08-05 to 2026-08-07 Updated: 2026-10-20 I started Ferrum because I want another way to run the Intel software people still use on an Apple Silicon Mac. Apple's published Rosetta transition makes that work worth taking seriously. A compatibility layer needs time to mature, and I'd rather work through the difficult parts while people still have their existing options. The project builds on FEX, the open-source x86 and x86-64 translation engine. The initial job was to get its core building on Darwin, the operating-system foundation underneath macOS. That meant dealing with platform assumptions around synchronization, signals, memory, and executable code. A Linux-oriented frontend can't simply be relabeled as a Mac application and expected to work. The first visible result was small: translate some Intel instructions and get the expected answer back. From there, the work moved to loading a Windows PE executable, handling its relocations and imports, and letting it call a few real host-implemented Windows functions. The August 7 record includes a Windows executable printing its message through WriteFile and reaching its expected ExitProcess result in the ARM64 driver. What I like about that test is that it crosses an actual application boundary. The guest program has code, data, an entry point, and imported functions. It isn't just a native Mac program printing a Windows-themed message. At the same time, three working imports don't make a complete Windows environment. DLL loading, operating-system behavior, graphics, and application startup were still ahead. Some early failures were useful lessons in that distinction. Calls and returns needed the translator's own per-thread prediction stack. JIT memory needed the correct write-versus-execute handling, including nested compilation. The entry stack had to match the convention expected by Windows code. Each problem only became visible when the test started doing more than the previous one. That became the approach for the rest of the port: get one real behavior working, preserve a test that can tell when it breaks, and then move to the next boundary. The first executable was a starting point. The interesting part was finding out what it would take to run something larger. Project references: [FEX](); [Apple’s Rosetta support update]() (September 1, 2026; consulted for this entry). --- # Click-through controls and the cross-platform download set > Recovery controls, Linux capture evidence and a verified upload record. Canonical page: https://pyrosoft.pro/blog/click-through-controls-and-the-cross-platform-download-set Live development journal; no publication date. Work period: 2026-09-08 to 2026-09-09 Updated: 2026-10-20 A floating PiP can be useful and still get in the way of the thing underneath it. Click-through adds a simple choice: keep the picture visible while letting mouse clicks reach the desktop window below. It doesn't send those clicks back to the captured source. The recovery path matters just as much as enabling it. InfinitePIP hides the PiP controls while click-through is active, then lets you choose Restore clicks or Show from the main app. New PiPs start with normal mouse interaction, so you don't have to remember how a previous window was configured. The September Linux record includes real screen, external-window and region capture from the ARM64 Debian package in an isolated X11 environment. Nonblank pixel readback supported those checks. Native x64 runtime, physical desktop behavior and real Wayland portal flows remained open, and the click-through state checks didn't prove operating-system mouse delivery on every platform. On September 9, the upload record confirmed ten fresh candidates on itch: universal macOS DMG and ZIP, Windows x64 and ARM64 installers and portable apps, and Linux x64 and ARM64 AppImage and Debian packages. The Mac artifacts passed notarization, signature and Gatekeeper checks. Windows downloads were labeled unsigned and Linux downloads preview. That gives us a useful delivery milestone without flattening the differences between platforms. The files were uploaded and checked, while native click delivery, compositor behavior and broader runtime coverage still needed their own tests. For someone using InfinitePIP, the goal remains a small one: keep the view you need, get it out of your way when appropriate, and have an obvious way to bring its controls back. --- # A better workspace for all your PiPs > Dashboard navigation, capture controls and a more deliberate packaging process. Canonical page: https://pyrosoft.pro/blog/a-better-workspace-for-all-your-pips Live development journal; no publication date. Work period: 2026-08-30 to 2026-08-30 Updated: 2026-10-20 Once you're using several floating views, the main window needs to do more than offer a source picker. The August InfinitePIP candidate brought in a dashboard, source workbench, Active PiPs view, settings and diagnostics, using the same general visual direction as Bourbon and the macOS driver suite. The practical flow is still simple. Choose a display or application window, or define a custom screen region, then adjust the resulting PiP independently. Zoom, pan, opacity and always-on-top controls help the view fit around the work you're already doing. Permission and source state became more explicit too. On macOS, Screen Recording access belongs to the actual app identity. A development Electron process having permission doesn't tell us whether the packaged InfinitePIP app can capture. Protected media can also intentionally refuse capture, which a new dashboard can't override. Underneath the interface, the candidate moved to Electron 44 and added more deliberate release checks. Local developer packages were kept separate from signed release commands. Packaged legal notices, Electron fuse settings and fresh artifact checksums became things we could inspect instead of assumptions attached to a file in the output folder. The dated changelog calls 26.8.30 a public-release candidate. At this point in the chronology, signing and packaged runtime checks were still gates. The later September upload record supplies evidence that goes beyond that earlier candidate description. What I like here is the combination of a more usable main window and a clearer path to delivery. Both matter: the app needs to make multiple PiPs manageable, and the download needs a record of what was actually built and checked. --- # Giving InfinitePIP a clearer front door > A project site that explains the floating-window workflow. Canonical page: https://pyrosoft.pro/blog/giving-infinitepip-a-clearer-front-door Live development journal; no publication date. Work period: 2026-05-14 to 2026-05-14 Updated: 2026-10-20 By May, InfinitePIP needed a clearer way to explain itself outside the application. The May 14 commit added a project site, styling, a favicon and a desktop screenshot. The commit message was short, so I checked the changed files rather than treating the message as a complete description of the work. A picture-in-picture tool is easier to understand when you can connect it to an actual desktop task. Keep a reference visible, watch an application while you work elsewhere, or frame a small part of a larger display. The site work gave that explanation somewhere to live. It also helps separate the product idea from the implementation history. Someone looking for the app shouldn't need to work out why there is a deprecated Python folder next to the Electron application before understanding what the floating views do. This particular commit changed the website assets. It didn't establish a new capture engine or prove a freshly signed application release. That's a useful distinction in the chronology because the Git default branch stops here, while the local working tree contains substantial later application work. If we only read the latest commit date, we would miss the August interface and security changes and the September packaging and upload records. The project site is one milestone, and those later records are another. For this stage, the progress was straightforward: InfinitePIP had a more complete presentation around the workflow already taking shape in the app. The next work would concentrate on making that workflow easier to navigate, package and verify across the supported desktop targets. --- # Rebuilding InfinitePIP around independent floating windows > Source selection, crop preview and controls for each PiP. Canonical page: https://pyrosoft.pro/blog/rebuilding-infinitepip-around-independent-floating-windows Live development journal; no publication date. Work period: 2025-12-24 to 2025-12-26 Updated: 2026-10-20 The next day, InfinitePIP moved to an Electron implementation. The first rewrite included source selection and a floating PiP with opacity, zoom, pan and always-on-top controls. That gave the project a more direct foundation for managing desktop capture and several independent windows. A useful example is keeping a small application panel visible while the rest of that application stays behind your main work. You can adjust the view instead of resizing the original app until its interface becomes awkward. Zoom and pan let you decide which part deserves the space on your screen. The December 24 follow-up added a live region-crop preview and aspect-ratio locking. Previewing the crop is a big usability improvement: we can see what we're selecting before creating another floating window. The proportions can stay consistent while the view changes size. Per-PiP management followed the same evening. Once there is more than one floating view, the main app needs to help you find, adjust and close the correct one. A list of individual PiPs makes much more sense than assuming the last-created window is always the one you want. The project was then reorganized and its documentation updated, with additional README cleanup on December 26. Those commits describe the rewrite and interface work; they aren't a platform-by-platform release acceptance record. This is the point in the history where the current app's shape becomes recognizable: choose a source, frame the useful area, and manage the floating result separately. The later dashboard and packaging work build on that workflow rather than changing what InfinitePIP is for. --- # InfinitePIP begins with a simple desktop idea > Keep the useful part of another window nearby. Canonical page: https://pyrosoft.pro/blog/infinitepip-begins-with-a-simple-desktop-idea Live development journal; no publication date. Work period: 2025-12-23 to 2025-12-23 Updated: 2026-10-20 Sometimes I don't need a whole second application in front of me. I just want to keep an eye on one useful part of it while I'm working somewhere else. That's the idea behind InfinitePIP: take a view from the desktop and keep it nearby in a floating window. The retained history starts on December 23, 2025, with the modern Python interface. The work that day quickly moved into a package structure with platform utilities, followed by responsive layout and card interactions. There was also a pass to bring the interface closer to the intended design. That early organization mattered because capture, platform behavior and the dashboard aren't really the same job. Keeping them separate gives us somewhere to make a Windows-specific correction without turning every interface change into a platform rewrite. The useful goal was already easy to explain. If you're watching a reference, following a process or keeping a small status area visible, you shouldn't have to rearrange your whole desktop to do it. A floating view can give you the information you need while leaving the main application where it is. This was the beginning of the retained application history, not evidence that every desktop and capture source was already working. The Python implementation later became the deprecated original, which is why someone browsing the project today will find more than one generation of code. I like keeping that progression visible. The first version establishes the workflow; the later work tells us which implementation can support it more cleanly. InfinitePIP's core idea stayed consistent even as the application underneath it changed quite quickly. --- # Making the audio driver's foundations explicit > WDK and Sysvad attribution, with the remaining validation work kept visible. Canonical page: https://pyrosoft.pro/blog/making-the-audio-driver-s-foundations-explicit Live development journal; no publication date. Work period: 2026-03-03 to 2026-03-03 Updated: 2026-10-20 Open-source driver work starts with other people's foundations, and those foundations should be easy to find. The March 3 update added explicit WDK and Windows Driver Samples attribution, including the Sysvad audio sample lineage and the third-party license notice. That helps anyone trying to understand or extend the project. You can separate the original application work from the sample-derived code, find the relevant Microsoft material and see which notices need to travel with a distributed copy. It also gives us a more accurate way to describe what this product is. The Virtual Audio Driver is a Windows driver project exposing virtual audio endpoints. It is separate from the macOS suite's Core Audio HAL cables, even though both can help with audio workflows. The implementation, installation and validation requirements differ. The latest local and GitLab default heads matched at this attribution commit during the review. There wasn't a newer source revision in that comparison that would restore the removed effects experiment or establish a fresh production-signed release. The next useful work is practical: reconcile the README with the actual format declarations, test which streams applications can open, measure delivery through the intended workflow and verify installation and removal on the target Windows systems. The existing beta warning stays relevant until the exact package has its own stronger evidence. This is a smaller update than adding another device mode, but it makes the project easier to build on responsibly. If someone learns from this driver or incorporates parts of it into another tool, the origin and obligations of the sample code should be right there with the implementation. --- # Rolling back the effects experiment > A more focused topology and a reminder to read the actual format tables. Canonical page: https://pyrosoft.pro/blog/rolling-back-the-effects-experiment Live development journal; no publication date. Work period: 2026-01-15 to 2026-01-15 Updated: 2026-10-20 The January 15 audio history is a good example of why a development journal needs the rollback as well as the new-feature commit. Equalizer, noise-suppression and automatic-gain-control work was added, then explicitly reverted later that day. Those features shouldn't appear in a current capabilities list just because their introduction is still in Git. The next commit simplified the supported formats and topology. It removed the extra surround expansion and unused bass, treble, reverb, chorus and echo-cancellation nodes and related handlers. The direction was a smaller surface that would be easier to understand and validate. There is a wrinkle worth explaining in plain terms. The simplification commit's description is narrower than all of the retained table entries. The current microphone table still contains a floating-point example, and the speaker table retains additional entries beyond its headline range comments. A clean-sounding commit summary isn't an authoritative compatibility matrix. For this entry, I'm describing the removal and the remaining need to verify format negotiation rather than publishing a new exact list of supported combinations. That list needs to come from the actual advertised ranges, table entries and successful stream-open tests together. The same care applies to the README, which still includes broader historical descriptions. Updating the documentation against the implementation is useful next work, alongside native Windows tests for both endpoints and the relevant signing path. What I like about recording this stage honestly is that it makes the next decision easier. We know what was tried, what was reverted and where the remaining ambiguity is. We can test a focused driver instead of carrying forward a feature list assembled from several different generations of code. --- # Exploring more formats, channels and audio controls > A wider Windows audio experiment before the later simplification. Canonical page: https://pyrosoft.pro/blog/exploring-more-formats-channels-and-audio-controls Live development journal; no publication date. Work period: 2025-11-14 to 2025-11-14 Updated: 2026-10-20 Once the speaker and microphone endpoints existed, the next experiment was expanding what they advertised to Windows. The November 14 work added much broader format tables, then multichannel and signal-processing mode changes, followed by topology and property-handler work for audio controls. The format commit included PCM and IEEE floating-point entries across more sample rates. The speaker work also explored surround configurations, while both endpoint paths gained additional signal-processing mode declarations. In practical terms, the goal was to give applications more ways to negotiate an audio stream. The following change added tone-control, effects and acoustic-echo-cancellation related nodes and handlers using WDK patterns. Those additions are visible in the source history. They should be described as implementation work, because a topology node or exposed property alone doesn't prove the expected processing is audible, effective or stable in a real call. That's an easy distinction to lose when reading a feature list. Seeing an option in Windows, successfully opening a stream and measuring what comes out of that stream are separate checks. A wider table also creates more combinations to test for channel layout, sample conversion, long-running delivery and cleanup. This was a short, concentrated stage of development, and it wasn't the final shape of the driver. The January work later removed much of the extra topology and broad format expansion. I'm including this chapter because it explains that decision and prevents the later source from looking like an accidental loss of undocumented features. For anyone following the project, this is what was being explored at that point. The next milestone is about bringing the supported surface back to something more focused, with actual stream behavior still the standard for compatibility claims. --- # Virtual audio endpoints for a computer without speakers > The early Windows audio driver, format work and a quieter microphone path. Canonical page: https://pyrosoft.pro/blog/virtual-audio-endpoints-for-a-computer-without-speakers Live development journal; no publication date. Work period: 2025-01-02 to 2025-07-14 Updated: 2026-10-20 A headless computer can need audio devices even when there's no speaker or microphone plugged into it. Remote access, capture and testing tools often expect Windows to expose an endpoint they can select. The Virtual Audio Driver starts with that practical problem. The January 2, 2025 history introduced the driver and expanded the available audio formats, followed by ARM64 support work. The project derives from Microsoft's WDK audio samples, providing virtual speaker and microphone endpoints that applications can discover through the normal Windows audio system. Those endpoints are useful building blocks, but selecting a virtual microphone doesn't automatically connect every application or audio source to it. The complete workflow still needs the right driver behavior, routing and consumer configuration. That's especially relevant as the separate control panel grows its own audio-routing interface later in the history. A May change turned off the microphone tone generator and moved that path toward silence. That's a sensible correction for a virtual device someone may select in a call or test session: an unexpected generated tone isn't the default behavior we want them to discover. Build files and signing-workflow experiments continued through the first half of the year. The history includes changes and removals in that area, so the existence of those workflows isn't enough to describe every package as production signed. The current project documentation still carries a beta and test-signing warning. This first stage established the Windows device foundation and started making it more appropriate for real use. The next chapters show the format and effects experiments, including the parts later removed. That matters more than simply collecting every feature ever mentioned in a commit. --- # Safer monitor lifetimes and clearer driver replies > The latest retained driver changes focus on ownership and the control channel. Canonical page: https://pyrosoft.pro/blog/safer-monitor-lifetimes-and-clearer-driver-replies Live development journal; no publication date. Work period: 2026-08-31 to 2026-08-31 Updated: 2026-10-20 The latest retained Virtual Display Driver work is less visible than adding a new display mode, but it affects how reliably the rest of the toolchain can control the driver. The August 31 changes addressed monitor lifetime, mode state and named-pipe command handling. The monitor changes added explicit context cleanup and protected references while work was using an IddCx monitor object. That helps keep a monitor's resources connected to its actual lifetime instead of assuming the object will remain valid through a changing display configuration. On the control side, shared state and pipe handles received more careful synchronization. Replies were written through explicit helpers, and queries could return useful error information. A normal WDF device restart replaced the earlier unsafe reload behavior. Why does that matter in the app? If the driver rejects a request, the control panel needs to know. If a connection closes before its response is delivered, a successful write doesn't necessarily tell us whether the requested change succeeded. The matching control-panel work started handling those replies more deliberately too. The local driver head and GitLab's default head matched for this review. That establishes which source revision we're discussing. I haven't turned that into a claim that a newly signed Windows package was shipped or that a new hardware test matrix passed during this writing task. The useful next development step is to validate the paired driver and control panel on Windows: monitor creation and removal, mode changes, restart, command errors and repeated connections. The source changes give us a more defensible foundation for that work, with clearer ownership and better feedback when something goes wrong. --- # More precise GPU selection and multi-monitor corrections > PCI-based adapter resolution, HDR bit depth and swapchain threading. Canonical page: https://pyrosoft.pro/blog/more-precise-gpu-selection-and-multi-monitor-corrections Live development journal; no publication date. Work period: 2026-01-08 to 2026-06-22 Updated: 2026-10-20 When a system has several GPUs, choosing by a display name can leave too much ambiguity. The January 2026 work added a way to resolve an adapter LUID from its PCI bus number, with the supporting build and device-property changes needed for that path. The useful result is more specific adapter selection. Instead of assuming a friendly name uniquely identifies the device, the driver can connect the choice to hardware information. That builds on the earlier work to expose device identity in logs and configuration. The spring brought corrections to HDR bit depth and multi-monitor swapchain threading. The latter came through a community contribution and was merged in May. A multi-monitor driver has to keep each monitor's work associated with the right resources and threads; a fix there addresses a different problem from simply offering more resolutions. Build maintenance continued too, including moving the Windows Driver Frameworks headers into a Git submodule and updating CI configuration. That makes the source layout and required dependencies more explicit for contributors trying to reproduce a build. The history also includes an initial shader experiment that was reverted in January. I'm leaving it out of the active feature list. An experiment is useful evidence of what was tried, but its introduction commit alone doesn't establish what remains in the driver. Taken together, this stage is about being more exact: identify the intended GPU, describe the HDR format correctly, and keep separate virtual monitors from interfering with one another's rendering work. These are recorded source changes; a release artifact and the Windows configurations it passes still need their own evidence. --- # Building the tools around the display driver > Configuration, community automation and better device identification. Canonical page: https://pyrosoft.pro/blog/building-the-tools-around-the-display-driver Live development journal; no publication date. Work period: 2025-01-01 to 2025-11-30 Updated: 2026-10-20 A driver can be technically capable and still take too much effort to use. Much of the 2025 Virtual Display Driver work was about the tools and configuration around it: scripts, clearer settings, integration points and better ways to identify the right device. The February changes expanded configurable cursor support and color-format choices, alongside XML restructuring. Community scripts also received improvements around selecting a display, validating parameters and checking dependencies. Those are useful details when you're automating a streaming session and need the same sequence to work next time. Silent-install tooling entered the history in the spring. Later work added EDID integration, version metadata for the app and source for a helper that queries IddCx versions. Each gives another part of the toolchain a more explicit way to understand the driver instead of relying on a name or a guess. DeviceID and PCI-slot information helped friendly naming in September. On a machine with several adapters or virtual devices, a label that connects back to the actual hardware is much more useful than another generic entry. There were also build, signing-workflow and documentation changes across the year. I don't want to translate every pipeline edit into a claim that a fresh signed release was delivered. The meaningful product story is that the project was becoming easier to integrate, configure and diagnose. This work also depended on community contributions, including the scripts and integration changes visible in the history. Keeping those contributions credited matters. The virtual monitor is one part of the setup; the surrounding tools are what let people fit it into remote access, capture and automation without rebuilding the workflow from scratch every time. --- # Fine-tuning the virtual display > Hardware cursors, custom EDID and fractional refresh rates. Canonical page: https://pyrosoft.pro/blog/fine-tuning-the-virtual-display Live development journal; no publication date. Work period: 2024-09-01 to 2024-12-31 Updated: 2026-10-20 Once a virtual monitor is part of a streaming or remote-work setup, the details start to matter. A cursor needs to behave properly, a refresh rate may need to match an existing display, and the advertised monitor information can affect what the next application decides to do. The late 2024 changes added hardware-cursor work and a separate cursor toggle. They also introduced HDR+ controls and custom EDID support. EDID is the description a display gives the system about itself: identity, timings and other capabilities. Being able to supply that information gives advanced setups more control over what Windows sees. Fractional refresh rates arrived in the October work too. That's useful when the target is something like 59.94 rather than a rounded 60. The configuration can describe the intended timing more precisely, although the complete capture and client path still needs to agree with it. December's adapter logging added LUID information. That gives us a more specific identity to work with when multiple GPUs are present, which becomes useful again in the later PCI-based selection work. I like these changes because they're connected to practical questions. Which GPU did we select? What timing are we advertising? Is the cursor part of the path behaving as expected? The driver becomes easier to understand when those choices are visible and configurable. This is a source-history chapter. It describes when those controls were added, rather than asserting a new release or a successful end-to-end HDR test for every combination. The next useful step was making the settings and the surrounding tools easier to manage without asking everyone to edit the driver configuration by hand. --- # HDR and choosing the GPU behind the virtual screen > Expanding the display path while improving configuration. Canonical page: https://pyrosoft.pro/blog/hdr-and-choosing-the-gpu-behind-the-virtual-screen Live development journal; no publication date. Work period: 2023-12-02 to 2024-08-31 Updated: 2026-10-20 Creating another desktop is the first step. The next question is what kind of display it can be and which GPU should render it. The December 2023 through summer 2024 work pushed the Virtual Display Driver further in both directions. HDR support entered the history on December 2. That opened up a more useful virtual-display path for supported Windows HDR workflows, with the operating system, capture software and receiving display still determining the complete result. A virtual monitor advertising HDR doesn't make every part of a streaming chain HDR-capable by itself. Render-adapter selection followed in the spring. On a machine with more than one GPU, letting the user choose the adapter is much more practical than hoping the default matches the intended setup. That can matter when the GPU doing the work and the one connected to a physical panel aren't the same device. The summer changes included work toward one driver for Windows 10 and Windows 11, plus GPU fallback and XML configuration. By August, the history also records the XML and EDID work moving together. Those pieces help describe what the virtual monitor should expose and how the driver should recover when a preferred adapter isn't available. There were installer and control-panel prototypes along the way. They show the project expanding beyond the driver itself, though their early presence shouldn't be confused with the later standalone control panel's maturity. This stage made the virtual monitor more adaptable. We could start thinking about the intended display characteristics and the rendering hardware as choices in the setup, while still checking each combination against the Windows version and the software that would capture it. --- # A monitor without another panel on the desk > The early Virtual Display Driver work on modes, refresh rates and setup. Canonical page: https://pyrosoft.pro/blog/a-monitor-without-another-panel-on-the-desk Live development journal; no publication date. Work period: 2023-10-14 to 2023-10-21 Updated: 2026-10-20 A virtual display gives Windows another monitor without plugging in another panel. That's useful for remote access, streaming and headless computers, where an application may need a real desktop surface even though nobody is sitting in front of a physical screen. The project builds on the Indirect Display Driver sample lineage. The retained Git history goes back further than my product work, so those inherited commits belong to that foundation and its contributors. The October 2023 changes are where this chapter of the Virtual Display Driver story starts. Refresh rates were an early focus. The October 14 history shows additional modes being introduced, narrowed and adjusted again, followed by more refresh-rate work over the next week. There were also widescreen modes and a 2732 by 2048 option, giving the virtual screen dimensions that could better match different client devices. That back-and-forth is useful context. A refresh rate appearing in one commit doesn't mean it remained the final supported setting. The early work was finding a configuration Windows and the driver could handle consistently, rather than treating the longest mode list as the best result. Installer and alternate-driver experiments were also present, with some explicitly marked incomplete. I'm keeping those descriptions attached to their stage of development. Adding source for an installer isn't the same milestone as verifying a finished installation on someone's machine. The basic use case was already strong: create a desktop Windows can render, then let your capture or remote-access application use it. The later HDR, configuration and control-panel work grew out of making that virtual monitor more useful in real setups. --- # A rebuilt panel with displays, audio and an EDID lab > The React and TypeScript rewrite, followed by more careful driver replies. Canonical page: https://pyrosoft.pro/blog/a-rebuilt-panel-with-displays-audio-and-an-edid-lab Live development journal; no publication date. Work period: 2026-06-12 to 2026-08-31 Updated: 2026-10-20 The June rewrite brought the Driver Control Panel into an Electron, Vite, React and TypeScript structure. It combined a driver dashboard with display configuration, audio controls, diagnostics and an EDID lab, giving the project a much clearer application shape. The implementation includes a desktop arrangement map, typed XML settings, backups and a preview of configuration changes. The EDID tools decode monitor information and export the files used by the driver's profile path. Those are useful ways to understand a setup before changing it. Audio also has a broader place in the panel: endpoint volume and mute, default-device selection and a routing matrix. The routing engine is part of the running app, so those routes have a different lifecycle from the installed virtual audio driver. Keeping that distinction visible helps explain why a route depends on the panel remaining open. The August 31 follow-up addressed the connection to the display driver. Explicit ERROR replies now became failed operations, display count was bounded to the driver's limit, and the client recognized the normal restart path available with the corrected driver. It also retained compatibility with older PING behavior. There's a source difference to preserve here: GitLab's default branch matched the June rewrite, while the local checkout and GitLab's named-pipe fix branch included the later August change. Those references identify the implementation being discussed; a newly validated Windows release would need its own package and test evidence. The useful next step is testing the matching driver and panel together: installation trust, configuration recovery, display changes and real audio delivery. The rewrite gives those workflows a more coherent home, and the reply handling makes failures easier to report honestly. --- # Moving the panel behind a clearer application boundary > Context isolation, a preload bridge and native window controls. Canonical page: https://pyrosoft.pro/blog/moving-the-panel-behind-a-clearer-application-boundary Live development journal; no publication date. Work period: 2026-01-12 to 2026-01-13 Updated: 2026-10-20 A driver control panel has access to more than the average settings window. It reads configuration files, asks Windows about devices and can start privileged operations. That makes the boundary between the interface and the application process part of the design. The January 12 work moved the Electron panel toward context isolation and a secure preload bridge. It added utilities for validation, sanitization, command execution and safer DOM handling, then followed with initialization corrections. Custom controls for the frameless window arrived early the next day. The practical idea is to give the interface specific operations it can request instead of direct access to everything Node.js can do. That makes it easier to see what a button is allowed to change and where its inputs should be checked. This was a migration, not proof that every older call site had already been converted. The historical migration material identified remaining work, and the later June rewrite replaced much of that structure. I'm treating the January commits as an architectural step rather than a complete security certification. The window controls matter too, but for a different reason. If the panel uses its own frame, minimize, maximize and close still need to behave predictably. A polished appearance only helps if the ordinary desktop actions remain obvious. What I like about this stage is that it recognized the panel as a real application with a privileged job to do. The next version could build a more maintainable interface on that separation, while keeping device operations and configuration handling in explicit services that could be reviewed more directly. --- # Reconnecting the interface and fixing driver detection > A busy revision with installation controls temporarily pulled back. Canonical page: https://pyrosoft.pro/blog/reconnecting-the-interface-and-fixing-driver-detection Live development journal; no publication date. Work period: 2025-08-17 to 2025-08-17 Updated: 2026-10-20 The August 17 control-panel history shows a lot happening in one day: source reorganization, interface changes, settings connected to XML, elevation requests and several rounds of driver detection fixes. It also shows why the final feature list can't be made by adding up every commit message. Reinstall was removed after a bug, and Install and Uninstall were temporarily removed later that morning. Other commits improved version checks and eventually recorded a buildable application and another driver-status correction. That is a development sequence with changing behavior, rather than one uninterrupted list of additions. The useful interface work was making settings actually reach the configuration and making administrative operations request the appropriate elevation. A control that looks right but edits the wrong value isn't useful, and a lifecycle action that silently lacks permission is confusing to troubleshoot. Status detection matters for the same reason. If the app says the driver is missing when it is present, the next button it offers may send the user down the wrong recovery path. The repeated detection changes show attention to that practical issue. I want this chapter to preserve the temporary removals. Someone reading about the earlier installer work should be able to understand why it might not have been available in the next interface generation. Later rewrites revisited those operations; they shouldn't be projected backward onto this snapshot. This was a consolidation stage: connect the controls, correct the status and get the reorganized app building. The next major work would address the Electron security boundary and then rebuild the panel around a more modular interface. --- # Connecting the panel to everyday driver tasks > Real progress, tray controls, XML editing and audio-driver management. Canonical page: https://pyrosoft.pro/blog/connecting-the-panel-to-everyday-driver-tasks Live development journal; no publication date. Work period: 2025-05-01 to 2025-07-24 Updated: 2026-10-20 By May, the control-panel work was moving from the shell into the actions people would use regularly. The changes fixed behavior when no driver was installed, improved restart functions and added more realistic task progress and console input. That's useful because waiting on a driver operation can otherwise look like the app has stopped responding. A progress indicator should reflect the task, and the console should help explain what happened when it didn't finish as expected. Tray integration arrived alongside more consistent menu behavior. There were also corrections distinguishing hardware and software reload paths, plus a fuller XML editor and settings preload work. The goal was to make common changes available through the panel while keeping the underlying configuration understandable. Community scripts became easier to access and synchronize. That brought other people's workflow improvements closer to the app, though scripts still needed to be treated as actual operations with their own behavior, rather than decoration in a menu. July added installer and uninstaller work and then Virtual Audio Driver support. That expanded the panel's role from display configuration toward managing a small family of virtual-device tools. It also made accurate driver detection and operation feedback more important: the app needed to know which device and package an action concerned. These commits document capability development, not a newly verified release on every Windows configuration. There were still changes and reversals ahead in the installation controls. For this stage, the meaningful progress was that the interface was becoming connected to configuration, lifecycle actions and diagnostics that could save a user several manual steps. --- # A control panel for the settings behind the driver > From a nonfunctional shell to early commands and XML editing. Canonical page: https://pyrosoft.pro/blog/a-control-panel-for-the-settings-behind-the-driver Live development journal; no publication date. Work period: 2025-01-27 to 2025-02-22 Updated: 2026-10-20 A virtual display is much easier to recommend when changing it doesn't start with hunting for an XML file. The Driver Control Panel began as a way to bring those settings and driver actions into one place. The January 27 history is refreshingly direct: an initial commit is explicitly marked nonfunctional. From there, the work added system information, tools and a prototype XML editor. Interface experiments followed, but the application was still being connected to the things it needed to control. By January 30, the history records pipeline restart functionality and initialization fixes. Community and Sunshine script menus followed in February, along with a Python named-pipe utility. XML configuration work continued later that month. The practical goal was to connect an action in the app to the driver or its configuration. A restart button needs a real command behind it. An editor needs to load and preserve the relevant settings. A script menu needs to explain what it is about to run. That distinction matters for the timeline. The early screens and blank functions show the direction of the project, but they aren't evidence that every tool visible in the interface was already complete. The retained messages let us describe the prototype stage without pretending it was the finished panel. What I like about this beginning is the user problem it identifies. The driver already had useful capabilities; the missing piece was a more approachable way to manage them. The next work would connect the controls, improve the feedback and reduce the amount of manual configuration needed for an ordinary display change. --- # Advanced controls, shared workflows and the bundled CLI > The path through the layout patches to 26.10.5.6, build 41. Canonical page: https://pyrosoft.pro/blog/advanced-controls-shared-workflows-and-the-bundled-cli Live development journal; no publication date. Work period: 2026-10-05 to 2026-10-05 Updated: 2026-10-20 After the native-device work, the next revisions made the suite easier to use and automate. Build 39 corrected the window layout, keeping the sidebar full height and putting session actions in the right panel's footer. Build 40 stopped showing a purchase button to someone whose access was already verified. Build 41 then added Advanced controls across the seven driver pages, 28 workflow shortcuts and a bundled JSON CLI with 49 methods. A workflow configures the next instance without silently starting devices. That's useful when you're preparing a recording or test setup and still need to choose the actual source, route or backing file. The CLI shares resource ownership with the GUI and headless app. It can query supported fields, configure instances and perform live actions through the same owner. That avoids having two unrelated processes each believe they control the same virtual device. The controls also became more specific. Displays gained additional modes, placement and Display P3 wide-gamut SDR. Cameras exposed real source selection and live adjustments. MIDI, HID, private networking, audio routing and owned disk images each kept their own supported actions and limits. Display P3 didn't add HDR output, and a portrait-size display didn't become live rotation support. The final 26.10.5.6 record includes 89 passing tests, packaged CLI checks, 60 abnormal-client cases, seven-driver UI inspection and exact camera pixels. The actual itch download matched all 64 tested app files and passed signature, ticket and Gatekeeper checks. The saved public page was checked too. That is the latest documented macOS suite release in this review. The remaining work includes fresh-machine and broader hardware coverage, sleep and reboot behavior, cross-machine tunneling and live audio-consumer acceptance on that final package. Those are useful next tests around a suite whose implemented paths now have much stronger evidence behind them. --- # Real camera sources, HID reports and a private peer tunnel > Build 36 turns several remaining paths into measurable native workflows. Canonical page: https://pyrosoft.pro/blog/real-camera-sources-hid-reports-and-a-private-peer-tunnel Live development journal; no publication date. Work period: 2026-10-05 to 2026-10-05 Updated: 2026-10-20 The next October 5 milestone moved several modules beyond their earlier limits. Build 36 added real camera-source pipelines, native HID descriptors and reports, MIDI 2 UMP endpoints, encrypted disk images and an authenticated encrypted peer transport. The camera work had an especially useful test. A selected image traveled through capture, the Core Media I/O sink, the extension and an AVFoundation consumer, where the exact BGRA pixels matched. Earlier preference-based exchange had failed across the service boundary, so the implementation moved to the public CMIO provider bridge and IOSurface streams. HID acceptance created and enumerated a real gamepad, received actual reports in a native client, neutralized it and released it. The Apple capability request had been approved. This remained a macOS 15-and-newer feature, with no physical haptic actuator implied by a virtual controller. The network probe sent a packet through macOS packetFlow, an authenticated encrypted companion and back again, with real counters. It was an explicitly configured private peer tunnel, not a general public VPN. Storage testing created and reused an encrypted APFS image, rejected a wrong password, mounted it and detached it safely. The release record includes 58 strict tests, notarization and a verified itch download matching all 61 tested app files. That supplies a real publication milestone beyond the preceding candidate. There were still clear boundaries: the camera used BGRA sRGB without embedded audio or HDR, displays depended on an undocumented Mac API, and clean-install, reboot, sleep/wake and another physical Mac remained unverified. The progress was specific and useful because we could follow actual frames, reports and packets through the intended native path. --- # Teaching the suite to recover its own devices > Resource journals, atomic audio installation and safer storage handling. Canonical page: https://pyrosoft.pro/blog/teaching-the-suite-to-recover-its-own-devices Live development journal; no publication date. Work period: 2026-10-05 to 2026-10-05 Updated: 2026-10-20 A virtual device can outlive the window that created it. If the app quits unexpectedly or an extension finishes activating late, the next launch still needs to understand what belongs to the suite and how to stop it safely. The first October 5 candidate concentrated on that recovery problem. A durable resource journal recorded ownership before persistent creation. Startup discovered the app's cables, cameras, network managers and mounted images, exposing recovery and Stop actions. Cancellation and late callbacks were tied back to the original request instead of being allowed to create an unexplained leftover resource. Audio installation became an atomic, validated operation with rollback. The helper checked the actual staged signed bundle, preserved unknown or unsigned installations and restricted its operations to the suite's own bundled cables. Replacing a cable can interrupt system audio, so that action needs to be explicit and bounded. Storage gained similar care. New images used unique default paths, reuse required a matching app-created image and configuration, and ordinary files were rejected without overwriting them. Cleanup didn't force-detach an image just to make the interface look finished. Product-specific ownership verification and bounded offline access were added as well, while Stop and cleanup stayed available without a license. That matters when someone needs to remove a device after access expires. The 26.10.5.1 record includes 47 strict app tests, 18 backend tests and notarized package checks. It was a candidate with commercial and runtime acceptance still open at that stage, including HID approval. The following October 5 revisions addressed more of those gaps; this chapter records the safety foundation they built on. --- # Testing what the Mac devices actually deliver > Audio measurements, MIDI round trips and a real disk-image workflow. Canonical page: https://pyrosoft.pro/blog/testing-what-the-mac-devices-actually-deliver Live development journal; no publication date. Work period: 2026-09-06 to 2026-09-08 Updated: 2026-10-20 The September verification is where the macOS suite's history gets much more concrete. Instead of just listing device pages, the record describes what happened when the app created, used and stopped them on the test Mac. For audio, the test installed two cables and measured both a loopback and a route through the app mixer into the second cable. Live mute produced silence, and changing gain changed the measured output without restarting the session. That is much more useful than confirming that a volume slider moves on screen. Display testing created two virtual monitors, stopped one and created a replacement while the other survived. MIDI endpoints completed a live note round trip. Storage testing created an APFS sparse bundle, mounted it, copied a file, read the same bytes back and detached it through the app. The camera appeared in QuickTime and delivered the generated color-bar stream used at that stage. The network extension created an isolated interface and cleaned up its test routes, but it was still a packet sink rather than the later peer transport. HID remained gated, and MIDI 2.0 wasn't being presented as supported. Version 26.9.6.1 passed 34 tests and its recorded signing, notarization and extracted-package checks. The upload and page work were verified, while the listing remained a private draft in that record. The September 8 recheck didn't introduce another binary. This stage gave us a useful baseline with honest limits: real audio and storage behavior, a working test camera source and several lifecycle checks, alongside modules that still needed deeper implementation. The next work would focus on recovery, installation safety and replacing the remaining constrained paths with the intended real services. --- # From a Mac virtual display to a driver suite > A native control center begins expanding beyond monitors. Canonical page: https://pyrosoft.pro/blog/from-a-mac-virtual-display-to-a-driver-suite Live development journal; no publication date. Work period: 2026-08-30 to 2026-08-31 Updated: 2026-10-20 The macOS project started with a familiar question: can we create another useful display without attaching another screen? The August 30 history begins with a native Mac display app, then quickly expands into a broader Virtual Drivers suite. This is a separate implementation from the Windows Virtual Display Driver. The Mac display path uses CoreGraphics virtual-display classes through a native bridge, while the app itself is built with SwiftUI. That means the Windows driver's HDR capabilities and installation model don't automatically carry over. The same day's work broadened the application into a suite, and the later commits added audio, camera and network device code. Screenshots followed on August 31. The retained Git history is compact, but it captures the transition from one virtual-device idea into a shared control center. A common interface makes sense here. A display, audio cable or MIDI port has its own configuration, but people still need a consistent way to create it, see whether it's active and stop it. The app can bring those lifecycle actions together while the underlying services remain specific to each device type. The early release-named commits describe the versions in that history. They don't, by themselves, prove every later module was fully implemented or broadly tested that weekend. The September and October verification records provide the more useful detail on what was exercised and when. What I like about the direction is the practical overlap between these tools. Recording, streaming, music and test setups often need more than one kind of virtual device. A native Mac suite could make those pieces easier to configure together, provided each one still had a real implementation and clear capability limits. --- # Free manual Windows gaming setup on Apple Silicon: step by step > Install Sikarugir, create a Wine wrapper, configure graphics, install Steam or a standalone game, and troubleshoot your first launch. Plus honest paid alternatives. Canonical page: https://pyrosoft.pro/blog/manual-windows-gaming-apple-silicon-free-2026 Published: 2026-09-05 Some links to other products on this page are affiliate links, and we may earn a commission if you buy through them. It costs you nothing extra, and it has not changed what this article says — where a competitor is the better answer, we say so. **You can set up Windows gaming on an Apple Silicon Mac without buying a launcher.** This guide walks through a free manual route using Sikarugir, a maintained Wine wrapper: install the tools, create a separate Windows environment, choose graphics settings, install Steam or a standalone game, and make a repeatable launcher. Free means no charge for this setup route. Games, subscriptions inside games, and any separately required operating-system license are not included. This Wine route does not install Windows and does not require a Windows OS license. It also does not promise that your particular game will work. **Checked September 5, 2026.** We verified upstream download sources, package definitions, current engine/template lists, and configuration control names. This is a source-checked walkthrough, not a claim that we completed a fresh installation or played every game on every Mac. Upstream versions and storefront prices can change. ## Choose the route that fits your game First check the game's store page for a native macOS version and its current macOS requirements. If one exists, install that version directly. For a Windows-only game, check its anti-cheat, graphics requirements and recent Mac compatibility reports before downloading tens of gigabytes. Wine implements Windows APIs on macOS; graphics translation connects the game's DirectX calls to a supported Mac graphics backend. Rosetta translates Intel code on Apple Silicon. A virtual machine instead boots a complete guest operating system. Parallels normally runs Windows 11 Arm on Apple Silicon, with Windows handling compatible x86/x64 applications and Parallels providing a virtual graphics device. These approaches have different compatibility limits. **Affiliate disclosure:** We sell Bourbon. The CrossOver and Parallels links below are affiliate links, and we may earn a commission if you purchase through them. | Choice | Cost and conditions | Why choose it? | Manual Sikarugir setup | No setup-software purchase; games separate | You want control and can spend time choosing settings and troubleshooting. | [Bourbon]() | $29.99 one-time purchase | You prefer a guided app and centralized setup/library management. Check your games and current release requirements first. | [CrossOver+]() | $74 USD list; $62.90 with MIKETHETECH15 when accepted at checkout | A commercial compatibility layer with 12 months of support, upgrades and fixes. Your purchased version keeps working after that period; further support/upgrades require renewal. Do not assume the introductory discount applies to renewal. | [Parallels Desktop]() | Standard: $99.99/year list; Pro: $119.99/year list. Current official US promotional data shows $54.99 and $65.99 respectively; confirm offer duration and final price at checkout. Standard perpetual: $219.99 for the purchased version. Subscriptions auto-renew by default; future major versions are not included with the perpetual license. | You need a full Windows environment as well as compatible games. Windows licensing is separate. Prices are a September 5, 2026 USD snapshot, before applicable tax. Region, promotion, edition and renewal terms can change; confirm the final total and auto-renewal terms before paying. A higher-priced option still cannot guarantee a game's compatibility. See [CodeWeavers' store]() and [Parallels' edition comparison]() for current terms. The Parallels promotional figures come from its [live pricing data](); we did not complete a purchase or verify a final checkout total. Read its [subscription and perpetual-license terms]() and [CrossOver licensing terms](). ## 1. Prepare your Mac and game files - Use an Apple Silicon Mac with macOS Sonoma 14 or later for this Sikarugir route. Check Apple menu → About This Mac. Keep enough free storage for the game, installer, wrapper and a backup; a large game can require substantially more space during installation than its final size. - Have an administrator account available for prerequisite installers, an internet connection, and a legitimate Windows game installer or Steam account. Quit other games before configuring the new wrapper. - Use the official [Sikarugir GitHub repository](). The maintainers explicitly warn that the similarly named sikarugir.com website is unrelated. Do not obtain engines or installers from that site. - Back up existing saves. A Wine wrapper is an application environment, not a security sandbox: run only installers you trust. ## 2. Install Rosetta and Homebrew Open Terminal from Applications → Utilities. If Rosetta is not installed, run this command and read/accept Apple's displayed license prompt: `/usr/sbin/softwareupdate --install-rosetta` Apple explains Rosetta in its [official support article](). If it is already installed, continue. Run `brew --version`. If Terminal reports that brew is not found, open [Homebrew's official site]() and follow its current installer instructions. Complete the “Next steps” printed by the installer, including its shell configuration instructions, then open a new Terminal window and run `brew --version` again. Follow any Command Line Tools requirement shown by the installer; `xcode-select --install` opens Apple's installer when those tools are missing. Use Homebrew's standard Apple Silicon installation at `/opt/homebrew`; this guide does not need a second Intel Homebrew. See [Homebrew's installation requirements]() if this step fails. Do not continue until brew runs successfully. ## 3. Install Sikarugir Creator from its official tap Review the project's [package definition](), then run these commands individually: `brew update brew trust Sikarugir-App/sikarugir brew install --cask Sikarugir-App/sikarugir/sikarugir` The trust command approves this third-party tap. Its installer downloads Creator from the project's GitHub release; its post-install step removes quarantine from that app and applies an ad-hoc signature. That is not Apple notarization. Decide whether you trust this specific source before installing. Do not disable Gatekeeper globally. If an older Homebrew does not recognize `brew trust`, update Homebrew and consult the current upstream instructions. Open **Sikarugir Creator** in Applications. Creator 1.0.1 was listed when we checked. Older tutorials may say Wineskin or Kegworks; their interface labels can differ. Also, `brew install --cask wine-stable` is not our installation path: [Homebrew currently marks that cask disabled](). ## 4. Download an engine and create a wrapper - In Creator, download the template offered in the Template area. Our check found **Template-1.0.15** in the official [template list](). - Open the engine selector and download **WS12WineSikarugir10.0_6**, a version present in the official [engine list]() at publication. Select it after download. Treat this as a documented starting point, not a claim that it is the best engine for every title. Record any different version you choose. - Use **Create empty app**, name it **Manual Steam** (or a specific standalone game's name), and click **Create**. In older Creator interfaces this action may be called “Create New Blank Wrapper.” - Wait for creation to finish and open the resulting location. Keep the wrapper in your user Applications folder, usually `~/Applications/Sikarugir`. Record its actual location if you choose another folder. - Open the empty wrapper to configure it. To return to configuration later, right-click the wrapper in Finder, choose **Show Package Contents**, and open its **Configure** application. The wrapper contains its own virtual C: drive and settings. Use a different wrapper for a game that needs conflicting settings. Do not point this experiment at a Bourbon or CrossOver bottle. If an engine download returns “too many requests,” wait and retry later; don't substitute an untrusted mirror. ## 5. Choose the graphics path Start with the wrapper's defaults and open Configure → Advanced to inspect the graphics controls. The upstream defaults use WineD3D for older DirectX, D9VK for DirectX 9, and DXMT for DirectX 10/11. The following choices are alternatives, not settings to stack: | Game requirement | Starting choice | What to check | DirectX 8 or earlier / simple 2D | Default WineD3D path | Try a windowed launch first. | DirectX 9 | Default D9VK path | Keep the default initially; investigate game-specific reports if it fails. | DirectX 10 or 11 | DXMT | If rendering fails, quit the game and try DXVK as a separate test. | 64-bit DirectX 11 or 12 | Optional D3DMetal | Apple Silicon required. Review the separate Apple license before using it. The Configure controls are named “DirectX to Metal translation layer - (DXMT),” “DirectX to Vulkan translation layer - (DXVK),” and “Direct3D to Metal translation layer - (D3DMetal).” Select one relevant backend and close configuration before launching. The current configuration code turns the other two off when one is selected. **D3DMetal is optional proprietary Apple software, not open-source Wine.** Sikarugir links its [D3DMetal license](); review its conditions. This guide's default DXMT route does not require enabling it. If you do not accept those terms, leave D3DMetal disabled and choose a game that works with another backend. Do not assume generic Linux DXVK/VKD3D install commands create a supported macOS DirectX 12 setup. ## 6. Install Windows Steam and your game - Visit [Valve's Steam download page]() and select the **Windows** download. You need `SteamSetup.exe`, not the macOS DMG. - In your Manual Steam wrapper's Configure window, choose **Install Software → Choose Setup Executable**. Select `SteamSetup.exe` from Downloads. - Complete Steam's installer inside the wrapper using its default C: drive location. Let Steam update. If setup offers to launch Steam immediately, you can clear that option and finish setup first. - When Configure asks which executable to launch, choose `C:\Program Files (x86)\Steam\steam.exe`. If it does not offer the right file, use **Advanced → Browse** beside “Windows EXE” to select `steam.exe` from the wrapper's C: drive. Do not leave the launch target pointing to SteamSetup.exe. - Close Configure and double-click the Manual Steam wrapper. Sign in using Steam's normal interface and complete Steam Guard yourself. - Open Library, choose a Windows game whose requirements fit this route, and click Install. Use the default library inside the wrapper initially. - Click Play. Allow the game's legitimate first-run prerequisite installers to finish. Start with low graphics settings, a modest resolution and windowed mode. Confirm the main menu, actual gameplay, sound, controls, saving and loading. - Exit the game and Steam, reopen the wrapper, and launch the game again. A working installer or menu alone is not a successful gameplay test. Steam working does not establish that every game in its library works. Native Mac games belong in native macOS Steam. If a specific game's launcher update breaks the Windows client path, check current reports before changing a working wrapper. ## 7. Install a standalone EXE, MSI or portable game instead Create a separate wrapper with a descriptive name. Download the Windows installer from the game's publisher or your store account. For GOG titles, use the game's offline backup installer when available and keep its EXE and any accompanying BIN files together. - Choose **Install Software → Choose Setup Executable**, select the EXE or MSI, and complete installation to the wrapper's C: drive. - For an extracted portable game, use **Install Software → Copy a Folder Inside**. Copy the entire game folder, including data files; copying only the EXE is rarely enough. - Select the actual game executable when prompted. Use Advanced → Browse to correct the Windows EXE path if necessary. Avoid selecting an uninstaller or setup program. - Use **Test Run** once, then close Configure and launch normally by double-clicking the wrapper. Repeat the gameplay/save/reopen checks from the Steam section. You can drag the completed wrapper to the Dock for convenient launching. Store-dependent games may still require their original client; an EXE file alone does not remove DRM or ownership requirements. ## 8. Troubleshoot one change at a time - **Nothing opens:** Check the Windows EXE path, selected engine and Rosetta installation. Use Configure → Advanced → Test Run, then **View Last Run Log File**. Keep the first relevant error plus your macOS, chip, engine, template and renderer versions. - **Black screen or graphics error:** Confirm the game's DirectX requirement. Try windowed mode and lower resolution. For a DX11 game, compare DXMT and DXVK in separate runs after fully exiting the game. DX12-only games need an appropriate DX12 path; switching to DXVK is not a universal solution. - **Missing Visual C++ or .NET:** Use the game's supplied prerequisite installer or a game-specific recommendation. Configure includes **Winetricks** and Wine tools, but installing every runtime or random DLLs into one wrapper can create new conflicts. - **Steam installs but the game fails:** Verify game files inside Steam. Check the game's launcher, anti-cheat and recent compatibility reports. Do not infer compatibility from a successful Steam login. - **A process remains stuck:** Save work in other Wine apps first. Configure offers **Kill Wine Processes**; use it cautiously because terminating Wine processes can discard unsaved work. Then reopen the affected wrapper. - **Gatekeeper or malware warning:** Recheck the download source and upstream guidance. Don't turn off system-wide security or assume every detection is harmless. ## 9. Back up before updates, and know when to stop Quit the game, client and wrapper before copying the entire wrapper app to another location. Also back up saves that live outside it: Configure can map Windows Documents and other folders to your real Mac folders. Confirm cloud saves have synchronized rather than treating them as a guaranteed backup. Record the working engine/template/renderer combination before updating one component at a time. To remove an experiment, quit it and move its specific wrapper to the Trash in Finder after preserving saves. Don't delete shared Sikarugir support folders while other wrappers still use them. Removing a wrapper may not remove externally mapped saves. Kernel-level Windows anti-cheat, incompatible DRM, unsupported graphics features and some launchers can block local play. Neither Wine nor a VM guarantees a workaround. Use an available native version, a supported streaming service, or a Windows PC for those games. Parallels is a legitimate alternative for a full Windows desktop and compatible games, rather than a universal gaming upgrade: its [current gaming support page]() lists DirectX up to 11 and OpenGL up to 4.1, with additional game-specific restrictions. A Windows Arm VM cannot load arbitrary Intel Windows drivers. ### Keep the choice yours If you enjoy managing wrappers, the manual route gives you a practical place to start. If you'd prefer guided setup, consider Bourbon. If vendor support matters, try CrossOver with your actual game. If you also need a full Windows environment, evaluate Parallels and account for Windows licensing. Test the games you care about before committing to a paid option. [Check Bourbon compatibility]()[View Bourbon, $29.99]() --- # Windows games on Mac > Every way to run Windows games on a Mac in 2026 — translation, streaming, virtual machines — and which one fits the games you actually play. Canonical page: https://pyrosoft.pro/blog/windows-games-on-mac Published: 2026-07-26 **Windows games run on a Mac three ways:** translation (Wine and Apple's Game Porting Toolkit), streaming, or a virtual machine. Which one is right depends on the game — here's the honest map. People ask this constantly, and our answer is Bourbon 26, which you'd expect us to say. The more useful version is showing you why, because it comes down to what you actually play. **The 20 second version.** Get Bourbon 26. It's the only one of these tools that covers all three cases: it translates your Windows Steam games, routes your native Mac titles to the real Mac Steam client, and streams the anti-cheat ones that can't run locally at all. $29.99 once, no subscription. ## Start here: do you even need this? A lot of people build out a whole Wine setup for a game that already has a Mac build sitting right there on Steam. Of the 24,000 plus titles in our compatibility list, the big majority are native macOS builds. Steam installs them directly and nothing gets translated at all. So before anything else, look your games up. If they come back native, you're done. Go play. ## Windows only? Then you want Bourbon 26 Bourbon runs the actual Windows game and converts what it says into something macOS understands. Windows API calls become macOS ones, DirectX calls become Metal. No Windows license, no virtual machine, no giant disk image eating your SSD. This covers the big middle of most libraries. Single player stuff, older titles, indie games, anything without kernel level anti-cheat. The annoying part has always been setup. Wiring up Wine, DXVK, MoltenVK, VKD3D and a working Steam install by hand eats an afternoon, minimum. That's the exact problem Bourbon 26 is built to delete. One button installs all fourteen pieces including Steam, then Smart Play picks a graphics path per game so you're not sitting there guessing whether a title wants DXVK or VKD3D or something else entirely. ![Bourbon 26 games library](https://pyrosoft.pro/assets/images/bourbon26/games.jpg) Smart Play tags each game with the runtime it picked. ## Anti-cheat games? Stream them Fortnite, Valorant, Apex, PUBG, Rainbow Six Siege, Destiny 2, Call of Duty. These load a Windows kernel driver to watch for cheats, and macOS can't load Windows kernel drivers. Not "can't yet", just can't. No Wine wrapper or VM changes that. What does work is streaming, and this is where Bourbon still has you covered. Its Remote Play tab puts GeForce NOW, Xbox Cloud, Amazon Luna and Boosteroid in native windows, adds Chiaki for PS4 and PS5, and Moonlight for streaming off a gaming PC you already own. Same app, same library screen, no second tool to go find. That's the thing none of the alternatives do. CrossOver, Parallels and Whisky all translate or virtualize and stop there. If a game won't run locally they have no answer for you at all. ## What about a virtual machine? Parallels running Windows 11 ARM is great for business software and pretty rough for games. There's no GPU passthrough on Apple Silicon, so the guest gets a virtual display adapter instead of your actual M series GPU. You also need a Windows license on top of the $99.99 a year. For gaming, a translation layer talking straight to Metal wins. It isn't close. ## What each option costs | Option | Cost | Best for | Native Mac build | Free | Anything that has one | Bourbon 26 | $29.99 once | Windows only Steam library | CrossOver | $74/yr | Cross platform, paid support | Apple GPTK on its own | Free | People who like the Terminal | Cloud streaming | Subscription | Anti-cheat games | Parallels plus Windows | $99.99/yr plus license | Business software, not games Competitor pricing checked June 2026. ### So what should you do? Your library is probably a mix of all three: some native Mac builds, some Windows only titles, and a couple that anti-cheat blocks entirely. Bourbon 26 is the only one of these options that handles all three in a single app, and it's $29.99 once with no renewals. Look your games up first, that part's free. [Search your games, free]() [Buy Bourbon 26, $29.99]() --- # Steam on Mac > Steam runs on macOS, and most of its catalog can reach your Mac one way or another. What's native, what needs translation, and what streams. Canonical page: https://pyrosoft.pro/blog/steam-on-mac Published: 2026-07-26 **Steam runs natively on macOS.** The real question is which of your games do — and what to do about the ones that don't. Here's the breakdown. Yes. Steam has a proper macOS client and thousands of games run on it with zero extra software, and Bourbon 26 picks up everything that doesn't. What confuses people is that Steam shows your whole library no matter what platform it's for, so a game you definitely own will sometimes just refuse to install and not tell you why. ## Your library splits three ways ### 1. Games with a Mac build These just work. Install Steam for macOS, hit download, play. Full speed, nothing translated, nothing to configure. It's also the biggest group by a mile, with over 24,000 titles in our database being native Mac builds. ### 2. Windows only, no kernel anti-cheat These need Bourbon. Steam itself has to run inside a Windows environment and the game runs inside that, which Bourbon sets up for you in one pass instead of the afternoon it takes by other routes. ### 3. Windows only with kernel anti-cheat These won't run locally on a Mac under any tool. Bourbon streams them instead, from the same app, so they still end up playable. ## How to tell which is which On the Steam store page, look at the little platform icons next to the price. An Apple logo means there's a Mac build. In your library, a game without one simply won't give you an Install button on macOS. Easier still, search our compatibility list, which tags every title with the runtime Bourbon assigns it, including the ones that need streaming instead and why. Sort that list by popularity and the pattern jumps out. Terraria, Rust, Stardew Valley, Cyberpunk 2077 and Baldur's Gate 3 all have Mac builds. PUBG, Rainbow Six Siege, Apex Legends and Destiny 2 are all blocked by anti-cheat. Bourbon reads that database for you and picks the right route per game, so you never have to check manually. ## Getting the Windows only ones running For that middle group you need Steam running inside a Windows compatibility environment. By hand that means installing Wine, making a prefix, installing Steam into it, adding DirectX translation, and then working around the way the current Steam client renders under Wine, which needs a specific UI shim to look right. Bourbon 26 does all of that during setup. Steam is one of the fourteen components it installs, and the shim goes on automatically. You sign into your own Steam account and download your own games, so nothing about who owns what changes. ![Bourbon 26 Stores tab with Steam](https://pyrosoft.pro/assets/images/bourbon26/stores.jpg) Steam management inside Bourbon, with the client already installed. ## Do my saves and achievements still work? Yep. You're signing into the real Steam client, so Cloud saves, achievements and playtime all behave normally. Steamworks games authenticate the way they always do, because it really is Steam. ### Short answer Most Steam games run on a Mac with no help at all, so check for that Apple icon first. For the Windows only ones without anti-cheat, Bourbon 26 gets Steam running inside a working Wine setup for $29.99, once. [Check your library]() [Buy Bourbon 26]() --- # Anti-cheat on Mac > Kernel-level anti-cheat is why Fortnite, Valorant and Apex won't run on a Mac through any translation layer — and what actually works instead. Canonical page: https://pyrosoft.pro/blog/anti-cheat-on-mac Published: 2026-07-26 **Anti-cheat is the one wall Mac gaming can't climb.** Kernel-level systems like Easy Anti-Cheat, Vanguard and BattlEye need a real Windows kernel, so no translation layer — Bourbon, CrossOver, Whisky or Apple's own toolkit — can satisfy them. Here's why, and the routes that still work. This is the big disappointment in Mac gaming and it's worth understanding properly, because the answer isn't "Macs are too slow" and it isn't something a better app fixes next year. The good news is that Bourbon 26 planned for it, and these games still end up playable. We'll get there. First, the why. ## Here's what's actually going on Competitive shooters protect themselves with anti-cheat that runs at kernel level. **Easy Anti-Cheat** for Fortnite and Apex, **Riot Vanguard** for Valorant, **BattlEye** for PUBG and Rainbow Six Siege among others. Kernel level means the anti-cheat loads a Windows driver right into the core of the operating system so it can see everything running on your machine and catch cheats that hide from normal checks. That's the whole point of it. macOS can't load Windows kernel drivers. The two systems have completely different kernel architectures and driver models. A translation layer rebuilds the Windows API in user space, so it has no way to shove a Windows driver into the macOS kernel, and macOS would block it anyway. If you see a video claiming to run Valorant natively on a Mac, it's either wrong, it's actually cloud streaming, or it's something that'll get your account banned. Anti-cheat treats weird environments as suspicious on purpose. ## A VM doesn't save you either Reasonable next thought: run a Windows 11 VM, get real Windows, get real kernel drivers. Except anti-cheat systems detect virtualization and usually refuse to start inside it, because a VM is a handy place to hide a cheat. Parallels isn't getting you into Valorant. ## What does work Two options, both of which move the game off your Mac, and both of which Bourbon has built in so you're not running a second app. ### Cloud gaming The game runs on a Windows box in a data center and streams to you. **GeForce NOW** and **Xbox Cloud Gaming** both carry Fortnite, and Apex is on GeForce NOW. Valorant availability moves around, so check before you subscribe. You'll want solid internet, and there's latency, which matters more in these games than most. ### Remote Play from your own PC Already own a gaming PC? Stream from it over your own network with **Moonlight**. On a wired local network the latency is tiny, and the game is running on real Windows with real anti-cheat, so nothing sketchy is happening. Bourbon has both built in, plus Chiaki for PS4 and PS5, sitting right next to your translated games and your native Mac ones. So when Fortnite won't run locally, you're not switching apps or hunting for a second solution. You open the same window and stream it. That's worth weighing against the alternatives. CrossOver and Whisky are translation layers and nothing else. Parallels is a virtual machine and nothing else. None of them have a plan for the games that can't be translated, which means you end up running two or three tools instead of one. ![Bourbon 26 Remote Play options](https://pyrosoft.pro/assets/images/bourbon26/remote-play.jpg) Cloud services, Moonlight and Chiaki in one tab, none of which touch Wine. ## What Bourbon is actually good for Everything else, basically. Single player games, older titles, indie stuff, Steamworks games without kernel anti-cheat. That's a huge library and it runs well. Our compatibility list flags anti-cheat games as Not Compatible right up front so you can check before spending anything. ### Straight answer Kernel anti-cheat games don't run locally on a Mac, and no app changes that. What differs is what happens next. Bourbon's answer is Remote Play in the same window, so Fortnite streams while the rest of your library runs properly through translation, and your native Mac titles launch straight from Steam. One app, all three routes. CrossOver, Parallels and Whisky each handle exactly one of them. [Check a specific game]() [Buy Bourbon 26, $29.99]() --- # Boot Camp on Apple Silicon > Boot Camp doesn't exist on M-series Macs. What replaced it for games, and when you actually need a full Windows install. Canonical page: https://pyrosoft.pro/blog/boot-camp-apple-silicon Published: 2026-07-26 **There is no Boot Camp on Apple Silicon.** M-series Macs can't dual-boot Windows at all — but for games, that matters less than you'd think. If your last Mac was Intel, this is the first wall you hit. Boot Camp let you install Windows on its own partition and boot straight into it. A real Windows PC that happened to live inside a Mac, full speed, no compatibility questions. It's gone on Apple Silicon and it isn't coming back. Bourbon 26 is what fills that gap now, and the trade is better than most people expect. ## Why it disappeared Boot Camp worked because Intel Macs were, underneath, regular x86 PCs. Windows for x86 could boot on them directly. M series Macs are ARM. The x86 version of Windows can't boot on ARM hardware at all. There is a Windows 11 build for ARM, but Apple doesn't provide the firmware, drivers or licensing path to boot it on bare metal, and Microsoft doesn't sell a general license for it that way. Both companies would have to change their minds, and neither is showing signs of it. Upside nobody mentions: with Bourbon 26 you don't reboot, partition your drive, or babysit a second operating system. Your Windows games sit in the same library as your Mac ones and launch from the same window. ## What replaced it ### Bourbon 26, the closest thing for games Bourbon runs the Windows game right on macOS, translating its Windows calls to macOS ones and its DirectX to Metal. No reboot, no partition, no Windows license. Performance holds up because the graphics work reaches your real GPU through Metal instead of an emulated adapter. It installs the whole stack including Steam, picks a graphics path per game, routes native Mac titles to the Mac Steam client, and streams the anti-cheat games that can't run locally. That's all three of Boot Camp's jobs, in one app, for $29.99 once. ### 2. Windows 11 ARM in a VM Parallels runs the ARM build of Windows in a virtual machine. Great for business software, weak for games, because there's no GPU passthrough on Apple Silicon so the guest never touches your real GPU. You need a Windows license too. ### Streaming, which Bourbon includes Cloud gaming services, or Moonlight from a PC you already have. It's the only route for anti-cheat games, and Bourbon puts all of it in the same window as everything else rather than making you go find another app. ## What you actually lose Boot Camp gave you 100% compatibility because it was Windows. Nothing on Apple Silicon matches that for games: - Kernel anti-cheat games are out entirely, whatever you try locally. - Some titles need per game tweaking instead of working first try. - A few DRM schemes still act up under translation. What you gain is no rebooting, no Windows purchase, no 100GB of your SSD gone, and for a big slice of the catalog, performance that's completely fine. ### So what now? Stop hunting for Boot Camp, it isn't hiding somewhere in Settings. For a Windows Steam library on an M series Mac, a managed translation layer is the closest thing, and Bourbon 26 is $29.99 once with no Windows license to buy. Check your specific games first though, that part's free. [Check your games]() [Buy Bourbon 26, $29.99]() --- # Play Windows games on Mac for free > The genuinely free routes — raw Wine, Game Porting Toolkit, what's left of Whisky — what they cost you in time, and when $29.99 stops being worth avoiding. Canonical page: https://pyrosoft.pro/blog/free-windows-games-on-mac Published: 2026-07-26 **Yes, you can do this for free.** Everything Bourbon automates is open source, and this guide maps the free path honestly — including the hours it asks for in exchange. Sort of, and it's worth knowing what free actually buys you before you spend a weekend finding out. Short answer up front: the free options each solve one piece of the problem. Bourbon 26 solves all of it for $29.99 once, which is less than most people spend on a single game. Here's the comparison. ## The free routes ### Apple's Game Porting Toolkit Free, straight from Apple, and the D3DMetal renderer inside it is excellent. Catch is it's an evaluation tool for developers: Terminal commands, no interface, no library, one renderer with no fallback when a game doesn't suit it. Bourbon installs GPTK as one of its fourteen components and adds the other four renderers around it, so you get Apple's technology without the developer workflow. ### Whisky, CrossOver's free trial, and the rest Whisky was the friendly free option and it's covered below. CrossOver has a trial rather than a free tier, so it's a paid product with a look first. Everything else in this space is either a front end over the same open source pieces or a command line workflow with no interface at all. ### Whisky Used to be the friendly free pick and it earned that. Development stopped, which matters a lot here because macOS, Steam, Wine and the graphics layers all keep moving. An install you already have might limp along a while. Nobody's fixing it when it stops, and Bourbon is where most Whisky users have landed since. ### Steam's Mac catalog Thousands of games have real macOS builds and need no translation at all, over 24,000 titles in our compatibility list. Bourbon checks this for you and sends those games straight to the Mac Steam client, so you get the native build automatically instead of accidentally translating something that didn't need it. ## What free actually gets you The free options all share the same gaps. None of them install Steam for you. None of them ship a second Wine runtime for fragile 32 bit software. None of them pick a renderer per game. And none of them do anything at all for the games that can't be translated, so you're still opening a separate app to stream Fortnite. GPTK gives you one renderer. Whisky gives you a bottle and a dead maintenance story. Neither gives you a library that just launches. No tool gets you into anti-cheat games locally, free or paid, because macOS can't load Windows kernel drivers. The difference is that Bourbon streams them for you from the same app. The free options just leave you stuck. ## What $29.99 adds All fourteen components installed in one pass including Steam and its UI shim. Five renderers instead of one, assigned per game from a database of 24,000 plus titles. A second Wine runtime for the awkward 32 bit stuff. Remote Play for the games translation can't touch. And somebody tracking Wine, Steam and macOS changes so it keeps working next year. It's one payment against a free tool that's either unmaintained or wasn't built for players in the first place. For most people that's a short conversation. ### Being straight with you Check Steam's Mac catalog first, since native builds beat translation every time and Bourbon routes you to them automatically anyway. For everything else, $29.99 once gets you the whole stack set up, five renderers, and streaming for the games that can't be translated. Look your games up first, that part's free. [Search your games, free]() [Buy Bourbon 26, $29.99]() --- # Bourbon 26 system requirements > What Bourbon 26 needs, everything it installs, and how much disk the whole Windows-gaming stack actually takes. Canonical page: https://pyrosoft.pro/blog/bourbon-26-system-requirements Published: 2026-07-26 No pitch on this one. Just what Bourbon 26 needs and what it does. ## System requirements | Processor | Apple Silicon. M1, M2, M3, M4 or newer | macOS | macOS 14 Sonoma or later | Account | Admin account recommended for first setup | Network | Internet connection for the lightweight edition | Storage | Room for Steam, Wine support files and your games | Signing | Developer ID signed and notarized for Gatekeeper | Price | $29.99, one payment, no subscription Intel Macs aren't supported. The whole thing is built around Apple Silicon and the Metal graphics path. ## What Set Up Everything installs One button, fourteen components, in this order: - **Rosetta 2**, Apple's x86 translation, needed by parts of the toolchain - **Homebrew**, the package manager used to fetch several pieces - **MoltenVK**, Vulkan running on top of Metal - **Wine Staging 11**, the main Windows compatibility runtime - **CrossOver source Wine**, a second runtime in its own prefix for fragile 32 bit Windows tools - **A Wine prefix**, the Windows environment Steam lives in - **DXVK**, DirectX 9, 10 and 11 to Vulkan - **VKD3D**, DirectX 12 to Vulkan - **Game Porting Toolkit 3**, Apple's D3DMetal path, tracked through Homebrew with its own update button - **Steam client**, installed and ready to sign into - **DXMT**, DirectX 10 and 11 straight to Metal - **Steam UI shim**, works around how the current Steam client renders under Wine - **Game runtimes**, Visual C++ and DirectX helper libraries - **Core Windows fonts** Every one of those gets its own status row afterward with individual install, repair, update, disable and remove buttons. Nothing is a black box you have to nuke and redo. ## Optional extras - **Game Porting Toolkit 4 beta.** Bourbon can open Apple's download page and import the DMG for you. Marked experimental, and GPTK 3 stays the default. - **OS Experience.** An optional QEMU based add-on for running full Windows 11 ARM64 or Bourbon Linux virtual machines. Separate from the Wine stack, and not gaming grade, since there's no GPU passthrough. ## What you can run - **Steam games.** Sign into your own account, download your own library. - **Standalone Windows software.** `.exe` and `.msi` files, including through Finder's Open With menu. - **Curated Windows apps.** A built in catalog that installs from each project's official source. - **Remote Play.** Xbox Cloud, GeForce NOW, Amazon Luna and Boosteroid in native windows, plus Chiaki for PS4 and PS5 and Moonlight for your own PC, Linux box or Mac. ## Data and storage Bourbon keeps its runtime data in `~/Library/Application Support/Bourbon`. Wine prefixes, Steam data, support files, logs, configuration. You can move that folder to another drive and repair the paths afterward. External volumes under `/Volumes` can be mapped into Wine drive letters so Steam can build libraries on external storage. ## Licensing One payment of $29.99. Nothing expires. The version you buy stays supported with maintenance updates, meaning fixes for macOS and Steam changes plus ongoing compatibility work. New features land in the next major version, which is a separate optional purchase you're never forced into. ### One line version Apple Silicon Mac on macOS 14 or later, $29.99 once, one button that installs the whole Windows gaming stack including Steam. [Buy Bourbon 26, $29.99]() [Check your games]() --- # DXVK vs D3DMetal > DXVK, VKD3D, DXMT, WineD3D or D3DMetal — what each renderer translates, and which one your game wants on a Mac. Canonical page: https://pyrosoft.pro/blog/dxvk-vs-d3dmetal Published: 2026-07-26 **Short answer: let the game decide.** Each renderer translates a different slice of DirectX, and the right pick is per-title — which is exactly why Bourbon's Bottle Shelf chooses for you. The full map: Windows games speak DirectX. Apple Silicon speaks Metal. Something has to sit in the middle and translate, and there's no single translator that's best for everything. Bourbon 26 ships all five and chooses per game, so in practice you never pick. But it's worth knowing what they are, because most other tools give you one and hope for the best. ## The five options ### DXVK, DirectX 9 through 11 to Vulkan The everyday workhorse. DXVK turns DirectX calls into Vulkan, then MoltenVK turns Vulkan into Metal. Two hops, but DXVK is extremely mature and handles the biggest share of the catalog well. Right default for most modern games. ### VKD3D, DirectX 12 to Vulkan DXVK's sibling for DirectX 12. Modern titles built on D3D12 generally want this instead of being pushed down the DX11 path. ### DXMT, DirectX 10 and 11 straight to Metal Skips Vulkan completely and goes right to Metal. Fewer layers, less overhead, and often the fix for DirectX 11 games that misbehave under DXVK. ### D3DMetal, Apple's Game Porting Toolkit Apple's own DirectX 11 and 12 to Metal translation. Seriously impressive tech and sometimes the fastest thing available, especially on DirectX 12 titles. ### WineD3D, the original Wine's built in translation, going to OpenGL rather than Vulkan. Slower for modern 3D work and way more forgiving for older DirectX 9 games, Source engine titles, and non game business software. WineD3D is the one everyone forgets and it matters. The AIL eAPP insurance client needs WineD3D specifically and flags both DXVK and D3DMetal as known bad. Bourbon already knows that, which is the point of shipping all five renderers and a database that says which goes where. ## Quick reference | Renderer | Translates | Best for | DXVK | DX9/10/11 to Vulkan to Metal | Most modern games, the safe default | VKD3D | DX12 to Vulkan to Metal | Modern DirectX 12 titles | DXMT | DX10/11 to Metal | DX11 games that hate DXVK | D3DMetal | DX11/12 to Metal | Apple's path, strong on some DX12 games | WineD3D | DX9 to OpenGL | Source engine, older games, business apps ## Choosing without testing all five In a tool that only ships one renderer, like GPTK, you don't get to choose. The game either suits D3DMetal or it doesn't. In tools that ship a couple, you're changing a bottle setting and relaunching to find out which works. Bourbon 26 installs all five during setup and assigns one per game through Smart Play, using a compatibility database of over 24,000 titles. You can override it any time you disagree. The idea is that the default is usually already right, so most people never open that menu. ![Bourbon 26 component controls](https://pyrosoft.pro/assets/images/bourbon26/advanced.jpg) All five renderers install during setup, each with its own repair and update actions. ### Short version You shouldn't have to think about any of this. Bourbon installs all five renderers and assigns one per game from a database of 24,000 plus titles, so the right answer is already selected before you launch. Tools that ship one renderer give you one answer to every question, and that's how games end up looking broken for no reason. [Buy Bourbon 26, $29.99]() [See what your game uses]() --- # Wine bottles on Mac > What a Wine bottle (prefix) is, why every game deserves its own, and how Bourbon 26's Bottle Shelf manages runtimes per title. Canonical page: https://pyrosoft.pro/blog/wine-bottles-on-mac Published: 2026-07-26 **A bottle is Wine's private little Windows** — a prefix holding one app's drive C, settings and runtime. Get bottles right and most Wine pain disappears. Here's how Bourbon runs them. Getting a Windows game running under Wine means picking a runtime, picking a renderer, and applying whatever tweaks that particular game needs. Multiply that by a whole Steam library and congratulations, you have a new hobby. The Bottle Shelf is how Bourbon 26 removes that job. No other Mac tool does this part for you. The Bottle Shelf turns those choices into named presets. Each bottle is a tested combination, and Smart Play assigns one per game automatically. ## The bottles | Bottle | Stack | What it runs | Homegrown | Native macOS | Mac native Steam games, no Wine at all | Old Reliable | DXVK, 90 Proof | Most DirectX 9 to 11 and Vulkan games | Heritage Reserve | WineD3D, Aged | Source engine and older DirectX 9 games | Double Barrel | VKD3D, 120 | Modern DirectX 12 games | Cask Strength Metal | DXMT, Full Proof | DirectX 11 games that hate DXVK | Orchard Reserve | D3DMetal, GPTK | DirectX 11 and 12 through Apple's toolkit | Small Batch '10 | Native DXGI | Legacy DirectX 10 titles | Single Malt | DXVK, Neat | Non Steam and installer based games | Blended Toolworks | CrossOver, 32 bit | Fragile 32 bit Windows tools ## Why the weird ones exist Most games land on Old Reliable or Homegrown. The interesting ones are the rest. **Homegrown** saves the most time of any of them. If a game has a Mac build, running it through Wine is just worse, so Smart Play routes it to the real macOS Steam client instead. Our compatibility database currently lists over 24,000 titles where that applies. **Blended Toolworks** exists because Wine Staging and CrossOver source Wine are good at different things. Fragile 32 bit Windows tools, and the Neverwinter Nights Aurora Toolset is the classic example, behave way better on the CrossOver build in its own prefix. Bourbon installs both runtimes during setup exactly so this bottle can exist. **Heritage Reserve** catches the games modern renderers handle badly. Source engine titles and older DirectX 9 games often want WineD3D, which looks slower on paper and is simply more reliable in practice. ## Overriding it Smart Play's pick is a default, not a verdict. Every game's settings let you pour a different bottle, and titles with a Steam listed Mac build keep a one click Wine fallback in case the native version has some problem the Windows one doesn't. ![Bourbon 26 library with Smart Play badges](https://pyrosoft.pro/assets/images/bourbon26/games.jpg) Every game shows the bottle it got, with the runtime name under the title in the list. ### Why it matters Per game configuration is the part of Mac gaming that eats weekends, and no other tool on the Mac does it for you. CrossOver gives you bottles to configure yourself. Whisky gave you one and stopped being maintained. Bourbon ships nine tested presets and assigns them automatically, which is the difference between a library that launches and a project. [Buy Bourbon 26, $29.99]() [Browse bottles by game]() --- # AIL eAPP on Mac > How to run the AIL eAPP on macOS with Bourbon 26, step by step. Canonical page: https://pyrosoft.pro/blog/ail-eapp-on-mac Published: 2026-07-26 If you write life and supplemental health business for [American Income Life]() (Globe Life Inc.), eAPP isn't optional. It's how applications get transmitted. It's also Windows only with no Mac build, which is why plenty of Mac based agents end up buying a cheap Windows laptop just to file business. It does run on a Mac, and Bourbon 26 ships the working configuration as a couple of clicks. It's worth seeing why the obvious approaches fall over first, because that's exactly the afternoon Bourbon saves you. **The setup that works:** CrossOver source Wine, plus Wine Mono, plus the WineD3D renderer, installed from the MSI. Confirmed reaching the Electronic Application Processing Program splash with Transmit Applications and Update Software both available. ## What doesn't work Save yourself the attempts. All three of these got tested and all three failed. - **Wine Staging.** Hangs, or throws .NET initialization errors. It's also the default runtime in most Wine wrappers, which is exactly why eAPP has a reputation for not working on Mac. - **DXVK or D3DMetal as the renderer.** Both are flagged known bad for this app. eAPP is a forms client, not a 3D game. Pointing a DirectX to Vulkan translator at it adds failure modes and gains you nothing. - **Copying `eAPP.exe` over on its own.** Most common mistake by far. The bare executable, or `EappMain.exe` pulled out of a Downloads folder, fails on missing `Ail.dll` and `Ail.Eapp.Messenger`. eAPP is a .NET app with a dependency tree, and only the MSI puts that tree down properly. ## What does work Three things have to be true at the same time. - **CrossOver source Wine** as the runtime, in its own prefix, not the Wine Staging build you'd use for games. - **Wine Mono** installed, because eAPP is .NET. - **Installed from `eAppSetupAIL.msi`**, so `eAPP.exe`, `Ail.dll` and everything else land together. Get all three right and it reaches the splash screen and transmits normally. Get any one wrong and it fails in a way that looks like Wine being broken. ## The quick route Bourbon 26 ships this setup as a recipe so you don't have to build it. The MSI is bundled too, so there's nothing to go hunting for. - Install Bourbon 26 and run **Set Up Everything** once. That installs both Wine runtimes including the CrossOver source build eAPP needs. - Open the **Windows Apps** tab. - Find **AIL eAPP**, it has a Recommended badge, and install it. - Launch it from Smart Play, where it shows up as **AIL eAPP Main**. Bourbon drops it into a dedicated `prefixes/ail-eapp` prefix with WineD3D selected and Wine Mono present, then watches for the `eAPP.exe` process and the `eApp` window to confirm it came up. After first launch the client self updates the same way it does on Windows. ![Bourbon 26 Windows Apps tab](https://pyrosoft.pro/assets/images/bourbon26/windows-apps.jpg) The Windows Apps tab, where the AIL eAPP recipe sits with the other curated installs. ## Why not just use CrossOver? Reasonable question, since eAPP wants the CrossOver source Wine build. CrossOver will run it, but you're doing the setup yourself: creating the bottle, adding Wine Mono, selecting WineD3D, and finding the MSI. That's $74 a year for the runtime without the recipe. Bourbon ships the tested configuration and bundles the MSI, so the whole thing is a couple of clicks, for $29.99 once. Parallels would also run eAPP, but you're buying a Windows license and running a full virtual machine to open a forms application. One thing worth being careful about. eAPP handles client personal and health information, so your usual obligations follow you onto the Mac. Full disk encryption, locked screen, and whatever your agency says about where client data can live. Running it through Bourbon doesn't change your compliance position either way, so check your setup with your agency before you file real business on it. ### Bottom line eAPP is a great candidate for a translation layer. It's a forms client, not a 3D app, and there's no Mac build competing with it. The only reason it's got a reputation for not working is that the default Wine setup is the wrong one. Bourbon 26 ships the right one. [Buy Bourbon 26, $29.99]() --- # Run .exe files on Mac > How to open and run Windows .exe and .msi files on macOS — safely, in their own bottle. Canonical page: https://pyrosoft.pro/blog/run-exe-on-mac Published: 2026-07-26 **A Mac can't run a Windows .exe by itself** — but with a translation layer it can, often at full speed. Here's the safe way to do it. You've downloaded a Windows program and macOS is showing it as a document it can't open. That's because a `.exe` is a Windows executable and a `.msi` is a Windows installer package, and neither means anything to macOS by itself. What you need is a Windows compatibility environment to open it inside, and on an Apple Silicon Mac that's Bourbon 26. ## The direct way With Bourbon 26 installed, a Windows file has two routes. - **Windows Apps tab.** Open Bourbon, go to Windows Apps, point it at the file. - **Finder.** Right click the `.exe` or `.msi` and choose **Open With, then Bourbon**. macOS remembers it after that. Installers run inside a Wine prefix and put things where they expect them. Once it's installed, the program shows up in Bourbon's app list and launches from there. Always prefer the installer over the loose executable. Copying a bare `.exe` across without running its `.msi` is the number one cause of "it just doesn't work". The program's missing the DLLs the installer would have put next to it. ## Which programs are worth trying **Good candidates.** Self contained desktop utilities, older business software, forms based line of business clients, portable tools. Small, offline, no license server, no kernel driver. **Bad candidates.** Anything with hardware locked licensing, heavy GPU needs, or a dependency on real Windows services. Big licensed CAD and accounting packages belong in a virtual machine, and we say so in the app rather than letting you find out the slow way. ## The shortcut Bourbon ships a catalog of Windows apps it can install straight from each project's official source, so there's no download hunting. It's got Notepad++, PuTTY, WinSCP, WinMerge, SumatraPDF, IrfanView, ImageGlass, ShareX, Greenshot, Everything, WinDirStat and BleachBit, plus specialist entries like the AIL eAPP insurance client. The catalog is deliberately Windows only. Anything with a real Mac build gets left out, because installing the Mac version is always the better move. ![Bourbon 26 Windows Apps catalog](https://pyrosoft.pro/assets/images/bourbon26/windows-apps.jpg) Curated installs pull from each project's official source, not a mirror. ## What about the alternatives? CrossOver handles standalone Windows apps well and has a bigger tested database for productivity software, but it's $74 a year and it won't set Steam up alongside them. Parallels runs anything at all, at $99.99 a year plus a Windows license, with a full virtual machine booting in the background just to open a small utility. Bourbon sits in between at $29.99 once. Finder integration, a curated catalog that already knows which programs are worth attempting, and the same install handling your Steam library and your streaming. ### Short version Right click, Open With, done, assuming the program is the self contained kind. Heavy licensed software still wants a VM, but for everything else Bourbon is the cheapest way to get there and it covers your games in the same app. [Buy Bourbon 26, $29.99]() --- # Notepad++ on Mac > Notepad++, PuTTY, WinSCP and the small Windows utilities worth keeping on your Mac — and the native swaps worth taking instead. Canonical page: https://pyrosoft.pro/blog/notepad-plus-plus-on-mac Published: 2026-07-26 **Notepad++ has no Mac build** — but it runs beautifully through a translation layer, and so do most of the small Windows tools people miss. When to translate, and when a native swap is honestly better: Most people buy Bourbon for the games. They stick around for a much more boring reason: three or four small Windows utilities they've used for fifteen years and have never found a Mac replacement they actually like. These are good candidates. Small, self contained, no GPU needed, no phoning home to a license server. ## The ones that work well Bourbon ships a curated catalog that installs these from their official sources. The ones marked Recommended, meaning they install and launch cleanly: - [Notepad++](), the editor people actually miss on macOS. Installer UI shows up as expected, just accept the defaults. - [PuTTY](), small MSI installer. Network behavior can vary under Wine so test your own connections. - [WinMerge](), lightweight diff tool and a good first thing to try if you just want to confirm your setup works. - [SumatraPDF](), small native installer, solid document viewer smoke test. - [ImageGlass](), lightweight image viewer. File associations might need setting up by hand. - [WinDirStat](), disk usage visualizer. - [BleachBit](), cleanup utility. Read those last two carefully. BleachBit and WinDirStat only see inside the Wine prefix. They're not Mac system cleaners and they can't touch your real disk. That's a safety feature, not a bug, but it does make them less useful here than on Windows. ## The ones to test first These install fine, but their whole job involves talking to the outside world, which is where Wine gets less predictable. - [WinSCP](), file transfer. Network tools vary with Wine's networking, so check it against your actual servers. - [ShareX]() and [Greenshot](), screen capture. Global hotkeys and system wide hooks are exactly the kind of thing that doesn't cross the boundary cleanly. Test before you rely on them. - [Everything](), whose search index only covers the Wine prefix, and the NTFS service behavior it depends on isn't native here. ## The honest caveat For several of these, macOS already has a great native equivalent, and a native app beats a translated one every single time. Bourbon's catalog policy is blunt about it: anything with a real Mac build gets removed from the list entirely, because running a Mac app through Wine is just worse than installing the Mac version. So this isn't "run all your Windows utilities on a Mac". It's that for the specific tools where the Windows version is the one you want and no Mac build exists, Bourbon installs them in a couple of clicks and keeps them working. ![Bourbon 26 Windows Apps catalog](https://pyrosoft.pro/assets/images/bourbon26/windows-apps.jpg) Curated installs pull from each project's official source. ### Bottom line This is often the thing that finally gets the PC off your desk. Bourbon installs these from their official sources with no hunting, and the same $29.99 covers your Steam library and your streaming too. CrossOver would run them as well, at $74 every year and without the games side. [Buy Bourbon 26, $29.99]() --- # Whisky alternative > Whisky is no longer maintained. What that means for your bottles, and the closest like-for-like replacement on macOS. Canonical page: https://pyrosoft.pro/blog/whisky-alternative Published: 2026-07-26 **Looking for a Whisky alternative?** Whisky's developer ended active work on it, and its Game Porting Toolkit foundation keeps moving without it. Here's what still works, what breaks over time, and how to move your bottles somewhere maintained. Whisky earned its reputation. Free, clean SwiftUI front end over Wine, and it made a genuinely miserable setup process feel approachable. For a lot of people it was the first Windows game they ever got running on a Mac. It's not maintained anymore. That's the whole problem, it's bigger than it sounds, and it's the reason Bourbon 26 exists as the picked-up torch. ## Why unmaintained matters more here An unmaintained text editor is fine for years. An unmaintained Wine wrapper isn't, because everything underneath it keeps moving. - **macOS ships a new major version every year** and regularly changes things Wine depends on. - **Steam updates its client constantly.** The current one has CEF rendering behavior that needs an active workaround under Wine, which is why Bourbon ships a UI shim. That shim exists because the problem appeared after Whisky stopped. - **Wine, DXVK, MoltenVK and VKD3D all release constantly.** Somebody has to keep track of which combination currently works. None of that happens on a dead project. Your games don't break the day development stops. They break slowly, and nobody fixes them. ## What Bourbon does that Whisky didn't Being maintained is the headline, but there are real feature gaps too. | | Whisky | Bourbon 26 | Price | Free | $29.99 once | Maintained | No | Yes | Installs Steam for you | No | Yes | Steam UI shim | No | Yes | Second Wine runtime for 32 bit tools | No | Yes | Per game runtime presets | Manual | Smart Play, automatic | Console and PC streaming built in | No | Chiaki and Moonlight | Routes native Mac games to Mac Steam | No | Yes The one that changes day to day life most is Steam. Whisky gave you a bottle and getting Steam working inside it was your problem. Bourbon installs Steam as one of its fourteen components along with the shim that keeps its interface rendering right. Second is the dual runtime design. Bourbon installs Wine Staging 11 for games and a CrossOver source build in a separate prefix for fragile 32 bit Windows tools. Those two jobs want different runtimes and one bottle can't do both well. ![Bourbon 26 games library with Smart Play](https://pyrosoft.pro/assets/images/bourbon26/games.jpg) Smart Play gives each title a runtime preset so you're not tuning prefixes per game. ## Being fair to Whisky Whisky was free and Bourbon isn't. If your needs are narrow, say one or two older games on a setup that already works and no interest in Steam, then a working Whisky install is a working Whisky install and nobody should talk you out of it while it lasts. What you're buying with Bourbon is somebody still doing the work. Tracking Wine and Steam changes, maintaining compatibility recipes, shipping fixes when macOS moves. That's the part that stopped when Whisky did, and it's worth $29.99 to most people who'd rather play than debug. ### Bottom line Whisky was good and it's finished. Bourbon 26 picks up where it left off and goes further: Steam installed for you, five renderers instead of one, a second runtime for awkward 32 bit software, native Mac games routed properly, and streaming for the titles Wine can't touch. One payment, no renewals, and somebody still maintaining it. [Buy Bourbon 26, $29.99]() [Check your games]() --- # CrossOver alternative > CrossOver charges yearly; Bourbon 26 is $29.99 once. Where CodeWeavers still earns its price, and where the alternative wins. Canonical page: https://pyrosoft.pro/blog/crossover-alternative Published: 2026-07-26 **Weighing a CrossOver alternative?** CrossOver is excellent, mature software with a subscription-shaped price. This is the honest comparison — including the cases where we'd still tell you to buy CrossOver. Credit where it's due first. CodeWeavers has employed Wine developers for over two decades and pushes their work upstream. If you've ever run a Windows app on Linux or a Mac, you've benefited from CrossOver whether you paid for it or not. Bourbon uses CrossOver source Wine itself, open source builds via cxbuilder, as its second runtime for fragile 32 bit tools. So this isn't a comparison where we pretend the other product is bad. ## The pricing difference CrossOver is $74 a year, or $494 for a lifetime license. Bourbon 26 is $29.99 once. That's the headline, and for most individuals it's the deciding factor. Here's the nuance though. A CrossOver subscription buys a year of updates, and their support is real. You can file a bug about a specific application and an actual human who works on Wine might look at it. If your livelihood depends on one Windows app behaving, that's worth money. | | CrossOver | Bourbon 26 | Price | $74/yr, $494 lifetime | $29.99 once | Renewals | Yearly for updates | None | Platforms | macOS, Linux, ChromeOS | macOS on Apple Silicon | Installs Steam for you | No | Yes | Commercial support | Yes | Discord community | Console and PC streaming | No | Chiaki and Moonlight | Routes native Mac games to Mac Steam | No | Yes | Upstream Wine contribution | Substantial | Uses it Pricing checked June 2026 at codeweavers.com. ## The scope difference CrossOver is a general purpose Windows compatibility product across three operating systems, with a big tested application database covering productivity software and commercial support behind it. Bourbon is narrower on purpose. Apple Silicon Macs, gaming as the center of gravity. That focus buys things a general tool doesn't do, like Steam installed and shimmed during setup, per game runtime presets, a games compatibility database, and console and PC streaming through Chiaki and Moonlight in the same app. It also means Bourbon does less. No Linux version, no support contract, no staff engineer to escalate your specific app to. ## Which one should you buy **Go CrossOver if** you're running Linux or ChromeOS as well as a Mac, or you need a support contract with a name on it. Those are real reasons and we won't pretend otherwise. **Go Bourbon 26 if** you're on an Apple Silicon Mac. Same Wine foundation underneath, plus Steam installed and shimmed for you, five renderers assigned per game, native Mac titles routed to the real Mac Steam client, and streaming built in for anything translation can't touch. CrossOver does the translation part and stops. One payment against $74 every year. ### Bottom line CrossOver is broader across operating systems and comes with paid support. On a Mac, though, Bourbon covers more of what you'll actually hit: translated games, native Mac games and streamed games, all in one app, for $29.99 once instead of $74 a year. Unless you need Linux or a support contract, it's the easier answer. [Buy Bourbon 26, $29.99]() --- # Parallels alternative > Parallels runs a whole Windows; Bourbon 26 runs just your games. Which approach fits, and when a full VM is genuinely the right call. Canonical page: https://pyrosoft.pro/blog/parallels-alternative Published: 2026-07-26 Some links to other products on this page are affiliate links, and we may earn a commission if you buy through them. It costs you nothing extra, and it has not changed what this article says — where a competitor is the better answer, we say so. **A Parallels alternative depends on what you need Windows for.** For office apps and drivers, a VM earns its subscription. For games, translation is lighter, faster and cheaper. Here's the split. Comparing Bourbon to Parallels is a bit like comparing a translator to an embassy. One converts what your app is saying into something macOS gets. The other hands you actual sovereign Windows territory on your Mac. Both are valid. They cost wildly different amounts and they fail in completely different ways. ## What Parallels does that Bourbon can't Parallels runs a real Windows 11 ARM install, which means: - **Compatibility stops being a question.** If the app runs on Windows on ARM, it runs. No recipes, no renderer picking, no verified badges. - **Licensed professional software works.** Office with Click to Run licensing, QuickBooks Desktop, Power BI, SQL Server tooling. Exactly the apps translation layers struggle with, and we mark them as VM territory in Bourbon's own catalog rather than pretending otherwise. - **Windows services are real**, because Windows is real. If your job depends on a specific licensed Windows application, that's your answer. [Buy Parallels](). ## What it costs Parallels Desktop is $99.99 a year and doesn't include Windows, so you need a license for that too. Real first year number is the subscription plus a Windows license, then the subscription again every year after. | | Parallels Desktop | Bourbon 26 | Price | $99.99/yr | $29.99 once | Windows license needed | Yes, extra | No | Approach | Full Windows 11 ARM VM | Translation layer | Disk footprint | Tens of GB for the guest | Wine prefixes only | Licensed business software | Works | Often doesn't | Gaming performance | No GPU passthrough | Direct Metal translation | Kernel anti-cheat games | No | Not locally, but streams them | Cloud and console streaming built in | No | Yes | Native Mac games handled | No | Yes, routed to Mac Steam Pricing checked June 2026 at parallels.com. ## Where Bourbon wins **Games.** A VM has no GPU passthrough on Apple Silicon, so the guest gets a virtual display adapter instead of your M series GPU. Translation layers hand DirectX calls to Metal on the real hardware. For gaming this isn't a close call. **Cost and weight.** No Windows license, no huge guest disk image, no VM to boot before you can launch anything. **One payment.** $29.99 once against $99.99 every year. Neither one runs kernel anti-cheat locally. BattlEye, Easy Anti-Cheat and Riot Vanguard don't work in a Mac VM either, because the anti-cheat can tell it's virtualized. The difference is Bourbon streams those games for you from the same app, and Parallels has nothing to offer there. ## Which to buy **[Parallels]()** if a licensed Windows business app is non negotiable, or you need a full Windows desktop. **Bourbon 26** if you want your Steam library and some Windows utilities running on Metal without a Windows license or an annual bill. **Both** is a genuinely good answer for some people. They're not mutually exclusive, and since Bourbon is a one off $29.99, adding it to a Parallels subscription costs less in year two than Parallels alone did in year one, with games running properly on Metal instead of through a virtual display adapter. ### Bottom line Different tools. Parallels buys correctness for licensed software at a recurring price. Bourbon buys speed and simplicity for games and utilities at a one off one. Pick based on what you actually need to run, and if it's a game, the VM was never going to be the answer. [Buy Bourbon 26, $29.99]() [Check your games]() --- # Game Porting Toolkit > What Apple's Game Porting Toolkit is, who it's actually for, and how Bourbon 26 packages the same technology for people who just want to play. Canonical page: https://pyrosoft.pro/blog/game-porting-toolkit Published: 2026-07-26 **Game Porting Toolkit is Apple's translation technology for running Windows games on Apple Silicon** — built for developers evaluating ports, not for players. Here's what it does, and how to use its power without the Terminal. Apple's Game Porting Toolkit does something pretty remarkable. D3DMetal translates DirectX 11 and 12 calls straight to Metal without going through Vulkan first. Fewer layers, less overhead. For some games it's the fastest path available on a Mac. It's also not a consumer product, and Apple has never claimed it was. That gap between the technology and the player is exactly where Bourbon 26 sits. ## What GPTK actually is GPTK exists so studios can evaluate how much work porting their game to macOS would be. It's an evaluation environment. Using it means Terminal commands, Homebrew, and building a Wine prefix by hand. No interface, no library, no per game configuration, no support when a title misbehaves, because you're not who it's for. Bourbon doesn't compete with GPTK. It installs it. Game Porting Toolkit 3 is step nine of Bourbon's fourteen step setup, and D3DMetal is available as a per game renderer on the Bottle Shelf. ## Bourbon installs it for you That's the honest framing here. GPTK is a component, not a rival. Bourbon tracks the `gcenx/wine/game-porting-toolkit` Homebrew cask, installs it during setup, and gives it its own update action so it can be refreshed without touching anything else. It handles the newer beta too. Apple's GPTK 4 evaluation environment ships its payload inside a nested disk image, and Bourbon can open Apple's download page and import that DMG for you. It stays marked experimental, because Apple expects newer beta tooling for the full Metal 4 workflow and GPTK 3 is still the supported default. | | GPTK on its own | Bourbon 26 | Price | Free | $29.99 once | Terminal required | Yes | No | Installs Steam | No | Yes | D3DMetal available | Yes | Yes, it installs GPTK | Other renderers | D3DMetal only | DXVK, VKD3D, DXMT, WineD3D | Per game presets | No | Smart Play | Who it's for | Game developers | Players ## Why more than one renderer matters D3DMetal is excellent for some games and wrong for others. Real examples from Bourbon's own recipe data: the AIL eAPP business client flags D3DMetal and DXVK as known bad and needs WineD3D instead. Source engine and older DirectX 9 games often want WineD3D too. Modern DirectX 12 titles frequently do better on VKD3D. A GPTK only setup has one answer for every question. Bourbon's Bottle Shelf keeps five and Smart Play picks between them per title. ![Bourbon 26 advanced component controls](https://pyrosoft.pro/assets/images/bourbon26/advanced.jpg) Every component including GPTK gets its own install, repair, update and remove controls. ## So why not just use GPTK? Because it isn't a way to play games, it's a way to test them. There's no library, no Steam, no per game configuration, and only one renderer, so every title that doesn't suit D3DMetal has no fallback. Bourbon includes GPTK and adds the other four renderers, Steam, Smart Play, and Remote Play for anything that can't be translated at all. Same Apple technology underneath, with the parts a player actually needs built around it. ### Bottom line Not a rivalry. GPTK is one of the graphics paths Bourbon installs and manages alongside DXVK, VKD3D, DXMT and WineD3D. Use GPTK directly if the Terminal is where you're happiest. Buy Bourbon if you'd rather it were already set up. [Buy Bourbon 26, $29.99]() --- # Windows on Apple Silicon > Every way to run Windows software on an M-series Mac in 2026 — translation, emulation, VMs — and how to pick per app. Canonical page: https://pyrosoft.pro/blog/windows-on-apple-silicon Published: 2026-07-26 Some links to other products on this page are affiliate links, and we may earn a commission if you buy through them. It costs you nothing extra, and it has not changed what this article says — where a competitor is the better answer, we say so. **Apple Silicon runs Windows software four ways:** translation, a VM, emulation, or streaming. Nobody needs all four — here's how to pick per app. Apple Silicon broke the old answer. Boot Camp's gone, x86 virtualization is gone, and the tidy advice people gave in 2019 doesn't apply anymore. What replaced it is a set of overlapping tools that solve different problems, plus a lot of confident internet advice that ignores the differences. Here's the version that includes where Bourbon 26, our own app, is the wrong choice. Spoiler: that list is short. ## The four approaches ### 1. Translation layers, which is what Bourbon 26 is Wine isn't an emulator. It rebuilds the Windows API so a Windows binary calls into macOS instead. On Apple Silicon there's a second translation on top, since DirectX calls have to become Metal calls, either through Vulkan (DXVK, VKD3D, MoltenVK) or directly (DXMT, D3DMetal). Bourbon installs every one of those and picks between them per game. **Good at:** single player games, self contained desktop utilities, older business apps. **Bad at:** anything with kernel drivers, aggressive DRM, or a dependency on a real Windows service. ### 2. Full virtualization Run an actual Windows 11 ARM install in a VM. Everything Windows expects is there, because it really is Windows. **Good at:** licensed professional software, anything needing real Windows services, correctness. **Bad at:** cost, since you need a Windows license on top of the VM software, and GPU bound work, because there's no GPU passthrough. ### 3. Cloud and remote streaming, also built into Bourbon Don't run it locally at all. Stream it from someone else's hardware, or from a PC you already own. Bourbon has Xbox Cloud, GeForce NOW, Luna and Boosteroid in native windows, plus Chiaki and Moonlight, so this isn't a separate tool you go and find. **Good at:** demanding games, anti-cheat titles that will never work under translation. **Bad at:** latency, offline use, and anything that isn't a game. ### 4. The Mac version, which Bourbon finds for you The one people skip. A surprising number of "Windows" apps have a real macOS build, and a native build wins every time. Bourbon routes games with a Mac build straight to the Mac Steam client, and deliberately keeps anything with a Mac version out of its software catalog, because running a Mac app through Wine is just worse than installing the Mac app. Always check for a native macOS build first. Bourbon does this automatically for games, routing anything with a Mac version straight to the real Mac Steam client instead of translating it. ## What each one costs | Tool | Approach | Cost | Still maintained | Bourbon 26 | Translation, managed | $29.99 once | Yes | Whisky | Translation, managed | Free | Discontinued | Apple GPTK | Translation, manual | Free | Yes, as a dev tool | CrossOver | Translation, managed | $74/yr or $494 lifetime | Yes | Parallels Desktop | Full VM | $99.99/yr plus Windows license | Yes | GeForce NOW / Xbox Cloud | Streaming | Subscription | Yes Competitor pricing checked June 2026 at codeweavers.com and parallels.com. Worth re-checking before quoting. ## Where translation actually falls over This is the part most comparison articles skip. No Wine based tool on macOS, ours included, can run: - **Kernel level anti-cheat.** BattlEye, Easy Anti-Cheat and Riot Vanguard load Windows kernel drivers. macOS can't load Windows kernel drivers. Nobody can fix this. - **Software needing a real Windows service stack.** Office Click to Run licensing, SQL Server tooling, anything doing hardware level activation. - **Heavy licensed CAD and GIS.** SOLIDWORKS, ArcGIS Pro, Revit. These want a GPU, a license server and real Windows. A VM is the right answer and we say so in the app itself. If someone tells you their Wine wrapper runs Valorant or Fortnite on a Mac, they're wrong or they're talking about cloud streaming. Worth checking which. ## So which should you pick? **A Steam library you already own:** Bourbon 26. It installs the whole stack including Steam in one pass, then handles native, translated and streamed games from the same window. **One specific business app your job depends on:** check whether Bourbon has a verified recipe for it. If it does, you're done in a couple of clicks. If it doesn't and it's one of the heavy licensed packages below, budget for a VM instead of losing a week to it. **Licensed professional software:** [Parallels]() plus a Windows license. It costs more because it does more. **Competitive multiplayer:** streaming, which Bourbon has built in. Nothing local is going to work, for anyone. ### Where Bourbon 26 fits Buy once, no subscription, and it sets up the entire stack in one guided pass: both Wine runtimes, every graphics translation layer, Steam and its UI shim. Anti-cheat still won't run locally for anyone, but Bourbon streams those instead and routes your native Mac games to the real Steam client. Three routes, one app, $29.99. [Buy Bourbon 26, $29.99]() [Look your game up first]() --- # What Wine can't run > Drivers, kernel services, anti-cheat and the other Windows software no translation layer can handle — where a VM is the honest answer. Canonical page: https://pyrosoft.pro/blog/what-wine-cant-run Published: 2026-07-26 Some links to other products on this page are affiliate links, and we may earn a commission if you buy through them. It costs you nothing extra, and it has not changed what this article says — where a competitor is the better answer, we say so. **Wine has hard limits.** Anything that needs a real Windows kernel — drivers, services, kernel anti-cheat — is out of reach for every translation layer, ours included. Here's the list and the honest workaround. It would be really convenient to claim Bourbon runs everything. It doesn't, and the app says so in its own interface. Over half the entries in its curated catalog are marked not installable, each with a note explaining what they need instead. Here's that list and the reasoning, so you can decide before spending money rather than after. ## Heavy licensed CAD and engineering **SOLIDWORKS, Autodesk Revit, Autodesk AutoCAD, Altium Designer, 2020 Design Live.** These all share a profile that's hostile to translation. Account gated installer, a license check that wants to see real hardware, a GPU bound rendering pipeline, and a support contract that assumes Windows. Bourbon marks SOLIDWORKS as needing a Windows VM, GPU and licensing validation, and doesn't offer to install it. Run these in [Parallels]() with a real Windows license, or on an actual workstation. ## GIS and data platforms **ArcGIS Pro, Power BI Desktop, SQL Server Management Studio.** ArcGIS Pro combines GPU requirements, a bundled Python environment, licensing and an extension system, which is four separate ways for a translation layer to fall over. Power BI needs WebView and .NET and validates monthly. SSMS drags in Visual Studio shell dependencies. ## Accounting and practice software **QuickBooks Desktop, Quicken Classic, PCLaw.** Licensing, update flows, PDF generation and payroll modules all want real Windows. There's a second reason to be careful here that has nothing to do with technology: this is your financial data, and "mostly works" isn't a standard you should accept for your books. ## Microsoft Office family **Access, Project, Visio.** Office Click to Run isn't a simple Wine install. Subscription licensing plus the Office dependency chain makes these manual targets at best. Worth noting that Word, Excel, PowerPoint and Outlook all have proper Mac versions, so use those. Access, Project and Visio are the three without a Mac build, which is exactly why they keep coming up. ## Clinical and safety critical **RadiAnt DICOM Viewer.** Bourbon's own note is the right one here. Clinical use demands validation and it isn't presented as guaranteed. Don't make diagnostic decisions on software running through a translation layer nobody has validated for that purpose. The pattern across all of these: license enforcement, GPU dependence, real Windows services, or consequences when it quietly misbehaves. Any one is a warning sign, two or more means a VM. Everything outside that list, which is most software and nearly all games, is Bourbon territory. ## What that leaves Plenty, actually. Games are the big one, since a game mostly wants a GPU and a graphics API and both of those translate well. So do self contained desktop utilities, and line of business clients that are really just forms over a network, like the [AIL eAPP client](). The dividing line isn't big app versus small app. It's how much the software depends on being on real Windows rather than just on the Windows API. ### Bottom line Check your specific app before buying anything, ours included. If it's on the list above, budget for Parallels and a Windows license. That's the right tool and we'd rather you got it working than bought the wrong thing from us. If it's a game or a self contained utility though, you're exactly in the territory Bourbon 26 was built for, and $29.99 will probably be the end of the problem. [Buy Bourbon 26, $29.99]() [Search the compatibility list]() --- # Software by PyroSoft ## Available and early access - [Bourbon 26](https://pyrosoft.pro/software/bourbon-26.md) — Play Windows games on Mac, plus Steam and Android apps, on Apple Silicon. ($29.99) - [Virtual Drivers for macOS](https://pyrosoft.pro/software/virtual-drivers-macos.md) — Seven virtual-device tools. One Mac app. ($14.99) - [InfinitePIP](https://pyrosoft.pro/software/infinitepip.md) — Keep any screen, window or region in view, always on top. ($4.99) - [FreeSpark](https://pyrosoft.pro/software/freespark.md) — Free AI that runs on your own device. (Free) - [Battle Bot Arena Engine](https://pyrosoft.pro/software/battle-bot-arena-engine.md) — Unity 6 (URP) template for robot-combat and arena-brawler games. ($99.99) - [Display Preview App](https://pyrosoft.pro/software/display-preview-app.md) — View your virtual displays in application windows. ($2.50) - [Bourbon-OSS](https://pyrosoft.pro/software/bourbon-oss.md) — What Bourbon learned, in the open. (Free) - [BurnBin](https://pyrosoft.pro/software/burnbin.md) — Share a file. Get a link. Let it burn away. (Free) - [FriendlyIP](https://pyrosoft.pro/software/friendlyip.md) — Turn IPv4 addresses into six-character codes you can read aloud. (Free) - [Linux Virtual Display Driver](https://pyrosoft.pro/software/linux-virtual-display-driver.md) — Add a monitor that isn't there. (Free) - [Pixoo 64 Tools](https://pyrosoft.pro/software/pixoo-64-tools.md) — Python scripts for the Divoom Pixoo 64 LED display. (Free) - [Polygone](https://pyrosoft.pro/software/polygone.md) — A low-poly zombie-horde FPS: hold off endless waves solo or in co-op. ($9.99) - [PSN Account ID Finder](https://pyrosoft.pro/software/psn-account-id-finder.md) — Find your PSN Account ID. (Free) - [PyroSoft Model Archive](https://pyrosoft.pro/software/model-archive.md) — AI models. By torrent. (Free) - [Rite of Eris](https://pyrosoft.pro/software/rite-of-eris.md) — Free-to-play 3D survival roguelike: pick a hero and survive the waves. (Free) - [Steam Command Generator](https://pyrosoft.pro/software/steam-command-generator.md) — Generate Steam commands instantly. (Free) - [StreamSavers](https://pyrosoft.pro/software/streamsavers.md) — A desktop-overlay idle RPG where Twitch chat unleashes chaos. ($9.99) - [UE5 Action Adventure](https://pyrosoft.pro/software/ue5-action-adventure-course.md) — Create your own 3rd Person action adventure game with Blueprints and Unreal 5's features! (On GameDev.tv) - [Virtual Audio Driver](https://pyrosoft.pro/software/virtual-audio-driver.md) — Add a virtual speaker and virtual microphone to your Windows device. (Free) - [Virtual Display Driver](https://pyrosoft.pro/software/virtual-display-driver.md) — Add virtual monitors to Windows 10/11 for VR, OBS, Sunshine and screen sharing. (Name your price) - [Virtual Driver Control](https://pyrosoft.pro/software/virtual-driver-control.md) — One app to control and configure VirtualDrivers tools. (Free) - [Virtual Driver Installer](https://pyrosoft.pro/software/virtual-driver-installer.md) — Inno Setup source for the Virtual Display Driver installer. (Free) - [VirtualBT](https://pyrosoft.pro/software/virtualbt.md) — A Windows-host Bluetooth server that simulates input devices. (Free) - [DevZIP](https://pyrosoft.pro/software/devzip.md) — A Windows-first archiver with a native C++ engine. (Free) ## Coming soon - [Bambi3D](https://pyrosoft.pro/software/bambi3d.md) — Print the things you care about. (Price TBA) - [BambiMaps](https://pyrosoft.pro/software/bambimaps.md) — Print the place you love. (Price TBA) - [Bourbon OS](https://pyrosoft.pro/software/bourbon-os.md) — Power on. Straight into Steam. (Coming to Bourbon 26) - [BurnFlix](https://pyrosoft.pro/software/burnflix.md) — Your whole media library, ready instantly. (Price TBA) - [EmberLink](https://pyrosoft.pro/software/emberlink.md) — One desk. Every computer. (Price TBA) - [Ferrum](https://pyrosoft.pro/software/ferrum.md) — Windows games on a Mac, without Rosetta. (Ships inside Bourbon 26) - [FireFetch](https://pyrosoft.pro/software/firefetch.md) — Download literally anything worth keeping. (Price TBA) - [Fuse](https://pyrosoft.pro/software/fuse.md) — See how much of each AI plan you have left, from your Mac's menu bar. (Price TBA) - [MagicGlass](https://pyrosoft.pro/software/magicglass.md) — Your Mac screen. Now touchable. (Price TBA) - [NotSoMysteryBox](https://pyrosoft.pro/software/notsomysterybox.md) — The mystery box that tells you what's inside. (Price TBA) ## Legacy reference - [AlisalTech - Kids](https://pyrosoft.pro/software/alisaltech-kids.md) — Educational games, activities and resources for home and class. - [Blue Box](https://pyrosoft.pro/software/blue-box.md) — Modern blue box tone generator. - [Box2D Space Shooter Source (GMS2)](https://pyrosoft.pro/software/box2d-space-shooter-source.md) — GameMaker Studio 2 template for a Box2D physics space shooter. - [CinemaVerse](https://pyrosoft.pro/software/cinemaverse.md) — Credit trails between any two movies, shows or people. - [Custom Bouncing Screensaver](https://pyrosoft.pro/software/custom-bouncing-screensaver.md) — Bounce your own image around the screen, DVD-logo style, in a browser. - [DRW Auto Loader](https://pyrosoft.pro/software/drw-auto-loader.md) — Classroom launcher for K-12 learning sites, built for Del Rey Woods. - [Educational Site Loader](https://pyrosoft.pro/software/educational-site-loader.md) — One-window launcher for popular K-12 learning websites. - [Fight for the Hood: The Game](https://pyrosoft.pro/software/fight-for-the-hood-game.md) — Urban zombie survival game based on the Fight for the Hood movie. - [Free 3D Dice Roller](https://pyrosoft.pro/software/free-3d-dice-roller.md) — 3D dice for tabletop games: D4 to D100 on a table they can't fall off. - [Guardians of Dale](https://pyrosoft.pro/software/guardians-of-dale.md) — A Notepad-made text adventure from a game-design lesson plan. - [Kinect Virtual Green Screen](https://pyrosoft.pro/software/kinect-virtual-green-screen.md) — Use a Kinect as a webcam, with your background swapped for green. - [LinuxWidgets](https://pyrosoft.pro/software/linuxwidgets.md) — Glassmorphism desktop widgets for Linux. - [MBARI Underwater Rover Simulation](https://pyrosoft.pro/software/mbari-underwater-rover.md) — An Unreal Engine underwater expedition with MBARI's Doc Ricketts ROV. - [MDEdit](https://pyrosoft.pro/software/mdedit.md) — A cross-platform WYSIWYG Markdown editor built with Electron. - [Paragon Tournament](https://pyrosoft.pro/software/paragon-tournament.md) — A Smash-style platform fighter prototype built with Paragon assets. - [Pixoo 64: Snake](https://pyrosoft.pro/software/pixoo-64-snake.md) — Classic Snake for the Pixoo 64 LED display. - [Python VDD Pipe Control](https://pyrosoft.pro/software/python-vdd-pipe-control.md) — A small window for sending commands to the VDD's named pipe. - [SalinasRadio.com](https://pyrosoft.pro/software/salinasradio.md) — Internet radio that promoted the Monterey Bay music scene. - [ScreenSaver XP](https://pyrosoft.pro/software/screensaver-xp.md) — A 3D Unreal Engine tribute to the Windows XP Bliss hill, day to night. - [Spotify for Pixoo 64](https://pyrosoft.pro/software/spotify-for-pixoo-64.md) — Display your current Spotify album artwork on your Pixoo 64 device. - [Tech Helper](https://pyrosoft.pro/software/tech-helper.md) — Technical support and troubleshooting utility for Windows systems. - [The Hacker's Toolkit](https://pyrosoft.pro/software/the-hackers-toolkit.md) — A hacking sim played across desktop apps that mimic real hacker tools. - [Video Tools](https://pyrosoft.pro/software/video-tools.md) — Remux MKV and convert almost any video to MP4. - [Virtual Studio (Unreal Engine 5)](https://pyrosoft.pro/software/virtual-studio-ue5.md) — A live 3D broadcast studio in Unreal Engine, wired into Twitch. - [WinDebbie](https://pyrosoft.pro/software/windebbie.md) — Windows desktop chatbot built on the A.L.I.C.E. AIML framework. - [Anarchist Calculator](https://pyrosoft.pro/software/anarchist-calculator.md) — Humorous Windows calculator remake with a calendar and memo pad. - [ChatGPT Completion Script](https://pyrosoft.pro/software/chatgpt-completion-script.md) — Script for adding ChatGPT completions to apps and workflows. - [Claude File Context](https://pyrosoft.pro/software/claude-file-context.md) — Open-source tool for managing file context with Claude. - [EDIDtvScraper](https://pyrosoft.pro/software/edidtvscraper.md) — Extracted and analysed EDID data from displays and TVs. - [GameSalad Top-Down Shooter Project Files](https://pyrosoft.pro/software/gamesalad-top-down-shooter-source.md) — Project files for Mike's 11-part GameSalad top-down shooter tutorial. - [HazMat Clock Screensavers](https://pyrosoft.pro/software/hazmat-clock-screensavers.md) — Custom clock screensavers made for the band HaZmAt. - [Integrity Messenger](https://pyrosoft.pro/software/integrity-messenger.md) — Instant messaging client with encryption and privacy features. - [LangChain Sample Templates for Replit](https://pyrosoft.pro/software/langchain-replit-templates.md) — ChatGPT and LangChain starter templates for Replit (GPT-3). - [LangChainCSV](https://pyrosoft.pro/software/langchaincsv.md) — CSV data analysis tool built on LangChain. - [LangChainDoc Processing](https://pyrosoft.pro/software/langchaindoc-processing.md) — LangChain utility for AI text analysis and extraction. - [Matrix Screensaver](https://pyrosoft.pro/software/matrix-screensaver.md) — Matrix-style digital rain screensaver with custom effects and colors. - [PHilliP](https://pyrosoft.pro/software/phillip-aiml.md) — PHP AIML chatbot that replied to forum posts from its own account. - [Pixoo-Paint](https://pyrosoft.pro/software/pixoo-paint.md) — A pixel-art drawing tool made for the Pixoo 64 LED display. - [Post Warz](https://pyrosoft.pro/software/post-warz.md) — A GameMaker side-scrolling platformer, released as a demo. - [Pyro's Air Ride](https://pyrosoft.pro/software/pyros-air-ride.md) — Top-down shooter set in 1942 with period aircraft. - [Pyro's Air Ride 2.1](https://pyrosoft.pro/software/pyros-air-ride-2-1.md) — Expanded 2004 upgrade of the top-down shooter Pyro's Air Ride 2. - [PyServe](https://pyrosoft.pro/software/pyserve.md) — Python web server framework with built-in development tools. - [QSuite Public SDK](https://pyrosoft.pro/software/qsuite-public-sdk.md) — Developer SDKs for quantum-safe cryptographic operations. - [Space Warz](https://pyrosoft.pro/software/space-warz.md) — An early PyroSoft space combat game. - [Space Warz 2](https://pyrosoft.pro/software/space-warz-2.md) — Sequel to PyroSoft's early space combat game Space Warz. - [Space Warz 3: HaZmAt Edition](https://pyrosoft.pro/software/space-warz-3.md) — Third Space Warz game, a custom edition for the band HaZmAt. - [SteamDeckDriversPack](https://pyrosoft.pro/software/steamdeck-drivers-pack.md) — Steam Deck Windows drivers, bundled in one download. - [Sunshine Script Builder](https://pyrosoft.pro/software/sunshine-script-builder.md) — Built Sunshine host scripts for your own game-streaming setup. - [Transite](https://pyrosoft.pro/software/transite.md) — A super-simple browser that makes any website transparent. - [Uplink Screensaver](https://pyrosoft.pro/software/uplink-screensaver.md) — Custom screensaver with network-connectivity themes. - [VoidChat](https://pyrosoft.pro/software/voidchat.md) — Modern rewrite of 2006's ajChat web chat. - [WinPick](https://pyrosoft.pro/software/winpick.md) — Unlock hidden Windows features. --- # PyroSoft blog and live journals - [Delivering the tested arena build without changing the server around it](https://pyrosoft.pro/blog/delivering-the-tested-arena-build-without-changing-the-server-around-it.md) — The exact public package, preserved rollback and a separate desktop browser check. - [Battle Bot Arena Engine 2.0 reaches the browser](https://pyrosoft.pro/blog/battle-bot-arena-engine-2-0-reaches-the-browser.md) — Workshop, Garage and combat behavior in the exact WebGL build. - [DZCM: a context-mixing codec of our own](https://pyrosoft.pro/blog/dzcm-a-context-mixing-codec-of-our-own.md) — A new experimental backend, with its strong and weak cases recorded. - [Compression levels and the cost of a smaller archive](https://pyrosoft.pro/blog/compression-levels-and-the-cost-of-a-smaller-archive.md) — Best-of-N selection and content-aware transforms in the June overhaul. - [DevZIP opens up its archive engine](https://pyrosoft.pro/blog/devzip-opens-up-its-archive-engine.md) — A native Windows engine, a readable container and a measured starting point. - [Route, gather, then write the answer once](https://pyrosoft.pro/blog/route-gather-then-write-the-answer-once.md) — A simpler pipeline and a more practical automatic model choice. - [Checking whether Spark actually helps the model](https://pyrosoft.pro/blog/checking-whether-spark-actually-helps-the-model.md) — A growing prompt suite, bare-model comparisons and fixes from real answers. - [Making local work survive the next conversation](https://pyrosoft.pro/blog/making-local-work-survive-the-next-conversation.md) — IndexedDB chats, workspace previews and a context budget. - [FreeSpark: useful AI on the hardware you already have](https://pyrosoft.pro/blog/freespark-useful-ai-on-the-hardware-you-already-have.md) — Local inference, clearer online boundaries and the first reliability pass. - [Connecting FriendlyIP to the rest of PyroSoft](https://pyrosoft.pro/blog/connecting-friendlyip-to-the-rest-of-pyrosoft.md) — Shared navigation without losing the local tool menu. - [FriendlyIP: an address you can read over the phone](https://pyrosoft.pro/blog/friendlyip-an-address-you-can-read-over-the-phone.md) — A documented snapshot of the IPv4 converter and its related tools. - [Preserving the whole PSN identifier](https://pyrosoft.pro/blog/preserving-the-whole-psn-identifier.md) — Correct large-integer conversion, request limits and clearer attribution. - [Finding the account ID a Remote Play client asks for](https://pyrosoft.pro/blog/finding-the-account-id-a-remote-play-client-asks-for.md) — The retained baseline for the PSN Account ID Finder. - [Steam Command Generator: useful commands with the right expectations](https://pyrosoft.pro/blog/steam-command-generator-useful-commands-with-the-right-expectations.md) — An App ID workflow, copy controls and a clear limit on guessed depot IDs. - [Moving Bourbon safely, then making the verification faster](https://pyrosoft.pro/blog/moving-bourbon-safely-then-making-the-verification-faster.md) — Qualified candidate work and a later storage improvement that still needs its own gate. - [The audit that put saves and reset safety first](https://pyrosoft.pro/blog/the-audit-that-put-saves-and-reset-safety-first.md) — Protecting newer environments before broadening the feature work. - [Native Steam integration and a library you can use from the couch](https://pyrosoft.pro/blog/native-steam-integration-and-a-library-you-can-use-from-the-couch.md) — A new bridge, bigger controls and more careful cloud-save setup. - [Keeping older tools and newer Steam clients in their own lanes](https://pyrosoft.pro/blog/keeping-older-tools-and-newer-steam-clients-in-their-own-lanes.md) — Targeted runtime work, safer repairs and evidence from the real client. - [Giving SteamOS its own place in Bourbon](https://pyrosoft.pro/blog/giving-steamos-its-own-place-in-bourbon.md) — A separate guest lifecycle and tighter launch observation. - [Activation, installers and knowing which program we launched](https://pyrosoft.pro/blog/activation-installers-and-knowing-which-program-we-launched.md) — Small recovery fixes followed by more careful Windows software analysis. - [Smart Play starts figuring out unfamiliar games](https://pyrosoft.pro/blog/smart-play-starts-figuring-out-unfamiliar-games.md) — Reading game files before choosing a runtime. - [Making setup and repair less disruptive](https://pyrosoft.pro/blog/making-setup-and-repair-less-disruptive.md) — Better readiness checks and more careful handling of active sessions. - [When the menus work but the game world is black](https://pyrosoft.pro/blog/when-the-menus-work-but-the-game-world-is-black.md) — Following the real game executable and isolating the graphics route. - [Bourbon 26: choosing the right way to play](https://pyrosoft.pro/blog/bourbon-26-choosing-the-right-way-to-play.md) — Native Mac games, per-game Wine choices and a more useful Bottle Shelf. - [Asynchronous I/O and the Bytes a Cancelled Write Keeps](https://pyrosoft.pro/blog/async-io-and-the-bytes-a-cancelled-write-keeps.md) — The latest verified candidate passes focused 64-bit read and write profiles on both pipe routes. The tests caught real EOF, completion-block, and cancellation-accounting mistakes. - [A Real Archive Roundtrip and Better File Behavior](https://pyrosoft.pro/blog/real-archive-roundtrip-and-file-behavior.md) — The original 7-Zip command-line tool created, tested, and extracted an archive, with all four files compared byte for byte. - [Making the Launcher Own Its Storage and Processes](https://pyrosoft.pro/blog/making-the-launcher-own-its-work.md) — Managed storage and an app-local process supervisor are part of turning a development engine into an application people can safely launch and stop. - [Getting Wine's Real 32-Bit Startup to Run](https://pyrosoft.pro/blog/getting-wines-real-32-bit-startup-to-run.md) — The ordinary Wine loader path needed real process, thread, locale, and shutdown state. A command prompt that prints and relaunches became a useful application milestone. - [Making Memory Protection and Lifetime Tests More Useful](https://pyrosoft.pro/blog/memory-protection-and-lifetime-tests.md) — The memory work checked more than successful allocation: page permissions, decommit, release, reuse, process-image data, and the bytes around each result. - [Recovering the Project and Resuming Real Tests](https://pyrosoft.pro/blog/recovering-the-project-and-resuming-real-tests.md) — The resumed work established the source baseline, exercised real NT/file behavior, and added bounded Intel Mac command-line evidence. - [Correcting the Ferrum Progress Report](https://pyrosoft.pro/blog/correcting-the-progress-report.md) — Some earlier 32-bit checks proved placeholder outputs rather than real NT behavior. The recovery work started by separating useful code from unsupported completion claims. - [Portal Reaches a Command Stream, With the Frame Still Ahead](https://pyrosoft.pro/blog/portal-reaches-a-command-stream.md) — More Vulkan commands and application imports were connected for Portal. The recorded run still did not establish an intro, menu, or visible game frame. - [A Launcher and a Freeze That Wasn't the Presenter](https://pyrosoft.pro/blog/a-launcher-and-a-freeze-that-wasnt-the-presenter.md) — The launcher made the project easier to approach. A separate graphics investigation showed why a changing frame counter wasn't enough to prove a changing picture. - [Working on Presentation and Controller Input](https://pyrosoft.pro/blog/windows-that-keep-up-and-controllers-that-wake.md) — Presentation timing and controller discovery needed tests outside a simple offscreen run. The Mac has its own window and input rules to account for. - [DirectX 12, Shader Caches, and the Steam Startup Work](https://pyrosoft.pro/blog/directx-12-shader-caches-and-steam.md) — The graphics feature work and Steam startup fixes advanced useful components. Neither a feature probe nor a running Steam process closed the application journey. - [Making Memory, Files, and Graphics State Agree](https://pyrosoft.pro/blog/making-runtime-state-consistent.md) — Adjacent allocations, runtime-loaded modules, media resources, and pipeline caching showed why a growing API surface still needs consistent state underneath it. - [Building the 32-Bit Graphics Path](https://pyrosoft.pro/blog/building-the-32-bit-graphics-path.md) — The 32-bit path progressed from API setup to real Vulkan commands and a known-pixel readback. That established important pieces without establishing a visible Portal frame. - [Game Progress and Measuring the Right Thing](https://pyrosoft.pro/blog/gameplay-performance-and-measuring-the-right-thing.md) — Controlled gameplay in King's Pass was useful progress. Understanding the route, memory growth, and test conditions was just as important as reaching another screen. - [Installers, Saves, Fonts, and the Parts Around the Game](https://pyrosoft.pro/blog/installers-saves-fonts-and-audio.md) — A silent 7-Zip installation and progress on saves, fonts, and audio brought more ordinary Windows behavior into the development stack. - [Following a Game Through Its Opening Video](https://pyrosoft.pro/blog/following-a-game-through-its-opening-video.md) — A game's opening sequence connected video formats, input timing, and its own state machine. Fixing the picture was only part of getting past it. - [Building More of the Windows Runtime](https://pyrosoft.pro/blog/windows-runtime-threads-and-older-directx.md) — Older DirectX, thread state, windows, and system objects all became part of the same job: answering the requests real Windows components make. - [From Return Values to Pixels and Sound](https://pyrosoft.pro/blog/from-return-values-to-pixels-and-sound.md) — A window, a sound, and a changing image answer different questions. This phase started connecting translated Windows code to results a person can actually see and hear. - [Bringing FEX to macOS: The First Windows Program](https://pyrosoft.pro/blog/bringing-fex-to-macos.md) — Getting the translation engine to build was the first step. Getting a real Windows executable to run showed where Ferrum's Mac-side work actually begins. - [Click-through controls and the cross-platform download set](https://pyrosoft.pro/blog/click-through-controls-and-the-cross-platform-download-set.md) — Recovery controls, Linux capture evidence and a verified upload record. - [A better workspace for all your PiPs](https://pyrosoft.pro/blog/a-better-workspace-for-all-your-pips.md) — Dashboard navigation, capture controls and a more deliberate packaging process. - [Giving InfinitePIP a clearer front door](https://pyrosoft.pro/blog/giving-infinitepip-a-clearer-front-door.md) — A project site that explains the floating-window workflow. - [Rebuilding InfinitePIP around independent floating windows](https://pyrosoft.pro/blog/rebuilding-infinitepip-around-independent-floating-windows.md) — Source selection, crop preview and controls for each PiP. - [InfinitePIP begins with a simple desktop idea](https://pyrosoft.pro/blog/infinitepip-begins-with-a-simple-desktop-idea.md) — Keep the useful part of another window nearby. - [Making the audio driver's foundations explicit](https://pyrosoft.pro/blog/making-the-audio-driver-s-foundations-explicit.md) — WDK and Sysvad attribution, with the remaining validation work kept visible. - [Rolling back the effects experiment](https://pyrosoft.pro/blog/rolling-back-the-effects-experiment.md) — A more focused topology and a reminder to read the actual format tables. - [Exploring more formats, channels and audio controls](https://pyrosoft.pro/blog/exploring-more-formats-channels-and-audio-controls.md) — A wider Windows audio experiment before the later simplification. - [Virtual audio endpoints for a computer without speakers](https://pyrosoft.pro/blog/virtual-audio-endpoints-for-a-computer-without-speakers.md) — The early Windows audio driver, format work and a quieter microphone path. - [Safer monitor lifetimes and clearer driver replies](https://pyrosoft.pro/blog/safer-monitor-lifetimes-and-clearer-driver-replies.md) — The latest retained driver changes focus on ownership and the control channel. - [More precise GPU selection and multi-monitor corrections](https://pyrosoft.pro/blog/more-precise-gpu-selection-and-multi-monitor-corrections.md) — PCI-based adapter resolution, HDR bit depth and swapchain threading. - [Building the tools around the display driver](https://pyrosoft.pro/blog/building-the-tools-around-the-display-driver.md) — Configuration, community automation and better device identification. - [Fine-tuning the virtual display](https://pyrosoft.pro/blog/fine-tuning-the-virtual-display.md) — Hardware cursors, custom EDID and fractional refresh rates. - [HDR and choosing the GPU behind the virtual screen](https://pyrosoft.pro/blog/hdr-and-choosing-the-gpu-behind-the-virtual-screen.md) — Expanding the display path while improving configuration. - [A monitor without another panel on the desk](https://pyrosoft.pro/blog/a-monitor-without-another-panel-on-the-desk.md) — The early Virtual Display Driver work on modes, refresh rates and setup. - [A rebuilt panel with displays, audio and an EDID lab](https://pyrosoft.pro/blog/a-rebuilt-panel-with-displays-audio-and-an-edid-lab.md) — The React and TypeScript rewrite, followed by more careful driver replies. - [Moving the panel behind a clearer application boundary](https://pyrosoft.pro/blog/moving-the-panel-behind-a-clearer-application-boundary.md) — Context isolation, a preload bridge and native window controls. - [Reconnecting the interface and fixing driver detection](https://pyrosoft.pro/blog/reconnecting-the-interface-and-fixing-driver-detection.md) — A busy revision with installation controls temporarily pulled back. - [Connecting the panel to everyday driver tasks](https://pyrosoft.pro/blog/connecting-the-panel-to-everyday-driver-tasks.md) — Real progress, tray controls, XML editing and audio-driver management. - [A control panel for the settings behind the driver](https://pyrosoft.pro/blog/a-control-panel-for-the-settings-behind-the-driver.md) — From a nonfunctional shell to early commands and XML editing. - [Advanced controls, shared workflows and the bundled CLI](https://pyrosoft.pro/blog/advanced-controls-shared-workflows-and-the-bundled-cli.md) — The path through the layout patches to 26.10.5.6, build 41. - [Real camera sources, HID reports and a private peer tunnel](https://pyrosoft.pro/blog/real-camera-sources-hid-reports-and-a-private-peer-tunnel.md) — Build 36 turns several remaining paths into measurable native workflows. - [Teaching the suite to recover its own devices](https://pyrosoft.pro/blog/teaching-the-suite-to-recover-its-own-devices.md) — Resource journals, atomic audio installation and safer storage handling. - [Testing what the Mac devices actually deliver](https://pyrosoft.pro/blog/testing-what-the-mac-devices-actually-deliver.md) — Audio measurements, MIDI round trips and a real disk-image workflow. - [From a Mac virtual display to a driver suite](https://pyrosoft.pro/blog/from-a-mac-virtual-display-to-a-driver-suite.md) — A native control center begins expanding beyond monitors. - [Free manual Windows gaming setup on Apple Silicon: step by step](https://pyrosoft.pro/blog/manual-windows-gaming-apple-silicon-free-2026.md) — Install Sikarugir, create a Wine wrapper, configure graphics, install Steam or a standalone game, and troubleshoot your first launch. Plus honest paid alternatives. - [Windows games on Mac](https://pyrosoft.pro/blog/windows-games-on-mac.md) — Every way to run Windows games on a Mac in 2026 — translation, streaming, virtual machines — and which one fits the games you actually play. - [Steam on Mac](https://pyrosoft.pro/blog/steam-on-mac.md) — Steam runs on macOS, and most of its catalog can reach your Mac one way or another. What's native, what needs translation, and what streams. - [Anti-cheat on Mac](https://pyrosoft.pro/blog/anti-cheat-on-mac.md) — Kernel-level anti-cheat is why Fortnite, Valorant and Apex won't run on a Mac through any translation layer — and what actually works instead. - [Boot Camp on Apple Silicon](https://pyrosoft.pro/blog/boot-camp-apple-silicon.md) — Boot Camp doesn't exist on M-series Macs. What replaced it for games, and when you actually need a full Windows install. - [Play Windows games on Mac for free](https://pyrosoft.pro/blog/free-windows-games-on-mac.md) — The genuinely free routes — raw Wine, Game Porting Toolkit, what's left of Whisky — what they cost you in time, and when $29.99 stops being worth avoiding. - [Bourbon 26 system requirements](https://pyrosoft.pro/blog/bourbon-26-system-requirements.md) — What Bourbon 26 needs, everything it installs, and how much disk the whole Windows-gaming stack actually takes. - [DXVK vs D3DMetal](https://pyrosoft.pro/blog/dxvk-vs-d3dmetal.md) — DXVK, VKD3D, DXMT, WineD3D or D3DMetal — what each renderer translates, and which one your game wants on a Mac. - [Wine bottles on Mac](https://pyrosoft.pro/blog/wine-bottles-on-mac.md) — What a Wine bottle (prefix) is, why every game deserves its own, and how Bourbon 26's Bottle Shelf manages runtimes per title. - [AIL eAPP on Mac](https://pyrosoft.pro/blog/ail-eapp-on-mac.md) — How to run the AIL eAPP on macOS with Bourbon 26, step by step. - [Run .exe files on Mac](https://pyrosoft.pro/blog/run-exe-on-mac.md) — How to open and run Windows .exe and .msi files on macOS — safely, in their own bottle. - [Notepad++ on Mac](https://pyrosoft.pro/blog/notepad-plus-plus-on-mac.md) — Notepad++, PuTTY, WinSCP and the small Windows utilities worth keeping on your Mac — and the native swaps worth taking instead. - [Whisky alternative](https://pyrosoft.pro/blog/whisky-alternative.md) — Whisky is no longer maintained. What that means for your bottles, and the closest like-for-like replacement on macOS. - [CrossOver alternative](https://pyrosoft.pro/blog/crossover-alternative.md) — CrossOver charges yearly; Bourbon 26 is $29.99 once. Where CodeWeavers still earns its price, and where the alternative wins. - [Parallels alternative](https://pyrosoft.pro/blog/parallels-alternative.md) — Parallels runs a whole Windows; Bourbon 26 runs just your games. Which approach fits, and when a full VM is genuinely the right call. - [Game Porting Toolkit](https://pyrosoft.pro/blog/game-porting-toolkit.md) — What Apple's Game Porting Toolkit is, who it's actually for, and how Bourbon 26 packages the same technology for people who just want to play. - [Windows on Apple Silicon](https://pyrosoft.pro/blog/windows-on-apple-silicon.md) — Every way to run Windows software on an M-series Mac in 2026 — translation, emulation, VMs — and how to pick per app. - [What Wine can't run](https://pyrosoft.pro/blog/what-wine-cant-run.md) — Drivers, kernel services, anti-cheat and the other Windows software no translation layer can handle — where a VM is the honest answer.