Win98与WinXP及后续版本GDI差异致StretchDIBits SRCPAINT文字缺失

你定位到的StretchDIBits()调用异常不是调试误差，是Windows XP之后GDI实现的明确行为变更导致的：

• Win9x系统的GDI在处理StretchDIBits()的SRCPAINT光栅操作（ROP码0x00EE0086，运算逻辑为源像素OR目标像素）时，不会校验源DIB颜色表的保留位/alpha字段，老游戏常用的“黑底白字DIB+SRCPAINT”方案可以正常实现黑位透明、白字叠加的效果，不需要额外做透明色处理。
• WinXP及后续版本的GDI在处理StretchDIBits()的非SRCCOPY类ROP时，会强制检查源DIB的颜色格式标记、颜色表保留字段：老游戏生成临时DIB时大多只填RGB值，不会把颜色表每个表项的保留字节初始化为0，GDI会误判该DIB带alpha通道，在ROP运算前错误将包括白字在内的所有像素alpha值判定为0，最终没有有效像素写入目标DC，就会出现“内存位图里有内容、函数返回成功、屏幕无渲染”的现象。
• 系统自带的兼容模式没有覆盖这个逻辑分支：兼容层仅处理版本校验、窗口消息、旧版内存分配等通用兼容问题，没有修改GDI内部ROP对DIB的校验逻辑，所以指定Win95/98兼容模式不会生效。

• 二进制补丁方案：用十六进制编辑器定位游戏主程序中StretchDIBits()调用前压入栈的SRCPAINT常量，将其替换为SRCCOPY（ROP码0x00CC0020），搭配老游戏兼容渲染工具（如DDrawCompat、dgVoodoo2）的颜色键透明功能，将纯黑色设为透明色，即可还原原本的文字叠加效果，不会出现黑块覆盖背景的问题。
• 免修改方案：直接为游戏挂载最新版DDrawCompat，该兼容层专门修复了大量Win9x到NT内核系统的GDI/DirectDraw行为差异，其中就包含StretchDIBits()处理非SRCCOPY ROP时的颜色表校验bug，绝大多数同类型老游戏的文字缺失问题不需要额外配置即可直接修复。
• 验证方法：用API Monitor挂载游戏进程，拦截StretchDIBits()调用，在回调中把传入的BITMAPINFO结构内所有颜色表项的rgbReserved字段强制置0后放行调用，如果文字正常显示即可100%确认根因。

内容的提问来源于stack exchange，提问作者ayuanx