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