# 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.

Canonical page: https://pyrosoft.pro/blog/correcting-the-progress-report

Live development journal; no publication date.
Work period: 2026-10-02 to 2026-10-02
Updated: 2026-10-20

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.