# 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](<https://github.com/FEX-Emu/FEX>); [Apple’s Rosetta support update](<https://developer.apple.com/news/?id=w5ngl9k2>) (September 1, 2026; consulted for this entry).