Ferrum development journal · Part 1 of 19
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.
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.
Ferrum development journal
View the journalLive19 entries so far·Updated New (19 entries updated in the last 14 days)
- Part 1Bringing FEX to macOS: The First Windows Program
- Part 2From Return Values to Pixels and Sound
- Part 3Building More of the Windows Runtime
- Part 4Following a Game Through Its Opening Video
- Part 5Installers, Saves, Fonts, and the Parts Around the Game
- Part 6Game Progress and Measuring the Right Thing
- Part 7Building the 32-Bit Graphics Path
- Part 8Making Memory, Files, and Graphics State Agree
- Part 9DirectX 12, Shader Caches, and the Steam Startup Work
- Part 10Working on Presentation and Controller Input
- Part 11A Launcher and a Freeze That Wasn't the Presenter
- Part 12Portal Reaches a Command Stream, With the Frame Still Ahead
- Part 13Correcting the Ferrum Progress Report
- Part 14Recovering the Project and Resuming Real Tests
- Part 15Making Memory Protection and Lifetime Tests More Useful
- Part 16Getting Wine's Real 32-Bit Startup to Run
- Part 17Making the Launcher Own Its Storage and Processes
- Part 18A Real Archive Roundtrip and Better File Behavior
- Part 19Asynchronous I/O and the Bytes a Cancelled Write Keeps