Ferrum development journal · Part 15 of 19
Making Memory Protection and Lifetime Tests More Useful
The memory work checked more than successful allocation: page permissions, decommit, release, reuse, process-image data, and the bytes around each result.
Memory compatibility is one of the places where the difference between Windows and an Apple Silicon Mac becomes very concrete. Windows code can work with a 4 KB page while the host manages protection at a larger page size. The port needs to track the guest's view carefully instead of assuming that a writable host mapping means every smaller guest page is writable.
The work in this period expanded the tests around allocation, protection, decommit, release, and reuse. A successful allocation is the easy case. More interesting questions include whether a protected neighbor keeps its bytes, whether decommitted memory is reported correctly, and whether a reused address is being mistaken for the old allocation.
Process-image information needed the same care. The 32-bit structure has its own layout, and a buffer-size check or return-length field is part of the API's behavior. A result that looks plausible in the first field can still be wrong for a real loader reading the rest of the structure.
The development packets retained complete output structures, before-and-after bytes, and guarded regions around the target. That makes it possible to catch a write outside the intended field or a change that an abbreviated log would hide. The ordinary memory and lifetime profiles were later repeated on the adopted checkpoint, rather than assuming that an older passing result applied to every newer driver.
There were failures in the test and build machinery along the way as well. Those were preserved and repaired separately from product bugs. If a collector rejects a valid result because its own model is wrong, changing the collector doesn't magically become a new runtime success; the saved evidence still needs to be checked against the actual contract.
This phase overlaps the later startup work because the loader depends on these same memory behaviors. It made the foundation more useful for real applications, but it wasn't a reason to mark every VM or concurrency path complete. The point was to make the next application failure easier to trust and explain.
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