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