# From Return Values to Pixels and Sound

> A window, a sound, and a changing image answer different questions. This phase started connecting translated Windows code to results a person can actually see and hear.

Canonical page: https://pyrosoft.pro/blog/from-return-values-to-pixels-and-sound

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

Once an executable can run, the next question is pretty straightforward: can it do anything useful outside the terminal? For a game or a desktop application, that means windows, drawing, input, and sound. Those are separate connections, and getting one working doesn't automatically bring the others along.

The August work started joining those pieces. A translated guest produced sound, the Mac surface gained a way to accept an image from the graphics path, and the rendering checks moved toward verifying the pixels the guest had actually drawn. That last part matters more than a successful device-creation call. An application can create a graphics device and still leave you looking at a blank window.

For example, if a test draws a known color, we can read the result back and compare it with what the program requested. Then we can ask a different question: did that image reach the window? The renderer and the presentation layer can each be doing something reasonable while the connection between them is wrong.

This phase also exposed instruction and API gaps that tiny command-line programs hadn't reached. More realistic graphics code exercised vector instructions, DLL initialization, memory, and synchronization in combinations the earlier tests never used. That is one reason I don't treat the number of implemented functions as a compatibility score. What matters is whether the application can use them together.

The sound and pixel milestones were encouraging because they made the work less abstract. There was something to observe. They were still targeted development results, though. They didn't establish sustained game audio, a long interactive session, or support for every DirectX feature.

The practical lesson was to keep asking for the result at the far end of a feature. If we're working on drawing, let's inspect what was drawn. If we're working on presentation, let's make sure the window changes. A return value is useful evidence, but the thing the viewer sees needs its own check.