# Building More of the Windows Runtime

> Older DirectX, thread state, windows, and system objects all became part of the same job: answering the requests real Windows components make.

Canonical page: https://pyrosoft.pro/blog/windows-runtime-threads-and-older-directx

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

A Windows compatibility layer starts to get interesting when the components begin depending on one another. A DLL needs thread-local state. A graphics library wants to enumerate a display. A registry operation needs the same view of an object that another API already created. Each individual call may look simple, but the application expects them to describe one consistent system.

One useful example from this period was the older Direct3D path. Direct3D 9 doesn't discover a display in exactly the same way as the newer DXGI-based path. The work had to answer the display-enumeration requests that this code actually made before it could create the expected device. The milestone records include targeted device and pixel results; that isn't a promise that every older DirectX game is supported.

Thread behavior was becoming just as important. A value that belongs to one thread can't be treated as a process-wide variable. Modules loaded after a thread starts still need the right initialization. A wait has to release the resources another thread needs in order to wake it. These are the kinds of problems that can make a program appear to stall somewhere unrelated to the original mistake.

There was also more work on the 32-bit foundation, including the process information and loader state that i386 programs expect. That target brings an extra address-space problem on the Mac: a 32-bit guest pointer needs to be translated into the correct host address. Passing the number through unchanged isn't enough.

For someone using the finished product, none of this should require a special setup step. You should launch the application and have its ordinary Windows components behave consistently. During development, though, those assumptions have to be made explicit and tested one at a time.

The progress here was a broader set of real runtime behaviors, with plenty of application-level work still open. I was moving past the question of whether Intel instructions could execute and into the harder question of whether the surrounding environment made sense to the program using it.