# A Launcher and a Freeze That Wasn't the Presenter

> The launcher made the project easier to approach. A separate graphics investigation showed why a changing frame counter wasn't enough to prove a changing picture.

Canonical page: https://pyrosoft.pro/blog/a-launcher-and-a-freeze-that-wasnt-the-presenter

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

The September launcher work gave Ferrum a more approachable starting point: drag a Windows program onto an application, classify it, prepare the environment, and launch it through the FEX path. The next changes added routing for 32-bit Windows executables. That was useful development packaging, although a launcher by itself doesn't make the runtime or the distribution ready to ship.

At the same time, an on-screen freeze needed a better explanation. An earlier theory blamed presenter early returns. The later investigation showed that the scrolling test was still presenting while its picture stopped changing. The actual problem was in GDI object allocation: freed handle-table indices and drawing-context slots were not being recycled.

The scrolling fixture created and deleted drawing objects repeatedly. Eventually the pools ran out, and later drawing operations stopped producing the expected content. A presentation counter could keep advancing through that failure, which made it a misleading witness if we looked at it alone.

Recycling those resources changed the result. The recorded bounded on-screen run lasted 65 seconds, with distinct captured content rather than just a rising presentation count. A withdrawal control restored the old allocation behavior and reproduced the failure. That is much more useful than changing the presenter and assuming a smoother-looking number explains the original problem.

There were still limits. The result belonged to that test, build, and display path; human smoothness and broader application sessions were not automatically accepted. The resource model also had documented stale-handle considerations. Those details matter before calling a component finished.

Some other 32-bit NT work from this period later failed the project's evidence audit because checks were accepting placeholder answers. I cover that correction in the October 2 chapter. I'm keeping the valid launcher and GDI progress separate from those discarded claims, rather than treating everything from the same dates as equally proven.