Building the 32-Bit Graphics Path

The 32-bit Windows target is important because an ARM64 Mac can't simply run those programs as native code. Ferrum needs to translate their Intel instructions and correctly handle their smaller pointers, structures, and calling conventions. A graphics API adds a lot of those structures in one place.

During this phase, the i386 path gained more of the Vulkan connection: surfaces, swapchains, presentation, commands, synchronization, and descriptor-related work. One recorded test had a 32-bit guest draw a known pixel and read it back. Another set of changes moved DXVK initialization through its display-adapter requirements and into real device creation.

A known-pixel test is useful because it gives us something more precise than a successful function return. We can ask whether the command reached the right resource and produced the requested result. The conversion code also has to carry array lengths, offsets, handles, and pointers correctly across the 32-to-64-bit boundary.

There is an important limitation here. These focused graphics tests do not prove that an entire 32-bit game has the Windows environment it needs. The existing host-implemented import path was useful for finding problems, but the product goal is to run arbitrary applications through real Wine components, without adding one more title-specific import every time a different game asks for something.

Portal became a demanding case for that work. It exercised a much larger combination of the loader, runtime, graphics, and application APIs than a small drawing fixture. Progress through those layers is worth recording, but I wouldn't describe device creation or command submission as a playable game.

What we had by this stage was a stronger graphics foundation with specific readback evidence. The application startup path, a visible game frame, and the menu were still separate milestones. Keeping them separate makes it easier to see what the next fix actually accomplishes.