GoKawiilSeptember 17, 2026
nullprogram.com/blog/2026/09/17/
Stars! is a 1995 4X game (explore, expand, exploit, exterminate) for 16-bit Windows 3.1 that I first played ~28 years ago. While Windows is famously backwards compatible, it’s notoriously difficult to play Stars! today. Windows x64 cannot run 16-bit applications, and playing requires either retro hardware or emulation (otvdm, DOSBox), sometimes paired with Wine. My new, exciting solution, Stars!VM, or Stars! Virtual Machine, embeds a custom 80286 emulator and a Win16 to Win32 bridge. As native Win32, the game looks and feels exactly as it did originally, except sporting a modern file chooser and 4k scaling. It’s indistinguishable from a genuine 32-bit or 64-bit port of the game, especially with the original 16-bit game embedded inside the VM executable.
The signed releases on GitHub embed a compressed copy of the original 16-bit game, so that single EXE is ready to play out-of-the-box with no further setup or downloads. I’m distributing 32-bit builds (but requires SSE2) because there’s no advantage to 64-bit here, and these builds work (almost) everywhere except 16-bit Windows. 32-bit Windows could run the original 16-bit game, but the VM-encapsulated version is better behaved. It doesn’t dump a Stars.ini under C:\WINDOWS , it interacts properly with the task bar, and copy protection is neutralized via the OS bridge.
If you ever been curious about Stars!, now’s the time to try it. The game has a thorough, built-in tutorial, but also check out the wiki, the official strategy guide, and AutoHost (play-by-email service). The game predates the modern search engine concept, otherwise they might have chosen a better name. I suggest using “stars 4x” in your searches.
If you want to build from source and hack on the VM yourself, the best tool for the job is w64devkit, of course, because it comes with everything you’ll need. Plus the game itself: stars.exe from stars27jrc3.zip .
Implementation details
The emulator itself requires x86 or x86-64 because it does not implement x87 (80-bit floating point) in software, but instead runs these operation directly on the host’s x87 hardware. This is simple, fast, and precise. The project validates the emulation as a whole with a differential fuzzer against the host. The fuzzer randomly generates a 16-bit instruction, emulates it, then runs it with JIT on the host and compares the results.
Handles on Windows are pointer-sized, and so the Win16-to-Win32 bridge maps 16-bit handles to host handles. It marshals between different struct layouts when translating these calls, services the DOS interrupts the game requires, an copies data in and out of guest memory. It’s rather like running a Wasm instance, which of course makes sense in retrospect.
The Win32 bridge is also monitorable and manipulatable using the Model Context Protocol (MCP). AI agents can “see” the UI “DOM” as it’s built, and can drive it by injecting synthetic events into the event pump, all without going through the usual desktop control. The MCP can also read and write guest memory. Opus 5 played a complete game through MCP — which is quite fun to watch — requesting my assistance at just two points when it got stuck in the UI. A foundation for a new Stars!Bench?
... continue reading