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