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

Canonical page: https://pyrosoft.pro/blog/memory-protection-and-lifetime-tests

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

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.