Ferrum development journal · Part 14 of 19
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.
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.
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